Re: [Chicken-users] import, the utf8 egg, syntax-case and tinyclos
At Thu, 23 Mar 2006 08:55:14 +0100, Sunnan wrote: I want to use the ut8 egg, but when I do it complains that it doesn't know what import is. Adding (require-extension syntax-case) gets rid of that complaint but then instead it complains about my tinyclos methods: This is my preamble: (require-extension syntax-case) (require-extension tinyclos) (require-extension utf8) (declare (uses srfi-1 srfi-13 regex extras)) Hi, I'm not exactly sure what (uses) does, but I don't think you want this line. If you want these features you should just use (require-extension srfi-1 srfi-13 regex) Note that utf8 already provides Unicode-aware regex functions. Also, srfi-13 won't do the right thing with utf8 strings, it'll treat them as byte strings. If you're using utf8, you probably want (require-extension syntax-case tinyclos utf8 utf8-srfi-13) (import utf8) (import utf8-srfi-13) which works fine for me. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] spiffy parameters
On Wed, Mar 22, 2006 at 11:32:17PM -0700, Shawn Rutledge wrote: I found that in the latest version I got an error like this: Error: call of non-procedure: ./web Call history: ... eval (load /etc/spiffy-conf.scm) eval (spiffy-root-path /var/www/localhost/htdocs) -- whereas if I set! spiffy-root-path it works. Was it intentional to quit using parameters and have them be plain variables? I'm curious if there is a reason why using parameters was bad? Blame me :) Implementing an on-the-fly reloadable config file is only possible if you can make all threads aware of the changed options. Parameters are meant to be thread-local, so there's no way to update all threads. Also, there's no way to control which thread handles a signal (I use SIGHUP as the signal to instruct Spiffy to reload the configuration). This is also the reason I decided to update Spiffy's version to 2.0, with the idea that a major version increase communicates a warning that the API has changed in a backward-incompatible way. Of course, we could go back to parameters if anyone has a suggestion how to implement dynamic reconfiguration with them. I decided to add dynamic reconfiguration after adding vhost support, since it is annoying to have to restart the server every time you add a new virtual host. It is also beneficial if you want to change the filetype map or the index page pattern, for example. Regards, Peter -- http://www.student.ru.nl/peter.bex -- 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 pgpSTdcFLxnqa.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] spiffy parameters
On Thu, Mar 23, 2006 at 11:32:29AM +0100, felix winkelmann wrote: Yes, blame him! ;-) Using parameters for all configuration options wasn't such a great idea from the beginning. It makes sense to use parameters, when you want thread-local options, but the spiffy configuration should be applied to all threads anyway. Note that thread-specific parameters are still that: parameters. I have to disagree. They /were/ a very good idea, since they allow you to fire up multiple instances of spiffy with different configurations (like on several ports) from one application. I sacrificed flexibility few people will use for another kind of flexibility more people will use. I think it's a good tradeoff. Regards, Peter -- http://www.student.ru.nl/peter.bex -- 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 pgpa03hp0Ti3L.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] spiffy parameters
On 3/23/06, Peter Bex [EMAIL PROTECTED] wrote: Using parameters for all configuration options wasn't such a great idea from the beginning. It makes sense to use parameters, when you want thread-local options, but the spiffy configuration should be applied to all threads anyway. Note that thread-specific parameters are still that: parameters. I have to disagree. They /were/ a very good idea, since they allow you to fire up multiple instances of spiffy with different configurations (like on several ports) from one application. In that case a configuration object packaging all options would have been the optimal solution. But I think running multiple spiffy instances in the same process isn't such a great idea anyway, opposed to running them in separate processes. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] import, the utf8 egg, syntax-case and tinyclos
At Thu, 23 Mar 2006 02:12:47 -0600, Alex Shinn wrote: I'm not exactly sure what (uses) does, but I don't think you want this line. If you want these features you should just use That's how we always did it when we were kids! I wasn't sure how chicken had changed. But I changed it as per your suggestion. (Same problem, though - I don't think the problem is with the utf-8 egg.) (require-extension srfi-1 srfi-13 regex) Note that utf8 already provides Unicode-aware regex functions. Thanks! Also, srfi-13 won't do the right thing with utf8 strings, it'll treat them as byte strings. If you're using utf8, you probably want I only use the srfi-13 operations on strings which have had their non-ascii characters stripped; but I might change it as per your suggetion to make it less confusing for any possible future maintainers of my code. (require-extension syntax-case tinyclos utf8 utf8-srfi-13) (import utf8) (import utf8-srfi-13) which works fine for me. I still get: Error: unbound variable: clean Call history: ##sys#require ##sys#require make-method add-method -- clean is a method I have defined differentlly for numbers, characters and strings. Works fine when I'm not requiring syntax-case. AML, Sunnan ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users