[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
