Re: [Chicken-users] Egg - Chicken version compatibility
Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. That's an interesting distinction to make. Given that it has the facility to install executables anyway, what's the difference in your mind? It doesn't take care of third-party libraries. I see it as a device to install libraries and perhaps some tools. That doesn't prevent it being used to install other sorts of applications, but it simply isn't a replacement for apt-get. Some sort of preparation (even if it means installing a reasonably recent chicken) will be needed. In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. That wouldn't work for flags that take arguments. In the other message, though, you suggested using declares, where unknown ones emit warnings rather than errors. Can't the command-line optimisation flags have the same semantics? What happens with declares that correspond to flags with arguments? The compiler can ignore declarations like (declare (florgleborgle this that the-other)) But how should it ignore csc ... -forgleborgle this that the-other Marking optimization flags (-opt-... or -f... or so) would perhaps be an answer, but I find it ugly and it would introduce too much change and means a lot of work on the docs. Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. That itself would be a rather messy change. Aye, I prefer the subsequent suggestions of sticking to -On for portable command lines, or declarations in the source! Yes, that's a good suggestion. The problem you encountered was not caused by core system changes in this case. Well, an egg was using a flag that didn't work in older versions - so adding that flag was a change to the core, no? Perhaps more of an enhancement. Since eggs and core are two different development streams, it is hard to keep them in sync perfectly. And we (and Salmonella) work hard at doing that. And who do you mean with we? And think about? Can't you simply say that this is annoying and you want it to stop? Did I not managed to express that? :-) Yes, you did. * Let's have a discussion about what the best semantics for an optimisation flag are. Should it fail if that optimisation isn't available in this version, or just emit a warning? What this boils down to is, when somebody requests such a flag, are they saying My code NEEDS this optimisation or My could WOULD LIKE this optimisation but will work without it? I'm not sure I understand. Isn't the problem that old chickens fail to support a new option? Or are you suggesting to be more careful when introducing options? I try to add declarations for all new options that regard specific optimizations, if possible. * Can we work out what versions are being installed by distros out there and draw a line in the sand of the oldest version it'd be nice if eggs still worked with (to be revised periodically) and have salmonella do another build of all the eggs against the appropriate git tag of chicken, to help detect accidental dependencies in eggs? A good idea. But I think we will need more computing resources for that (a Salmonella Farm! ;-). Or a very simple and easy-to-use way for someone to grab a shell-script that downloads everything, performs a salmonella run and sends us the results. Or something like this. * How about, when interfaces change in the manual, writing something along the lines of added in version X, so that people writing code using those interfaces who are concerned about compatability are given pause for thought, and can take appropriate actions (SRFI-0 etc) Hm... yes. As for what *I* can do? I've got some hardware on order for a new home fileserver to replace my long-dead one, so I could probably set up a chroot to bring up a geriatric chicken in and test the eggs for salmonella. Very good. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg - Chicken version compatibility
Hi, Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. That's an interesting distinction to make. Given that it has the facility to install executables anyway, what's the difference in your mind? As far as I can tell this difference is related to how dependencies are managed. chicken-install only calculates dependencies in one direction. i.e. When one installs an egg it works out the dependencies for that egg and ensures that they are installed. If, subsequently, a different egg is installed that has conflicting dependencies then the original egg will stop working and one won't find out about it until one tries to use it. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg - Chicken version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2011 04:32 AM, Felix wrote: Hello! Hello, Alaric. Hi! Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Probably an oversight of the egg maintainer. Have you contacted that person? Kon had a patch out within SECONDS, before I'd even found out it was his egg. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. That's an interesting distinction to make. Given that it has the facility to install executables anyway, what's the difference in your mind? In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. That wouldn't work for flags that take arguments. In the other message, though, you suggested using declares, where unknown ones emit warnings rather than errors. Can't the command-line optimisation flags have the same semantics? What happens with declares that correspond to flags with arguments? Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. That itself would be a rather messy change. Aye, I prefer the subsequent suggestions of sticking to -On for portable command lines, or declarations in the source! We've had other problems with problems due to moving things around in the core chicken libraries, too. Oh yeah, we head. Sometimes things have to change. Still we try to maintain backwards compatibility, if possible. Long deprecation phases, change request, etc. Yes, I mean it, even if development sometimes may make the impression of being haphazardly done. I've sent you a mail about compatibility issues regarding ugarit (use of getenv). IIRC, you never replied. Indeed! I'm only just getting back into sorting Ugarit out, after a too-long hiatus :-( I need to get it compiling before I can start to change things :-) I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! The problem you encountered was not caused by core system changes in this case. Well, an egg was using a flag that didn't work in older versions - so adding that flag was a change to the core, no? And who do you mean with we? And think about? Can't you simply say that this is annoying and you want it to stop? Did I not managed to express that? :-) So, do you have any suggestions? What can we do better? What are YOU willing to contribute? Could you specify more precisely what you'd like to have? How are the necessary incompatibilities to be introduced? How can we safely distinguish between bugfixes and incompatibilities (probably brought in with the intend of fixing bugs)? How can we keep up fast-paced development and maintenance, and fast response/bugfixing cycles for user reports and feature requests? Well, as I'm still catching up on things myself, I didn't want to get too far into specifics, but here's a few ideas: * Let's have a discussion about what the best semantics for an optimisation flag are. Should it fail if that optimisation isn't available in this version, or just emit a warning? What this boils down to is, when somebody requests such a flag, are they saying My code NEEDS this optimisation or My could WOULD LIKE this optimisation but will work without it? * Can we work out what versions are being installed by distros out there and draw a line in the sand of the oldest version it'd be nice if eggs still worked with (to be revised periodically) and have salmonella do another build of all the eggs against the appropriate git tag of chicken, to help detect accidental dependencies in eggs? * How about, when interfaces change in the manual, writing something along the lines of added in version X, so that people writing code using those interfaces who are concerned about compatability are given pause for thought, and can take appropriate actions (SRFI-0 etc) As for what *I* can do? I've got some hardware on order for a new home fileserver to replace my long-dead one, so I could probably set up a chroot to bring up a geriatric chicken in and test the eggs for salmonella. cheers, felix ABS - -- Alaric Snell-Pym
Re: [Chicken-users] Egg - Chicken version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2011 04:32 AM, Felix wrote: Hello! Hello, Alaric. Hi! Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Probably an oversight of the egg maintainer. Have you contacted that person? Kon had a patch out within SECONDS, before I'd even found out it was his egg. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. That's an interesting distinction to make. Given that it has the facility to install executables anyway, what's the difference in your mind? In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. That wouldn't work for flags that take arguments. In the other message, though, you suggested using declares, where unknown ones emit warnings rather than errors. Can't the command-line optimisation flags have the same semantics? What happens with declares that correspond to flags with arguments? Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. That itself would be a rather messy change. Aye, I prefer the subsequent suggestions of sticking to -On for portable command lines, or declarations in the source! We've had other problems with problems due to moving things around in the core chicken libraries, too. Oh yeah, we head. Sometimes things have to change. Still we try to maintain backwards compatibility, if possible. Long deprecation phases, change request, etc. Yes, I mean it, even if development sometimes may make the impression of being haphazardly done. I've sent you a mail about compatibility issues regarding ugarit (use of getenv). IIRC, you never replied. Indeed! I'm only just getting back into sorting Ugarit out, after a too-long hiatus :-( I need to get it compiling before I can start to change things :-) I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! The problem you encountered was not caused by core system changes in this case. Well, an egg was using a flag that didn't work in older versions - so adding that flag was a change to the core, no? And who do you mean with we? And think about? Can't you simply say that this is annoying and you want it to stop? Did I not managed to express that? :-) So, do you have any suggestions? What can we do better? What are YOU willing to contribute? Could you specify more precisely what you'd like to have? How are the necessary incompatibilities to be introduced? How can we safely distinguish between bugfixes and incompatibilities (probably brought in with the intend of fixing bugs)? How can we keep up fast-paced development and maintenance, and fast response/bugfixing cycles for user reports and feature requests? Well, as I'm still catching up on things myself, I didn't want to get too far into specifics, but here's a few ideas: * Let's have a discussion about what the best semantics for an optimisation flag are. Should it fail if that optimisation isn't available in this version, or just emit a warning? What this boils down to is, when somebody requests such a flag, are they saying My code NEEDS this optimisation or My could WOULD LIKE this optimisation but will work without it? * Can we work out what versions are being installed by distros out there and draw a line in the sand of the oldest version it'd be nice if eggs still worked with (to be revised periodically) and have salmonella do another build of all the eggs against the appropriate git tag of chicken, to help detect accidental dependencies in eggs? * How about, when interfaces change in the manual, writing something along the lines of added in version X, so that people writing code using those interfaces who are concerned about compatability are given pause for thought, and can take appropriate actions (SRFI-0 etc) As for what *I* can do? I've got some hardware on order for a new home fileserver to replace my long-dead one, so I could probably set up a chroot to bring up a geriatric chicken in and test the eggs for salmonella. cheers, felix ABS - -- Alaric Snell-Pym
Re: [Chicken-users] Egg - Chicken version compatibility
On Aug 20, 2011, at 17:32, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: * How about, when interfaces change in the manual, writing something along the lines of added in version X, so that people writing code using those interfaces who are concerned about compatability are given pause for thought, and can take appropriate actions (SRFI-0 etc) This doesn't come up too terribly often, but whenever I question when an interface was added, and the question is likely to come up again, I add the info to the wiki. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Egg - Chicken version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! Having a spare lunch hour, I started to set myself up to do some Ugarit hacking on my new work laptop. I quickly ran sudo apt-get install chicken-bin and a fresh 4.5.0 appeared in my path, so I ran off and tried to run my new ugarit test suite... ...only for it to die on trying to install tiger-hash, due to: installing message-digest: ... changing current directory to /tmp/chicken-install-31.tmp/message-digest /usr/bin/csi -bnq -setup-mode -e (require-library setup-api) -e (import setup-api) -e (extension-name-and-version '(\message-digest\ \\)) /tmp/chicken-install-31.tmp/message-digest/message-digest.setup /usr/bin/csc -feature compiling-extension -setup-mode message-digest.scm -shared -optimize-leaf-routines -inline -unboxing - -output-file message-digest.so -emit-import-library message-digest - -scrutinize -optimize-level 3 -debug-level 1 - -no-procedure-checks-for-toplevel-bindings -no-bound-checks csc: invalid option `-no-procedure-checks-for-toplevel-bindings' shell command failed with nonzero exit status 16384: /usr/bin/csc -feature compiling-extension -setup-mode message-digest.scm -shared -optimize-leaf-routines -inline -unboxing - -output-file message-digest.so -emit-import-library message-digest - -scrutinize -optimize-level 3 -debug-level 1 - -no-procedure-checks-for-toplevel-bindings -no-bound-checks Error: shell command terminated with nonzero exit code 17920 Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. We've had other problems with problems due to moving things around in the core chicken libraries, too. I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5OYDEACgkQRgz/WHNxCGrKvQCgjmZJPhN7BWmA+XKRC6aHewdY pWIAn0ewJghNLA7zePapPToLLHZ4Y03s =ed5i -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg - Chicken version compatibility
On Fri, Aug 19, 2011 at 02:08:01PM +0100, Alaric Snell-Pym wrote: Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Agreed. In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. In principle that's a good suggestion. I'd like to add that it's probably good to emit a warning, so people get notified of typos instead of scratching their heads to try to understand why their flag didn't have an effect. But the real reason it went wrong in this particular case is that people should NOT be using these hyper-specific flags for compiling eggs intended for public consumption unless there's a really good reason to do so. It's just an optimization flag, and I think if people need to squeeze every last drop of performance for an egg it's probably better to expect them to pass this option when compiling the egg through CSC_OPTIONS. I think egg authors should be cautious and generally only use the switches -O1, -O2 etc (that's O the letter, not the number :P) by default. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg - Chicken version compatibility
But the real reason it went wrong in this particular case is that people should NOT be using these hyper-specific flags for compiling eggs intended for public consumption unless there's a really good reason to do so. Absolutely. It's just an optimization flag, and I think if people need to squeeze every last drop of performance for an egg it's probably better to expect them to pass this option when compiling the egg through CSC_OPTIONS. Even better is to use declare. Unknown declarations give a warning but will be ignored. I think egg authors should be cautious and generally only use the switches -O1, -O2 etc (that's O the letter, not the number :P) by default. Right, indeed. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg - Chicken version compatibility
Hello! Hello, Alaric. Looks like the message-digest egg passes - -no-procedure-checks-for-toplevel-bindings to csc, which this old version of it doesn't like. Probably an oversight of the egg maintainer. Have you contacted that person? Now, there's several easy fixes to that (I'm compiling a more recent chicken from git as we speak), but it's a bad precedent IMHO that people might install chicken from their system package manager and then find they can't run Chicken apps. I'd like to be able to confidently say Wanna use Ugarit? Install chicken then type 'chicken-setup -s ugarit' and you're away! rather than expect people to install from source or from funny packages. Yes, that would be nice. But chicken-install is not a package manager, it's a tool to install libraries. In this case, I think that optimisation flags should all be ignored by csc if it doesn't understand them. That wouldn't work for flags that take arguments. Perhaps that would require optimisation flags being marked as such so they can be differentiated from less optional flags; that might be no bad thing anyway from a keeping the flag namespace clean perspective, if a messy change to go through. That itself would be a rather messy change. We've had other problems with problems due to moving things around in the core chicken libraries, too. Oh yeah, we head. Sometimes things have to change. Still we try to maintain backwards compatibility, if possible. Long deprecation phases, change request, etc. Yes, I mean it, even if development sometimes may make the impression of being haphazardly done. I've sent you a mail about compatibility issues regarding ugarit (use of getenv). IIRC, you never replied. I think, overally, we all need to think more about backwards and forwards compatibility when we change the chicken core, so that eggs can work reliably on older versions without needing too many version conditionals! The problem you encountered was not caused by core system changes in this case. And who do you mean with we? And think about? Can't you simply say that this is annoying and you want it to stop? (A statement like the one you make above is mostly ineffective. It's like going into the living room and saying: It would be nice if someone cleaned this mess up! As you will certainly have experienced, nothing is going to happen (unless your family has as a member one of those unfortunate humans that constantly try to fulfill other people's expectations - but I digress...)) So, do you have any suggestions? What can we do better? What are YOU willing to contribute? Could you specify more precisely what you'd like to have? How are the necessary incompatibilities to be introduced? How can we safely distinguish between bugfixes and incompatibilities (probably brought in with the intend of fixing bugs)? How can we keep up fast-paced development and maintenance, and fast response/bugfixing cycles for user reports and feature requests? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
