Re: [Chicken-users] UTF8 egg case conversion problem

2011-01-16 Thread Alex Shinn
Fixed.

On Tue, Jan 4, 2011 at 8:08 PM, Christian Kellermann
 wrote:
> Dear Alex,
>
> * Alex Shinn  [110104 03:38]:
>> I'll double check some of these cases and release a new
>> version shortly.
>
> While you are at the code, can you change the one 'noop' symbol to
> 'void' since noop has been deprecated in newer chickens.
>
> Changing that makes it work for me and the one word change does not
> seem to be worth a ticket.
>
> Thank you!
>
> Christian
>

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Re: utf8 open tickets

2011-01-16 Thread Alex Shinn
Hi, sorry for the delay.

On Sat, Jan 15, 2011 at 12:30 AM, .alyn.post.
 wrote:
> I have two open tickets against the utf8 egg:
>
>  https://bugs.call-cc.org/ticket/423

I haven't decided how to handle this yet,
but it will probably result in splitting all of
the utf8 modules into separate eggs.

>  https://bugs.call-cc.org/ticket/480

Fixed and committed.

-- 
Alex

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Need help on sxpath/txpath

2011-01-16 Thread Peter Bex
On Sun, Jan 16, 2011 at 03:49:41PM +0900, Daishi Kato wrote:
> Hi,
> 
> I'm porting one of my projects from chicken-3.2.0 to chicken-4.6.0.
> (And thus found a bug in http-client.)
> 
> It seems like the previous sxpath doesn't work on the new one.
> Could anybody help how I can fix this?
> 
> The sxpath worked on chicken-3.2.0 is something like the following:
> 
> ((sxpath "//table/tr[td[a[contains(@href,'&abc=123&')]]]") x)
> 
> On 3.2.0 I used the sxml-tools egg and the sxpath egg on 4.6.0

What is the error you get?  What is the content you run this
expression on?  Can you simplify it to a simple testcase?

My gut feeling is that the & is maybe wrong.  Did you try just '&'?

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
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] http-client and set-cookie

2011-01-16 Thread Peter Bex
On Sun, Jan 16, 2011 at 11:29:16AM +0900, Daishi Kato wrote:
> It worked. Thanks so much.

You're welcome, and thanks for reporting this!  I've tagged a new
http-client version (0.4) containing several other bugfixes as well.

> So, (get-param 'path c) actually returns a uri-common object. I see.

Indeed.  This is documented in the intarweb manual's table of header
types.

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
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Need help on sxpath/txpath

2011-01-16 Thread Daishi Kato
Here you go. --daishi

CHICKEN
(c)2008-2010 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.6.0
linux-unix-gnu-x86 [ manyargs dload ptables ]
compiled 2011-01-11 on spirits (Linux)

#;1> (use sxpath htmlprag utils)
; loading /usr/local/chicken-4.6.0/lib/chicken/5/sxpath.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/chicken.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/scheme.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/data-structures.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/srfi-1.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/srfi-13.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/sxpath-lolevel.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/extras.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/ports.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/txpath.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/htmlprag.import.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/sxpath.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/sxpath-lolevel.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/txpath.so ...
; loading /usr/local/chicken-4.6.0/lib/chicken/5/htmlprag.so ...
; loading library utils ...
#;2> ((sxpath "//table/tr[td[a[contains(@href,'&abc=123&')]]]") 
(html->sxml "yyy"))
()
#;3>


CHICKEN
(c)2008 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 3.2.0 - linux-unix-gnu-x86  [ manyargs dload ptables applyhook ]
SVN rev. 10664  compiled 2008-05-28 on spirits (Linux)

