[Chicken-users] catching a cannot import undefined module error
Hi guys, is there a way to catch cannot import undefined module error? I tried with catch and with-exception-handler procedures, but they don't seems to work. Thanks! Hugo. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching a cannot import undefined module error
From: Hugo Arregui hugo.arre...@gmail.com Subject: [Chicken-users] catching a cannot import undefined module error Date: Sat, 20 Aug 2011 11:59:17 -0300 Hi guys, is there a way to catch cannot import undefined module error? I tried with catch and with-exception-handler procedures, but they don't seems to work. Is this in the interpreter or when compiling a file? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching a cannot import undefined module error
On Aug 20, 2011, at 7:59 AM, Hugo Arregui wrote: Hi guys, is there a way to catch cannot import undefined module error? I tried with catch and with-exception-handler procedures, but they don't seems to work. This is raised as a syntax-error these do not use the exception machinery. (Evaluated in a toplevel context anyway so the actual meaning of (lambda () (import foo) ...) is probably not what one expects.) Maybe if you describe in more detail what you want to accomplish someone can provide a more fulfilling answer. Kon Thanks! Hugo. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching a cannot import undefined module error
Sure, i'm trying to build a script to list all my unsatisfied dependencies (along all my source files), so I can install them (for example: after a chicken upgrade). I'm already get the dependencies, but I need try to load them, so I can kow if they are missing or not. Thanks again! ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] catching a cannot import undefined module error
From: Hugo Arregui hugo.arre...@gmail.com Subject: Re: [Chicken-users] catching a cannot import undefined module error Date: Sat, 20 Aug 2011 16:45:04 -0300 Sure, i'm trying to build a script to list all my unsatisfied dependencies (along all my source files), so I can install them (for example: after a chicken upgrade). I'm already get the dependencies, but I need try to load them, so I can kow if they are missing or not. Is this about extensions? You can use extension-information to check whether a particular extension is installed. 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
-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
