Ubuntu and Debian package repository now available

[TedWalther]

Lutz has done a good job of making Debian packages available.



Now there is a Debian and Ubuntu repository available.  Once you set it up, you will get your newlisp upgrades automatically and the package management system will take care of getting the right deb file for your architecture.



The i386 and amd64 architectures are supported on Debian lenny (stable), Debian squeeze (testing), and Ubuntu karmic.



For complete info and instructions, go here:



http://dpkg.reactor-core.org/">http://dpkg.reactor-core.org/



Thank you Lutz for finding a bug in my packaging earlier on; it is all fixed and working.



I appreciate that there was an apt repository for newlisp earlier on; I hope this repository will be more comprehensive and bring newLISP to a broader spectrum of Debian distributions.  More specifically, I have eliminated the problem that made debian package management always consider newlisp packages to be coming from an "untrusted source".



Ted

Former member of Debian

[Lutz]

Thanks a lot Ted, there is a link to the repository also in this page:



http://www.newlisp.org/?Downloads">http://www.newlisp.org/?Downloads

[TedWalther]

newLISP is a very rewarding project to contribute to. :-)

[CaveGuy]

Now there is a Debian and Ubuntu repository available.  Once you set it up, you will get your newlisp upgrades automatically and the package management system will take care of getting the right deb file for your architecture.



This scares the hell out of me, just one not so little change like (inc 'a) to (inc a) to (++ a) and just about evey cgi and newlisp application on the system/server goes boom! I am in the process of moving code developed and currently running live on newlisp 6.22 6.5 7.0.4 9.2.0 and 10.1.7 on several W2k and w2k3 servers onto to a single multicore Ubuntu system, using what I hope to be 10.2 syntax rules. Oh ya lets not forget all the (write-line FileHandle "string")'s we had to change not so long ago.



In the past I have gotten around these problems by (link'ing applications to the newlisp.exe they were developed under and saved using app-name.exe,  now I am moving to Ubuntu this does not look like an option any longer :(



Once you make the commitment to the Ubuntu and Debian package repository concept, when and where auto-updates can be expected, please no more pulling functions out from under running code!



Keep makeing new and better ways, but no more (int's or (write-line like changes, PLEASE from now on, use a new sym and leave the old one alone.

[TedWalther]

CaveGuy, you have a good point.  For your needs, I suggest that you don't use the Debian packages.  Instead, I suggest you use the "configure-alt" configure script, use the --prefix option.  That way you can stick your particular compile of newlisp in a particular directory.  Then make your scripts reference that version directly.  For instance, you could do this:

Code Select Expand


$ ./configure-alt --prefix=/opt/newlisp-10.1.0


Then when 10.2.0 is released, you can do this:

Code Select Expand


$ ./configure-alt --prefix=/opt/newlisp-10.2.0


Set your symlinks to taste.



Your scripts would look like this:

Code Select Expand


#!/opt/newlisp-10.2.0/bin/newlisp
...


Note that this capability of configure-alt was released in the 10.1 devel

series, so unfortunately it isn't available earlier than that.



Ted

[m35]

This scares the hell out of me, just one not so little change like (inc 'a) to (inc a) to (++ a) and just about evey cgi and newlisp application on the system/server goes boom! I am in the process of moving code developed and currently running live on newlisp 6.22 6.5 7.0.4 9.2.0 and 10.1.7 on several W2k and w2k3 servers onto to a single multicore Ubuntu system, using what I hope to be 10.2 syntax rules. Oh ya lets not forget all the (write-line FileHandle "string")'s we had to change not so long ago.



In the past I have gotten around these problems by (link'ing applications to the newlisp.exe they were developed under and saved using app-name.exe,  now I am moving to Ubuntu this does not look like an option any longer :(



Once you make the commitment to the Ubuntu and Debian package repository concept, when and where auto-updates can be expected, please no more pulling functions out from under running code!



Keep makeing new and better ways, but no more (int's or (write-line like changes, PLEASE from now on, use a new sym and leave the old one alone.

Thanks for sharing the difficulties of your situation. This gives the community a very real use-case to consider when contemplating changes to newLISP.

[cormullion]

please no more pulling functions out from under running code!  ... Keep makeing new and better ways, but no more (int's or (write-line like changes, PLEASE from now on, use a new sym and leave the old one alone.

+1



no wait, inc



no, ++



Everyone expects me to say this, so I thought I'd better oblige ... :)

[Lutz]

Both 'inc' and '++' exist in 10.2.0, the first for floats the second for integers.



The is a change/addition asked for by the community many times over the years, to make it consistent with all other number operators: letters for floats special symbols for integer. I cannot recall anybody objecting to it.



At least in all of my code, this has only caused a problem when 'inc' was use without the second parameter (when it did integer mode), and in code interfacing with C-libraries.



I believe taking out the quote from variables 'inc'ed in v.10.0 a year ago, caused much more grief then this years introduction of ++/--.



The other change from 'name' to 'term' (also asked for by the community) may cause more problems. Though in my own files it has not occurred frequently.



After having said all that, I want to say, I also understand Caveguy's and Cormullion's concerns and these decisions to change names and make functional changes where not taken lightly. Like many of you, I have to maintain a lot of code too and "suffer" the same experience when these changes come along.



If you look back into all of the history of developing newLISP,  you will see that this kind of disruptive changes where much more frequent in earlier versions and have greatly diminished in recent years and will keep on diminishing more in years to come.