#;1> (use sxml-tools htmlprag utils)
; loading /usr/local/chicken-3.2.0/lib/chicken/3/sxml-tools.so ...
; loading /usr/local/chicken-3.2.0/lib/chicken/3/htmlprag.so ...
; loading library utils ...
#;2> ((sxpath "//table/tr[td[a[contains(@href,'&abc=123&')]]]") 
(html->sxml "yyy"))
((tr (td (a (@ (href "/xxx/yyy/?zzz&abc=123&")) "yyy"
#;3>


At Sun, 16 Jan 2011 13:27:41 +0100,
Peter Bex wrote:
> 
> On Sun, Jan 16, 2011 at 03:49:41PM +0900, Daishi Kato wrote:
> > Hi,
> > 
> > I'm porting one of my projects from chicken-3.2.0 to chicken-4.6.0.
> > (And thus found a bug in http-client.)
> > 
> > It seems like the previous sxpath doesn't work on the new one.
> > Could anybody help how I can fix this?
> > 
> > The sxpath worked on chicken-3.2.0 is something like the following:
> > 
> > ((sxpath "//table/tr[td[a[contains(@href,'&abc=123&')]]]") x)
> > 
> > On 3.2.0 I used the sxml-tools egg and the sxpath egg on 4.6.0
> 
> What is the error you get?  What is the content you run this
> expression on?  Can you simplify it to a simple testcase?
> 
> My gut feeling is that the & is maybe wrong.  Did you try just '&'?
> 
> 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
> http://lists.nongnu.org/mailman/listinfo/chicken-users
> 
> **
>  XREA.COM -Free Web Hosting-
>  http://www.xrea.com/
> **

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Undefined symbols: _C_toplevel (OS X 10.6.6 / Chicken 4.6.0)

2011-01-16 Thread Felix
From: David Dreisigmeyer 
Subject: [Chicken-users] Undefined symbols: _C_toplevel (OS X 10.6.6 / Chicken 
4.6.0)
Date: Sat, 15 Jan 2011 10:03:13 -0500

> void setup (void)
> {
>   CHICKEN_run(C_toplevel);
>   printf("Chicken setup successful");
> }

Should this use `CHICKEN_default_toplevel' ?


cheers,
felix

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Undefined symbols: _C_toplevel (OS X 10.6.6 / Chicken 4.6.0)

2011-01-16 Thread Felix
From: David Dreisigmeyer 
Subject: Re: [Chicken-users] Undefined symbols: _C_toplevel (OS X 10.6.6 / 
Chicken 4.6.0)
Date: Sat, 15 Jan 2011 12:00:43 -0500

> Also, if I use this Makefile:
> 
> CC = gcc-4.2
> CHICKEN_LIB = /usr/local/lib
> LIB = /usr/lib
> CHICKEN_INC = /usr/local/include
> 
> all:
>   $(CC) -fPIC -g -c -m64 -I$(CHICKEN_INC) cython_chicken.c
>   $(CC) -dynamiclib -m64 -L$(LIB) -lm -o libcython_chicken.dylib 
> cython_chicken.o
>   
> I get this instead:
> 
> Undefined symbols:
>   "_CHICKEN_eval_string_to_string", referenced from:
>   _eval in cython_chicken.o
>   "_CHICKEN_run", referenced from:
>   _setup in cython_chicken.o
>   "_C_toplevel", referenced from:
>   _setup in cython_chicken.o

You have to link with -lchicken here.

> 
> So where is C_toplevel defined?

In user-defined code. If you just want to initialize the runtime,
without embedded your own compiled Scheme file, use CHICKEN_default_toplevel.


cheers,
felix

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Undefined symbols: _C_toplevel (OS X 10.6.6 / Chicken 4.6.0)

2011-01-16 Thread Felix
From: David Dreisigmeyer 
Subject: Re: [Chicken-users] Undefined symbols: _C_toplevel (OS X 10.6.6 / 
Chicken 4.6.0)
Date: Sat, 15 Jan 2011 15:19:17 -0500

> Using this:
> 
>   CHICKEN_run(CHICKEN_default_toplevel);
> 
> gets my code running.  This would seem to be fine if I was going to
> evaluate Scheme code interactively from Python ("Embedding" section in
> manual):
> 
> "If you just need a Scheme interpreter, you can also pass
> CHICKEN_default_toplevel as the toplevel procedure, which just uses
> the default library units."
> 
> Am I reading this correctly?
> 

Yes, you are. C_toplevel is defined in normal compiled Scheme modules
generated by the chicken compiler. CHICKEN_default_toplevel is
provided by libchicken.


cheers,
felix

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Re: utf8 open tickets

2011-01-16 Thread Alan Post
On Sun, Jan 16, 2011 at 06:41:34PM +0900, Alex Shinn wrote:
> Hi, sorry for the delay.
> 
> On Sat, Jan 15, 2011 at 12:30 AM, .alyn.post.
>  wrote:
> > I have two open tickets against the utf8 egg:
> >
> >  https://bugs.call-cc.org/ticket/423
> 
> I haven't decided how to handle this yet,
> but it will probably result in splitting all of
> the utf8 modules into separate eggs.
> 

I saw the comment against this ticket, and you make
a valid point.  I consider this a low priority ticket,
so I'm happy to wait for the slower, more correct
solution.


> >  https://bugs.call-cc.org/ticket/480
> 
> Fixed and committed.
> 

Excellent!  Thank you.  The experimental branch is
looking really good.

-Alan
-- 
.i ko djuno fi le do sevzi

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Re: sqlite3 egg still failing in experimental branch

2011-01-16 Thread Alan Post
On Sat, Jan 15, 2011 at 03:51:45PM +0100, Thomas Chust wrote:
> 2011/1/15 Alan Post :
> > 2011/1/14 .alyn.post. :
> >> [...]
> >> The sqlite3 is still failing to compile in the experimental branch:
> >> [...]
> > [...]
> > I believe the attached patch should do it.  I withdraw the original
> > miliseconds deprecation patch (but retain the noop/void patch) and
> > replace it with this one.
> > [...]
> 
> Hello Alan,
> 
> although there was no patch attached to the message, I have now
> checked in modifications to the trunk version of the SQLite3 egg that
> should largely be equivalent to your suggested changes.
> 

I even said: "ok self, make sure you attach the patch to the
e-mail."  I notice that you removed code adding |current-milliseconds|
(presumably now |current-seconds|) to the timeout.  This was
intentional?  I also notice that several division and multiplication
operations in thread-sleep! weren't modified for fixnum--I though
they could be; you understand the code better than I do.

> All tests still run fine under CHICKEN 4.6.3, but I still haven't
> tested with the experimental branch of CHICKEN. I would be grateful if
> you could try it under CHICKEN 4.6.4 and tell me if everything is in
> order, then I would tag a new version of the SQLite3 egg.
> 

There is one test failure I'm seeing:

-- testing statement management
--
basic lifecycle
.. [ERROR]

Error: (finalize!) unable to close due to unfinalised statements:
#
(with-database
  (db ":memory:")
  (let-values
(((stmt tail) (prepare db "SELECT 42; -- tail")))
(dynamic-wind
  noop
  (lambda ()
(let* ((s0 (step! stmt)) (s1 (step! stmt))) (list tail s0 s1)))
  (lambda () (and-let* ((s stmt)) (set! stmt #f) (finalize! s))


I don't properly recall whether this was working earlier or not.  It
doesn't appear to be working currently, however.  For my use of the
sqlite3 egg, I don't believe I'm seeing a problem related to this
test failure, it at least isn't a show stopper for me.

> I hope my sluggish reaction didn't cause you too much trouble :-)
> 

I am very excited that Christian set up a salmonella report for the
experimental branch, it raised my own urgency on getting the sqlite3
egg working.  Thank you so much for taking the time to make these
fixes--it came just as I made some changes that cause my own test
cases to fail, so I'm now causing myself too much trouble.  ;-)

-Alan

PS: Thank you!  Thank you!
-- 
.i ko djuno fi le do sevzi

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Re: sqlite3 egg still failing in experimental branch

2011-01-16 Thread Thomas Chust
2011/1/16 Alan Post :
> [...]
> I notice that you removed code adding |current-milliseconds|
> (presumably now |current-seconds|) to the timeout.  This was
> intentional?
> [...]

Hello Alan,

yes, this was intentional: The way I understand it, thread-sleep! can
either be passed a number, which is interpreted as a delay, or a time
record, which is interpreted as an absolute point in time. But adding
the current time to the delay would of course be wrong.

> [...]
>  I also notice that several division and multiplication operations
> in thread-sleep! weren't modified for fixnum--I though they could
> be; you understand the code better than I do.
> [...]

You're right, these can be fixnum arithmetic, too, if we assume that
the values that will be passed to the created timeout procedure as the
second argument are always going to be fixnums as well, which should
be true.

I have checked in the additional changes to the egg's trunk version.

> [...]
> There is one test failure I'm seeing:
>
>    -- testing statement management
> --
>    basic lifecycle
> .. [ERROR]
>
> Error: (finalize!) unable to close due to unfinalised statements:
> #
>    (with-database
>      (db ":memory:")
>      (let-values
>        (((stmt tail) (prepare db "SELECT 42; -- tail")))
>        (dynamic-wind
>          noop
>          (lambda ()
>            (let* ((s0 (step! stmt)) (s1 (step! stmt))) (list tail s0 s1)))
>          (lambda () (and-let* ((s stmt)) (set! stmt #f) (finalize! s))
>
> [...]

Hmm, I can't reproduce that test failure under CHICKEN 4.6.3. It's
also pretty strange since the statement obviously *is* finalized
explicitly by that code.

> [...]
> PS: Thank you!  Thank you!
> [...]

And thank you, too, for coming up with the patches in the first place
:-)

Ciao,
Thomas


-- 
When C++ is your hammer, every problem looks like your thumb.

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] coops

2011-01-16 Thread schugk

Hi,

i am playing around with coops and have some problems with  and  
. I know that are fixed in version 1.1 but i can download 1.0  
only via chicken-install.


The next point is that the performance is not as good as expected. Are  
there any tricks? For example i have a method 'satisfy' with 2  
parameters. The first is specialized for some classes, the second is  
always a list.


(define-methode (satisfy (p ) (e #t)) ...)
(define-methode (satisfy (p ) (e #t)) ...)

Is it better to specialize the second argument too or switch the order  
of arguments?


Thank you in advance,
Sandro


___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] coops

2011-01-16 Thread Felix
From: sch...@uni-potsdam.de
Subject: [Chicken-users] coops
Date: Mon, 17 Jan 2011 03:39:45 +0100

> Hi,
> 
> i am playing around with coops and have some problems with  and
> . I know that are fixed in version 1.1 but i can download 1.0
> only via chicken-install.

The version you install is 1.1, but it is incorrectly specified in
coops.setup. I have fixed this and tagged a new version (1.2).
Thanks for reporting this.

> 
> The next point is that the performance is not as good as expected. Are
> there any tricks? For example i have a method 'satisfy' with 2
> parameters. The first is specialized for some classes, the second is
> always a list.
> 
> (define-methode (satisfy (p ) (e #t)) ...)
> (define-methode (satisfy (p ) (e #t)) ...)
> 
> Is it better to specialize the second argument too or switch the order
> of arguments?

You have to try it out. Performance largely depends on how well the
internal method-call cache can be utilized. Repeated calls of the same
method will cache the result of method-lookup, otherwise the method
has to be looked up (and parameter classes be matched), which is a
costly process. Do you use high optimization switches?


cheers,
felix

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users