Re: [Chicken-users] import, the utf8 egg, syntax-case and tinyclos

2006-03-23 Thread Alex Shinn
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

2006-03-23 Thread Peter Bex
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

2006-03-23 Thread Peter Bex
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

2006-03-23 Thread felix winkelmann
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

2006-03-23 Thread Sunnan
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