Re: [Chicken-users] Help solving this phasing problem.

2011-02-12 Thread Taylor Venable
On Sat, Feb 12, 2011 at 16:51, Peter Bex  wrote:
> This imports module-a (which can be internal and nobody has to know it's
> there) both for syntax and normally, and then re-exports the convenience
> function.

Pardon the interruption, but I wanted to check for my own
understanding: is import-for-syntax roughly the Chicken equivalent of
the (import (for (module-a) expand)) from chapter 7 of R6RS? (That may
be an oversimplification on my part, this gets into some of the parts
of Scheme I don't understand very well yet.)

Thanks,

-- 
Taylor C. Venable
http://metasyntax.net/

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


[Chicken-users] Using -accumulate-profile

2011-01-17 Thread Taylor Venable
Hi there, I'm building a program with csc and it's running slower than I'd
hoped so I'm trying to do some profiling. I tried using the
-accumulate-profile option to concatenate information from multiple runs of
the program but it seems to produce the same result as just using -profile
(i.e. multiple PROFILE. files, each containing information from a
single run). I thought maybe I had to explicitly set the profile file name
using -profile-name but that doesn't help (it changes the stem (i.e.
. with -profile-name ) but still multiple executions create
multiple files). I'm using 4.6.3 on 64-bit Linux: "linux-unix-gnu-x86-64 [
64bit manyargs dload ptables ]". I had thought from reading the doc that
using -accumulate-profile would build up a single profile output file
containing information for numerous successive executions; is that not
correct? Thanks for any advice (pointers to any general tips on profiling
and optimizing in Chicken also greatly appreciated).

-- 
Taylor C. Venable
http://metasyntax.net/
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Question about COOPS, generic methods, and modules

2010-09-22 Thread Taylor Venable
Hi there!

I found this while writing some code for work earlier (I'm lucky enough to
be able to write testing programs in the language of my choice). I define a
class and a generic method in a module in a file, then load it into the
REPL. I can make an instance of that class, binding it to a variable at the
toplevel, and use the generic method just fine. If I then reload my code, I
cannot use the generic method with the bound instance: I get the "no method
defined for given argument classes" error. If my class and generic method
definitions are not in a module, everything works fine. I'm wondering if
this is me misunderstanding something, or it is intentional behaviour, or
maybe it's a bug. Here is a concrete example:

;; FILE: coops-test-1.scm

(define-class  ()
  ((a 2) (b 3)))

(define-method (lols (instance ))
  (+ (slot-value instance 'a) (slot-value instance 'b)))

;; FILE: coops-test-2.scm

(module foo
  (
   lols)

  (import scheme chicken coops)

  (define-class  ()
((a 2) (b 3)))

  (define-method (lols (instance ))
(+ (slot-value instance 'a) (slot-value instance 'b)))
)



#;1> (use coops)
; loading /opt/chicken/lib/chicken/5/coops.import.so ...
; loading /opt/chicken/lib/chicken/5/scheme.import.so ...
; loading /opt/chicken/lib/chicken/5/chicken.import.so ...
; loading /opt/chicken/lib/chicken/5/matchable.import.so ...
; loading /opt/chicken/lib/chicken/5/srfi-1.import.so ...
; loading /opt/chicken/lib/chicken/5/data-structures.import.so ...
; loading /opt/chicken/lib/chicken/5/extras.import.so ...
; loading /opt/chicken/lib/chicken/5/record-variants.import.so ...
; loading /opt/chicken/lib/chicken/5/foreign.import.so ...
; loading /opt/chicken/lib/chicken/5/coops.so ...
#;2> (load "coops-test-1.scm")
; loading coops-test-1.scm ...

Note: implicitly defining generic-procedure: lols
#;3> (define instance (make ))
#;4> (lols instance)
5
#;5> (load "coops-test-1.scm")
; loading coops-test-1.scm ...
#;6> (lols instance)
5



#;1> (use coops)
; loading /opt/chicken/lib/chicken/5/coops.import.so ...
; loading /opt/chicken/lib/chicken/5/scheme.import.so ...
; loading /opt/chicken/lib/chicken/5/chicken.import.so ...
; loading /opt/chicken/lib/chicken/5/matchable.import.so ...
; loading /opt/chicken/lib/chicken/5/srfi-1.import.so ...
; loading /opt/chicken/lib/chicken/5/data-structures.import.so ...
; loading /opt/chicken/lib/chicken/5/extras.import.so ...
; loading /opt/chicken/lib/chicken/5/record-variants.import.so ...
; loading /opt/chicken/lib/chicken/5/foreign.import.so ...
; loading /opt/chicken/lib/chicken/5/coops.so ...
#;2> (load "coops-test-2.scm")
; loading coops-test-2.scm ...

Note: implicitly defining generic-procedure: lols
#;3> (import foo)
#;4> (define instance (make ))
#;5> (lols instance)
5
#;6> (load "coops-test-2.scm")
; loading coops-test-2.scm ...

Note: implicitly defining generic-procedure: lols
#;7> (lols instance)

Error: (lols) no method defined for given argument classes: (#'>)

Call history:

  (lols instance)
(lols instance)   <--

I'm using Chicken 4.6.1 (git 7ac10a2fb9b04d114af97d8c9918bffae38cc534) on
Linux AMD64 with COOPS 0.8 to test this. I notice that you get the warning
about automatically defining the generic method twice, at each load, maybe
that's indicative of the problem? Is there a way to make this work? Thanks.

-- 
Taylor C. Venable
http://metasyntax.net/
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] More on Packaging eggs

2010-09-13 Thread Taylor Venable
On Mon, Sep 13, 2010 at 7:44 PM, Taylor Venable wrote:

> On Mon, Sep 13, 2010 at 9:02 AM, Mario Domenech Goulart <
> mario.goul...@gmail.com> wrote:
>
>> Those are bugs.  The version indicated by the .setup file doesn't match
>> the one indicated by the tag directory.
>>
>
> We had this problem with the packaging system I wrote for work; there we
> have a scanning program that I run periodically to e.g. verify that things
> like this match up (the Subversion location to the "recipe" version as we
> say). It can even attempt to use Subversion to find out who is responsible
> so they can be notified. I can reinvent that for the Egg repository if
> people think that would be useful. :-)
>
> --
> Taylor C. Venable
> http://metasyntax.net/
>

I went ahead and threw together a little program just to see if I could do
it quickly; it turned out to be a fun exercise. It's on my Mercurial at
http://bitbucket.org/taylor_venable/metasyntax/src/tip/Programs/egg-scan.scm

The results (filtered out to show mismatches that the program can detect -
anything resulting from defining and then using a variable for the version
would currently go unnoticed) are attached.

-- 
Taylor C. Venable
http://metasyntax.net/
  Error: sdl version mismatch - expected 0.5.0found 
v0.4.51117.5
  Error: sdl version mismatch - expected 0.5.1found 
v0.5.1  
  Error: peepversion mismatch - expected 0.2.2found 
0.3 
  Error: imlib2  version mismatch - expected 0.7  found 
0.6 
  Error: utf8version mismatch - expected 3.1.0found 
3.0.0   
  Error: srfi-42 version mismatch - expected 1.61 found 
1.6 
  Error: lalrversion mismatch - expected 2.3.1found 
2.3.0   
  Error: setup-helperversion mismatch - expected 1.1.0found 
1.0.0   
  Error: srfi-41 version mismatch - expected 1.0.2found 
1.0.0   
  Error: srfi-41 version mismatch - expected 1.0.1found 
1.0.0   
  Error: srfi-41 version mismatch - expected 1.0.3found 
1.0.0   
  Error: chicken-doc-admin   version mismatch - expected 0.3.9found 
0.3.8   
  Error: php-s11nversion mismatch - expected 1.0.2found 
1.0.1   
  Error: sandbox version mismatch - expected 1.6  found 
1.41
  Error: npdiff  version mismatch - expected 1.11 found 
1.1 
  Error: npdiff  version mismatch - expected 1.10 found 
1.1 
  Error: linenoise   version mismatch - expected 0.2  found 
0.1 
  Error: format-textdiff version mismatch - expected 1.5  found 
1.6 
  Error: syslog  version mismatch - expected 1.0  found 
0.1 
  Error: http-sessionversion mismatch - expected 2.0  found 
2.0.0   
  Error: uri-generic version mismatch - expected 1.10 found 
1.1 
  Error: qt  version mismatch - expected 0.100found 
0.1 
  Error: fmt version mismatch - expected 0.700found 
0.7 
  Error: fmt version mismatch - expected 0.520found 
0.52
  Error: interp1dversion mismatch - expected 1.10 found 
1.1 
  Error: dictversion mismatch - expected 2.1  found 
2.0 
  Error: foreigners  version mismatch - expected 1.1  found 
1.0 
  Error: svn-client  version mismatch - expected 0.11 found 
0.10
  Error: unitconvversion mismatch - expected 1.8  found 
1.7 
  Error: sendfileversion mismatch - expected 1.6.0found 
1.5.2   
  Error: z3  version mismatch - expected 1.40 found 
1.4 
  Error: lru-cache   version mismatch - expected 0.5.2found 
0.5 
  Error: lru-cache   version mismatch - expected 0.5.1found 
0.5 
  Error: html-form   version mismatch - expected 1.2.1found 
1.2 
  Error: specialized-io  version mismatch - expected 1.1  found 
1.0 
  Error: json-abnf   version mismatch - expected 3.0  found 
1.3 
  Error: elliptic-curves version mismatch - expected 1.0.1found 
1.0.0   
  Error: sqlite3 version mismatch - expected 3.3.0found 
3.2.1   
  Error: loopversion mismatch - expected 0.2  found 
1.2 
  Error: matrix-utilsversion mismatch - expected 1.10 found 
1.1 
  Error: check-errorsversion mismatch - expected 1.1.0found 
1.0.0 

Re: [Chicken-users] More on Packaging eggs

2010-09-13 Thread Taylor Venable
On Mon, Sep 13, 2010 at 9:02 AM, Mario Domenech Goulart <
mario.goul...@gmail.com> wrote:

> Those are bugs.  The version indicated by the .setup file doesn't match
> the one indicated by the tag directory.
>

We had this problem with the packaging system I wrote for work; there we
have a scanning program that I run periodically to e.g. verify that things
like this match up (the Subversion location to the "recipe" version as we
say). It can even attempt to use Subversion to find out who is responsible
so they can be notified. I can reinvent that for the Egg repository if
people think that would be useful. :-)

-- 
Taylor C. Venable
http://metasyntax.net/
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Printing circular lists

2010-08-03 Thread Taylor Venable
On Tue, Aug 3, 2010 at 4:03 PM, Jeronimo Pellegrini  wrote:
> I was wondering how to get Chicken to print cyclic structures
> using references to previous elements instead of looping, like
> this, for example (this is what Gauche does on the REPL, and
> what Guile's display implementation does):
>
>  > a
>  #0=(1 . #0#)
>
> Is there some way to configure Chicken to do that? (I've searched
> the wiki but found nothing)

If you're open to using a different method to do so, both the fmt and
srfi-38 eggs provide such a means via fmt and
write-with-shared-structure, respectively.

#;1> (use fmt)
; loading /opt/chicken/lib/chicken/5/fmt.import.so ...
; loading /opt/chicken/lib/chicken/5/srfi-1.import.so ...
; loading /opt/chicken/lib/chicken/5/srfi-13.import.so ...
; loading /opt/chicken/lib/chicken/5/srfi-69.import.so ...
; loading /opt/chicken/lib/chicken/5/extras.import.so ...
; loading /opt/chicken/lib/chicken/5/fmt.so ...
#;2> (define a (list 1 2))
#;3> (set-cdr! a a)
#;4> (fmt #f a)
"#0=(1 . #0#)"

#;1> (use srfi-38)
; loading /opt/chicken/lib/chicken/5/srfi-38.import.so ...
; loading /opt/chicken/lib/chicken/5/extras.import.so ...
; loading /opt/chicken/lib/chicken/5/srfi-38.so ...
#;2> (define a (list 1 2))
#;3> (set-cdr! a a)
#;4> (write-with-shared-structure a) (newline)
#=0(1 . #0#)

-- 
Taylor C. Venable
http://metasyntax.net/

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


[Chicken-users] Interpreter Warnings w/ Line Numbers?

2010-07-30 Thread Taylor Venable
Hi there, when loading bad code into the interpreter, I get warnings.
Is it possible to have line numbers printed for where these warnings
are triggered?  Sometimes a message like "reference to possibly
unbound identifier: x" is hard to trace down if I use variable x a lot
in the code.  Just to be complete in my question, here is an example
of what I'm talking about:

file test.scm:

(module foo
  (foo)

  (import scheme)

  (define (foo)
(+ x y))

  (define (bar)
(display "I am displaying something.")
(newline))
)

 5831 [ taylor @ zareason ] : ~ > csi -no-init

CHICKEN
(c)2008-2010 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.5.6
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
compiled 2010-07-13 on zareason (Linux)

#;1> (load "test.scm")
; loading test.scm ...
; loading /opt/chicken/lib/chicken/5/scheme.import.so ...

Warning: reference to possibly unbound identifier: y

Warning: reference to possibly unbound identifier: x

Error: module unresolved: foo

Call history:

[foo] (##core#begin (+ x y))
[foo] (+ x y)
(define (bar) (display "I am
displaying something.") (newline))
(##core#set! bar (##core#lambda ()
(display "I am displaying something.") (newline)))
(##core#lambda () (display "I am
displaying something.") (newline))
[bar] (##core#begin (display "I am
displaying something.") (newline))
[bar] (display "I am displaying something.")
[bar] (newline) <--

-- 
Taylor C. Venable
http://metasyntax.net/

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


Re: [Chicken-users] Spiffy Question: handle-not-found

2010-02-15 Thread Taylor Venable
On Sun, 2010-02-14 at 18:17 +0100, Peter Bex wrote:
> On Sun, Feb 14, 2010 at 11:39:18AM -0500, Taylor Venable wrote:
> > The Spiffy documentation says about the value of handle-not-found: "It
> > is a procedure of one argument, the path (a string) that was requested."
> > However, it seems that the actual argument is the path, up until the
> > first component which was not found. If root-path does not exist, path
> > is always "/". If root-path does exist, but neither "foo" nor "asdf"
> > exist within it, then path is always "/foo" or "/asdf". That's what it
> > seems to be, anyway; is that the correct behaviour?
> 
> If nobody objects, I could change the handler to pass the remaining path
> to (handle-not-found) as a second argument.  Unfortunately this would be
> a backwards-incompatible change, though.  This would be a list of
> remaining path components.

No need to make a breaking change on my account, I've got what I need by
using intarweb and uri-common.  I just noticed an incongruity between my
understanding of the doc and the actual behavior, trying to figure out
which one was "right."

> Recently there have been a few new eggs created for dispatching URIs.
> You might find those interesting:
> http://chicken.wiki.br/eggref/4/spiffy-uri-match
>  (or more generally http://chicken.wiki.br/eggref/4/uri-match )
> http://chicken.wiki.br/eggref/4/uri-dispatch
> 
> and a more generic web framework was created as well:
> http://chicken.wiki.br/eggref/4/awful
> 
> If you prefer simplicity, you could also use Andrew Wright's pattern
> matcher on the uri-path:
> http://chicken.wiki.br/eggref/4/matchable

Sweet, these look useful.  Fortunately my app is pretty simple right
now, but if it gets more complicated these will definitely help.

Thanks for the insight.

-- 
Taylor Venable
http://metasyntax.net/



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


Re: [Chicken-users] Spiffy Question: handle-not-found

2010-02-14 Thread Taylor Venable
I made a mistake when copying this example from the real source code; it
should have read:

> (handle-not-found
>   (lambda (path)
> (log-to (debug-log) "REQUEST: ~s" path)
> (cond ((string=? path "/foo/bar"); s/uri/path/
>(x))
>   ((string=? path "/asdf/jkl")   ; s/uri/path/
>(y))
>   (else
>(handle-other)

Where x and y do their own header setup, and write their own output.

-- 
Taylor Venable
http://metasyntax.net/



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


[Chicken-users] Spiffy Question: handle-not-found

2010-02-14 Thread Taylor Venable
Hi, I'm using Spiffy and setting handle-not-found in an attempt to use
Spiffy like a generic URL-based dispatcher.  For example, when the user
requests /foo/bar I want to send back the result of calling function x,
and when the user requests /asdf/jkl I want to send back the result of
calling function y:

(handle-not-found
  (lambda (path)
(log-to (debug-log) "REQUEST: ~s" path)
(cond ((string=? uri "/foo/bar")
   (x))
  ((string=? uri "/asdf/jkl")
   (y))
  (else
   (handle-other)

The Spiffy documentation says about the value of handle-not-found: "It
is a procedure of one argument, the path (a string) that was requested."
However, it seems that the actual argument is the path, up until the
first component which was not found. If root-path does not exist, path
is always "/". If root-path does exist, but neither "foo" nor "asdf"
exist within it, then path is always "/foo" or "/asdf". That's what it
seems to be, anyway; is that the correct behaviour? It seems to be
slightly different from what the documentation says, since it is not
necessarily the requested path.

In the meantime I've been using this code as a workaround to get what I
want regardless of the existence of files in the path:

(string-join (cdr (uri-path (request-uri (current-request "/" 'prefix)

Thanks for the clarification,

-- 
Taylor Venable
http://metasyntax.net/



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


Re: [Chicken-users] Problem trying to use SSAX

2009-10-23 Thread Taylor Venable
On Fri, Oct 23, 2009 at 09:03:58AM +0200, Peter Bex wrote:
> On Thu, Oct 22, 2009 at 10:10:14PM -0400, Taylor Venable wrote:
> > Error: unbound variable: ssax:scan-Misc
> > 
> > I can't see the problem in my code, if there is one; I'm just starting  
> > to work with this so any ideas are appreciated.  Thank you.
> 
> This probably has something to do with the module exports.  I don't
> fully understand module exports for macros.  Please try the attached
> patch.  I will be gone during the weekend, so if it doesn't work,
> perhaps other people can help.

Thanks for the tip-off.  After exercising a bit more of the ssax egg's
functionality, I came up with a list of the things that I at least
needed to add to the export list to get it to work.  Being rather new
to the way eggs work, I've not the faintest idea of whether this is
the right way to fix it or not, but at least I got it to function.

Patch attached.

-- 
Taylor Venable
http://metasyntax.net/
Index: ssax-chicken.scm
===
--- ssax-chicken.scm(revision 16243)
+++ ssax-chicken.scm(working copy)
@@ -3,7 +3,7 @@
 
 (module ssax
 
-((ssax:make-parser fold)
+((ssax:make-parser fold ssax:scan-Misc ssax:Prefix-XML ssax:complete-start-tag 
ssax:read-char-data ssax:assert-token ssax:warn parser-error 
ssax:skip-internal-dtd ssax:ncname-starting-char? ssax:skip-pi ssax:skip-S 
ssax:S-chars ssax:read-external-id ssax:read-QName ssax:read-markup-token 
ssax:handle-parsed-entity)
  (ssax:make-pi-parser fold)
  (ssax:make-elem-parser fold)
  ssax:xml->sxml)
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Problem trying to use SSAX

2009-10-22 Thread Taylor Venable
Hi, I'm trying to use the ssax Egg for the first time, and running  
into troubles with an example taken from Oleg's site: http://okmij.org/ftp/Scheme/remove-markup.scm


When I try to run my code:



(require-extension ssax)

(define run2
  (lambda (file)
(let ((p (open-input-file file)))
  ((ssax:make-parser
NEW-LEVEL-SEED
(lambda (elem-gi attributes namespaces expected-content seed)
  seed)

FINISH-ELEMENT
(lambda (elem-gi attributes namespaces parent-seed seed)
  seed)

CHAR-DATA-HANDLER
(lambda (string1 string2 seed)
  (let* ((seed (cons string1 seed)))
(if (string-null? string2) seed
(cons string2 seed
) p '()

(let ((sxml (run2 "request.xml")))
  (display sxml)
  (newline))



I get this error:

-

CHICKEN
(c)2008-2009 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.2.2 - SVN rev. 15455
macosx-unix-gnu-x86-64 [ 64bit manyargs dload ptables applyhook ]
compiled 2009-10-22 on taylor-venables-mac-mini.local (Darwin)

; loading sdi.scm ...
; loading /usr/local/lib/chicken/4/ssax.import.so ...
; loading /usr/local/lib/chicken/4/scheme.import.so ...
; loading /usr/local/lib/chicken/4/chicken.import.so ...
; loading /usr/local/lib/chicken/4/ports.import.so ...
; loading /usr/local/lib/chicken/4/srfi-13.import.so ...
; loading /usr/local/lib/chicken/4/extras.import.so ...
; loading /usr/local/lib/chicken/4/srfi-1.import.so ...
; loading /usr/local/lib/chicken/4/input-parse.import.so ...
; loading /usr/local/lib/chicken/4/ssax.so ...
; loading /usr/local/lib/chicken/4/input-parse.so ...

Error: unbound variable: ssax:scan-Misc

Call history:

  (display sxml)
  (newline)
  (run2 "request.xml")
(run2 "request.xml")
[run2] (open-input-file file)
			[run2] ((ssax:make-parser NEW-LEVEL-SEED (lambda (elem-gi  
attributes namespaces expected-content seed) seed..

[run2] (scan-for-significant-prolog-token-1630 
port607 seed608)
			[scan-for-significant-prolog-token-1630] (ssax:scan-Misc633  
port607)	<--


-

I can't see the problem in my code, if there is one; I'm just starting  
to work with this so any ideas are appreciated.  Thank you.


Taylor Venable
http://metasyntax.net/



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


Re: [Chicken-users] testing release candidate for 4.0.0

2009-03-25 Thread Taylor Venable
On Wed, Mar 25, 2009 at 04:31:24PM +0100, felix winkelmann wrote:
> I tested it on several systems (mingw(+msys), linux), but would
> appreciate if others could give it a try. Note that some minor
> recent trunk changes didn't make it, due to unclear portability.

On OpenBSD 4.5 x86:

Compiles both from the distributed C files, and also from C files
generated (by Chicken 4) from the Scheme code.

I get the following when running "make fullcheck" --

==

gmake -f ./Makefile.bsd dist
gmake[2]: Entering directory `/home/taylor/Source/Lisp/chicken-4.0.0'
csi -s ./scripts/makedist.scm --platform=bsd CHICKEN=chicken

Error: (open-input-file) cannot open file - No such file or directory: 
"./scripts/makedist.scm"
gmake[2]: *** [dist] Error 70
gmake[2]: Leaving directory `/home/taylor/Source/Lisp/chicken-4.0.0'
gmake[1]: *** [compiler-check] Error 2
gmake[1]: Leaving directory `/home/taylor/Source/Lisp/chicken-4.0.0'
gmake: *** [fullcheck] Error 2

==

When issuing "make check" it runs to completion and appears to be
successful (I notice no failures; but I'd be happy to supply a
transcript if requested).

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-23 Thread Taylor Venable
On Mon, Mar 23, 2009 at 08:48:50AM +0900, Ivan Raikov wrote:
>   I doubt this is the case, since the regex unit is almost identical
> between Chicken 3 and Chicken 4. Taylor, can you compile Chicken with
> the attached regex.scm and see if there is any routine from the regex
> unit that is called at the point when the build process gets stuck?

I can trigger the bug using Chicken 3.4.7 when compiled with the
supplied regex.scm file (again I can do this by varying the -:s
parameter until it gets stuck).

A backtrace from GCC is attached (it continues to repeat through many
frames after the output given).  It exhibits behaviour similar to that
when using the regex.scm that comes with Chicken 3.4.7 normally.  The
regex.c file which is generated is on my website at:

http://real.metasyntax.net:2357/tmp/regex-pcre.c.gz

(Probably just my ignorance talking here again, but even though the
header on the file says PCRE, there are a lot of references to irregex
scattered throughout that file.)

Thanks for the continued time to try to solve this,

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/
(gdb) run utils.scm -quiet -no-trace -optimize-level 2 -include-path . 
-include-path ./ -explicit-use -output-file utils.c -:s74k -:d
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/taylor/Desktop/chicken-3.4.7/chicken utils.scm -quiet 
-no-trace -optimize-level 2 -include-path . -include-path ./ -explicit-use 
-output-file utils.c -:s74k -:d
[debug] application startup...
[debug] heap resized to 50 bytes
[debug] stack bottom is 0x7fff909c2ae0.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] entering toplevel data_structures_toplevel...
[debug] entering toplevel ports_toplevel...
[debug] entering toplevel extras_toplevel...
[debug] entering toplevel srfi_69_toplevel...
[debug] entering toplevel srfi_1_toplevel...
[debug] entering toplevel match_toplevel...
[debug] entering toplevel srfi_4_toplevel...
[debug] entering toplevel utils_toplevel...
[debug] entering toplevel regex_toplevel...
[debug] entering toplevel files_toplevel...
[debug] resizing heap dynamically from 500k to 1000k ...
[debug] resizing heap dynamically from 1000k to 2000k ...
[debug] resizing heap dynamically from 2000k to 4000k ...
[debug] resizing heap dynamically from 4000k to 8000k ...
[debug] resizing heap dynamically from 8000k to 16000k ...
[debug] resizing heap dynamically from 16000k to 32000k ...
[debug] resizing heap dynamically from 32000k to 64000k ...
[debug] resizing heap dynamically from 64000k to 128000k ...
[debug] resizing heap dynamically from 128000k to 256000k ...
[debug] resizing heap dynamically from 256000k to 512000k ...
^C
Program received signal SIGINT, Interrupt.
0x7f9c883adfcf in f_12537 (c=2, t0=140735619528656, t1=14680074) at 
regex.c:10326
10326   ((C_proc3)(void*)(*((C_word*)t3+1)))(3,t3,t2,((C_word*)t0)[2]);}
(gdb) bt
#0  0x7f9c883adfcf in f_12537 (c=2, t0=140735619528656, t1=14680074) at 
regex.c:10326
#1  0x7f9c881677e2 in f_3920 (c=3, t0=140309752394536, t1=140735619528656, 
t2=140309752479688) at library.c:34139
#2  0x7f9c883aded8 in f_12517 (t0=140735619529008, t1=6) at regex.c:10312
#3  0x7f9c883add3a in f_12551 (c=2, t0=140735619529056, t1=14680074) at 
regex.c:10287
#4  0x7f9c881677e2 in f_3920 (c=3, t0=140309752394536, t1=140735619529056, 
t2=140309752479688) at library.c:34139
#5  0x7f9c883adbe6 in f_12555 (c=2, t0=140735619529352, t1=140735619533232) 
at regex.c:10267
#6  0x7f9c88167a01 in f_3890 (c=3, t0=140309752393464, t1=140735619529352, 
t2=140309752479688) at library.c:34178
#7  0x7f9c883ad9e5 in f_12360 (t0=140735619529888, t1=6) at regex.c:10251
#8  0x7f9c883ad450 in f_12579 (c=2, t0=140735619529976, t1=140735619533232) 
at regex.c:10198
#9  0x7f9c88167a01 in f_3890 (c=3, t0=140309752393464, t1=140735619529976, 
t2=140309752479688) at library.c:34178
#10 0x7f9c883ad2f4 in f_12332 (t0=140735619530240, t1=140735619531152, 
t2=140309752479688, t3=14) at regex.c:10181
#11 0x7f9c883acfc3 in f_12327 (c=2, t0=140735619530512, t1=14679818) at 
regex.c:10156
#12 0x7f9c8816794c in f_3900 (c=3, t0=140309752393432, t1=140735619530512, 
t2=140735619531040) at library.c:34165
#13 0x7f9c883acdfe in f_12324 (c=2, t0=140735619530776, t1=10) at 
regex.c:10140
#14 0x7f9c88167a01 in f_3890 (c=3, t0=140309752393464, t1=140735619530776, 
t2=140735619531040) at library.c:34178
#15 0x7f9c883accc1 in f_12123 (t1=140735619531152, t2=140309752479688, 
t3=140735619531040) at regex.c:10127
#16 0x7f9c883b0994 in f_12126 (t1=140735619531152, t2=140309752479688, 
t3=140735619533728, t4=29) at regex.c:10829
#17 0x7f9c883aed75 in f_12439 (t0=140735619531280, t1=140309752479688) at 
regex.c:10468
#18 0x7f9c883aec5d in f_12436 (t0=140735619531488, t1=140309752479688) at 
regex.c:10454

Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-23 Thread Taylor Venable
On Mon, Mar 23, 2009 at 09:51:08AM +0100, Tobia Conforto wrote:
> Taylor Venable wrote:
>> When building Chicken 3.4.7 and higher (up to 3.5.2) on Ubuntu 8.10  
>> x86_64 the chicken compiler goes into an infinite recursion.
>
> Excuse my ignorance, how do I check out a version such as 3.4.7 or  
> 3.5.2? I cannot find the relevant tag or branch. Should I look for a log 
> message and checkout a specific release? If so, in which branch?

They're in the "development snapshots" area which is linked from the
releases page: http://chicken.wiki.br/dev-snapshots/

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Missing chicken-ffi-macros.scm

2009-03-21 Thread Taylor Venable
On Fri, Mar 20, 2009 at 12:17:20PM -0500, Lam Luu wrote:
> Do you know what is going on, and how to fix it?

I saw this also with the Chicken package on Ubuntu.  If you compile
and install from source this shouldn't happen.  (Don't worry, it's
quite painless to install from source.)

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-18 Thread Taylor Venable
On Wed, Mar 18, 2009 at 10:38:30AM +0100, felix winkelmann wrote:
> Could you try to build chicken 4? (possibly twice, building the compiler
> with the compiler built from the bootstrap tarball - so that you are really
> testing the newest version and not some stale code in the bootstrapping
> tarball).

Chicken 4 builds just fine, and I cannot get the bug to appear there
even with a variance of -:s options.

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-17 Thread Taylor Venable
On Mon, Mar 16, 2009 at 09:36:28PM -0400, Taylor Venable wrote:
> Since regex.c seems heavily involved in this last case, I've also put
> it on my website at: http://real.metasyntax.net:2357/tmp/regex.c.gz

Looking back at the changes log for the devel releases, I just noticed
that the first version that I have this problem in is 3.4.7 which is
when irregex replaced PCRE.

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-16 Thread Taylor Venable
On Mon, Mar 16, 2009 at 09:09:41PM +0100, felix winkelmann wrote:
> Well done, Taylor. Chicken coalesces all allocations inside a single
> generated C procedure and allocates it as one chunk. It seems here
> that the stack is already too small to hold the data, even after a minor
> GC was invoked. Can you reproduce the hang with larger settings for
> "-:s..."? If you add "-:d", you should see messages like
> 
> [debug] stack resized to  bytes
> 
> If you can't reproduce the hang with higher settings, change the makefile
> (defaults.make or rules.make and pass "-:s" to the "chicken-boot"
> invocations and look how far it gets (BTW, what does "./chicken-boot -:d" 
> show?)
> Then we probably have a precompiled bootstrapping compiler with a too
> low nursery setting, even though this used to work. It also may be something
> completely different.

Yes, now that I've tried these things I think that what I've run into
during the build process initially is different from the small stack
size that I've been using for this.  Or in other words I think there
may be two separate problems here, or at least I've figured out how to
get the program to hang in two different conditions.

First, here is the output with -:d for what proceeds normally.  Note
that with this build (done with "make PLATFORM=linux DEBUG_BUILD=yes
bootstrap") the original scenario works.

[debug] application startup...
[debug] heap resized to 50 bytes
[debug] stack bottom is 0x7fffce663a60.
[debug] entering toplevel toplevel...
[debug] stack resized to 262144 bytes
[debug] entering toplevel library_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] entering toplevel data_structures_toplevel...
[debug] entering toplevel ports_toplevel...
[debug] entering toplevel extras_toplevel...
[debug] entering toplevel srfi_69_toplevel...
[debug] entering toplevel srfi_1_toplevel...
[debug] entering toplevel match_toplevel...
[debug] entering toplevel srfi_4_toplevel...
[debug] entering toplevel utils_toplevel...
[debug] entering toplevel regex_toplevel...
[debug] entering toplevel files_toplevel...
[debug] entering toplevel support_toplevel...
[debug] resizing heap dynamically from 500k to 1040k ...
[debug] entering toplevel compiler_toplevel...
[debug] entering toplevel optimizer_toplevel...
[debug] entering toplevel driver_toplevel...
[debug] entering toplevel platform_toplevel...
[debug] entering toplevel backend_toplevel...
[debug] resizing heap dynamically from 1040k to 2081k ...
[debug] resizing heap dynamically from 2081k to 4163k ...
[debug] forcing finalizers...
[debug] resizing heap dynamically from 4163k to 2081k ...

Now, here's the output when I add -:s10k to that:

[debug] application startup...
[debug] heap resized to 50 bytes
[debug] stack bottom is 0x7fff275a99d0.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...

The last line repeats forever until I kill it.  There is no marked
increase in memory consumption.

HOWEVER I did figure out how to reproduce it for higher values of -:s
using a script that just stepped through trying increasing values
until it hung.  There are several that I found; both -:s74k and
-:s262k trigger it.  The GDB output from the latter case is attached.
Note that the backtrace gets larger and larger the longer you let it
run, and it repeats (starting at frame #57 <-> #16).

The behaviour in this last case seems different than that of the
-:s10k case.  The former never grew the heap, but continually called
the GC process.  But the latter is constantly growing the heap and as
a result the memory usage balloons.  I couldn't say if they're both
reflections of the same problem or if they're different.

Since regex.c seems heavily involved in this last case, I've also put
it on my website at: http://real.metasyntax.net:2357/tmp/regex.c.gz

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/
Starting program: /home/taylor/Desktop/chicken-3.4.7-DEBUG/chicken-boot 
utils.scm -quiet -no-trace -optimize-level 2 -include-path . -include-path ./ 
-explicit-use -output-file utils.c -:d -:s262k
[debug] application startup...
[debug] heap resized to 50 bytes
[debug] stack bottom is 0x7fff4561ba10.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] entering toplevel data_structures_toplevel...
[debug] entering toplevel ports_toplevel...
[debug] entering toplevel extras_toplevel...
[debug] entering toplevel srfi_69_toplevel...
[debug] entering toplevel srfi_1_toplevel...
[debug] entering toplevel match_toplevel...
[debug] entering toplevel srfi_4_toplevel...
[debug] entering toplevel utils_toplevel...
[debug] entering toplevel regex_toplevel...
[debug] entering toplevel files_toplevel...
[debug] resizing heap dynamically from 500k to 1000k ...
[debug] resizing heap dynamically from 1000k to 2000k ...
[debug] resizing heap dynamically from 2000k to 4000k ...
[debug] resizing heap dyn

Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-16 Thread Taylor Venable
On Sun, Mar 15, 2009 at 12:31:21PM +0100, felix winkelmann wrote:
> On Wed, Mar 11, 2009 at 7:25 PM, Taylor Venable  wrote:
> >
> > Well I was able to trigger a hang in my build with the debugging
> > symbols by setting the nursery stack size to 10k. ?Debug log from GDB
> > is attached. ?The three entries here were taken from allowing the
> > program to run for varying periods of time. ?The behaviour I got
> > spiked the CPU but the memory usage did not increase visibly. ?Hope
> > this sheds a little more light; if not let me know and I can go back
> > at it. ?(I notice here that the proc parameter to C_reclaim is the
> > null pointer, don't know if that's meaningful or not...)
> 
> The proc being 0 is ok. Apparently the GC looping: it might be that
> some sort of stack-limit check is constantly failing which results in
> one GC after the other. It would be cool, if you could step out of
> the GC (reclaim) and follow the execution - does it trigger a new
> GC right away?

My testing has all been done using Chicken 3.4.7 so line numbers
reference source code from that devel release.

Usually when it hangs, I end up sending it ^C when it's inside mark().
So if I step out to C_reclaim() I can step through from line 2802 (or
sometimes 2805; in runtime.c) to line 3016.  This I do in GDB using
the "next" command.  When I hit line 3016 which is

C_longjmp(C_restart, 1);

the program hangs again.  If I send it ^C again I'm back in that same
region of code again inside C_reclaim.  This happens infinitely, as
far as I can tell.

And tracing a bit further, it looks like C_library_toplevel() is
continuously calling C_reclaim().  The code that looks like (library.c
line 6616):

if(!C_demand(931)){
C_save(t1);
C_reclaim((void*)toplevel_trampoline,NULL);}

keeps getting run; this is what's calling the C_reclaim() over and
over again.  In fact, it seems that execution never makes it out of
this loop; just these three lines ad infinitum.

I found that the result of C_demand is based on C_stack_pointer and
C_stack_limit.  I was unable to determine the former using GDB, but in
this case C_stack_limit is always 0x7FFF83326C30.

Hope this helps.  I've put my library.c on my website, since it seems
to be generated code: http://real.metasyntax.net:2357/tmp/library.c.gz

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-11 Thread Taylor Venable
On Tue, Mar 10, 2009 at 02:19:56PM +0100, felix winkelmann wrote:
> On Mon, Mar 9, 2009 at 3:43 PM, Taylor Venable  wrote:
> >
> > The bug becomes more and more phantasmagorical!
> >
> > When initially compiling chicken-boot with "make PLATFORM=linux
> > DEBUGBUILD=yes bootstrap" the bug does not appear.
> >
> > When using -:d OR -:s500k OR -:s1m the bug does not appear.
> >
> > When run inside GDB (even without debugging symbols) the bug does not
> > appear.
> 
> When invalid data leaks into the garbage collector (and GC's happen
> very frequently in chicken), the effects are always interesting and 
> effectively
> non-deterministic. Giving an extra command-line option will allocate storage,
> which will slightly shift the moment GC happens, which will lead to another
> interesting effect. Debugging these bugs is very instructive.
> 
> Try to trigger a crash or loop inside gdb by using different -:s settings.

Well I was able to trigger a hang in my build with the debugging
symbols by setting the nursery stack size to 10k.  Debug log from GDB
is attached.  The three entries here were taken from allowing the
program to run for varying periods of time.  The behaviour I got
spiked the CPU but the memory usage did not increase visibly.  Hope
this sheds a little more light; if not let me know and I can go back
at it.  (I notice here that the proc parameter to C_reclaim is the
null pointer, don't know if that's meaningful or not...)

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/
(gdb) run utils.scm -quiet -no-trace -optimize-level 2 -include-path . 
-include-path ./ -explicit-use -output-file utils.c -:s10k
Starting program: /home/taylor/Desktop/chicken-3.4.7-DEBUG/chicken-boot 
utils.scm -quiet -no-trace -optimize-level 2 -include-path . -include-path ./ 
-explicit-use -output-file utils.c -:s10k
^C
Program received signal SIGINT, Interrupt.
0x008411a2 in mark (x=0xeb05e8) at runtime.c:3044
3044  val = *x;
(gdb) bt
#0  0x008411a2 in mark (x=0xeb05e8) at runtime.c:3044
#1  0x0084054a in C_reclaim (trampoline=0x5b3699, proc=0x0)
at runtime.c:2806
#2  0x005b378c in C_library_toplevel (c=2, t0=30, t1=139900129233496)
at library.c:6618
#3  0x005b36c9 in toplevel_trampoline (dummy=0x0) at library.c:6242
#4  0x0083d0be in CHICKEN_run (toplevel=0x0) at runtime.c:1362
#5  0x0083b1a5 in CHICKEN_main (argc=14, argv=0x7fff1186fae8, 
toplevel=0x403faa) at runtime.c:577
#6  0x00403f78 in main (argc=14, argv=0x7fff1186fae8) at chicken.c:1945
(gdb) run utils.scm -quiet -no-trace -optimize-level 2 -include-path . 
-include-path ./ -explicit-use -output-file utils.c -:s10k
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/taylor/Desktop/chicken-3.4.7-DEBUG/chicken-boot 
utils.scm -quiet -no-trace -optimize-level 2 -include-path . -include-path ./ 
-explicit-use -output-file utils.c -:s10k
^C
Program received signal SIGINT, Interrupt.
0x008411aa in mark (x=0x1ef15f0) at runtime.c:3046
3046  if(C_immediatep(val)) return;
(gdb) bt
#0  0x008411aa in mark (x=0x1ef15f0) at runtime.c:3046
#1  0x0084055a in C_reclaim (trampoline=0x5b3699, proc=0x0)
at runtime.c:2807
#2  0x005b378c in C_library_toplevel (c=2, t0=30, t1=140380082637400)
at library.c:6618
#3  0x005b36c9 in toplevel_trampoline (dummy=0x0) at library.c:6242
#4  0x0083d0be in CHICKEN_run (toplevel=0x0) at runtime.c:1362
#5  0x0083b1a5 in CHICKEN_main (argc=14, argv=0x7fffd0faa228, 
toplevel=0x403faa) at runtime.c:577
#6  0x00403f78 in main (argc=14, argv=0x7fffd0faa228) at chicken.c:1945
(gdb) run utils.scm -quiet -no-trace -optimize-level 2 -include-path . 
-include-path ./ -explicit-use -output-file utils.c -:s10k
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/taylor/Desktop/chicken-3.4.7-DEBUG/chicken-boot 
utils.scm -quiet -no-trace -optimize-level 2 -include-path . -include-path ./ 
-explicit-use -output-file utils.c -:s10k
^C
Program received signal SIGINT, Interrupt.
0x00840580 in C_reclaim (trampoline=0x5b3699, proc=0x0)
at runtime.c:2805
2805  for(tinfo = trace_buffer; tinfo < trace_buffer_limit; ++tinfo) {
(gdb) bt
#0  0x00840580 in C_reclaim (trampoline=0x5b3699, proc=0x0)
at runtime.c:2805
#1  0x005b378c in C_library_toplevel (c=2, t0=30, t1=140472330148440)
at library.c:6618
#2  0x005b36c9 in toplevel_trampoline (dummy=0x0) at library.c:6242
#3  0x0083d0be in CHICKEN_run (toplevel=0x0) at runtime.c:1362
#4  0x0083b1a5 in CHICKEN_main (argc=14, argv=0x7fff4b5c0838, 
toplevel=0x403faa) at runtime.c:577
#5  0x00403f78 in main (argc=14, argv=0x7fff4b5c0838) at ch

Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-09 Thread Taylor Venable
On Sat, Mar 07, 2009 at 11:46:03PM +0100, felix winkelmann wrote:
> On Fri, Mar 6, 2009 at 3:11 PM, Taylor Venable  wrote:
> >
> > I have no direct evidence that it was an infinite recursion.  It was
> > just a guess by the symptoms, but admittedly I have little knowledge
> > of Chicken's internals.  Sorry for the noise on that.  The symptoms
> > are that CPU usage increases to max, memory usage increases steadily,
> > and the process appears to hang.
> 
> Oh, it may very well be a recursion. I was just asking in case there
> is anything that points into that direction, to give us a hint at what's
> going wrong here.
> 
> >
> > Adding "-debug p" produces no output, even when removing "-quiet".
> > When I remove "-no-trace" and add "-debug p" it also fails in the same
> > way.  But when I remove both "-no-trace" and "-debug p" it works.  So
> > it fails when "-no-trace" and/or "-debug p" is specified, but works OK
> > when neither is specified.
> 
> Hm... What happens if you add "-:d" and/or "-:s500k" (or "-:s1m")?
> It is possible that different stack settings influence the behaviour.
> Is chicken-boot built with -g ? If not, could you add it and run it
> under gdb, producing a backtrace by interrupt the program if it
> hangs? Sorry, but this is likely to need quite a lowlevel approach.

The bug becomes more and more phantasmagorical!

When initially compiling chicken-boot with "make PLATFORM=linux
DEBUGBUILD=yes bootstrap" the bug does not appear.

When using -:d OR -:s500k OR -:s1m the bug does not appear.

When run inside GDB (even without debugging symbols) the bug does not
appear.

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-06 Thread Taylor Venable
On Fri, Mar 06, 2009 at 01:45:10PM +0100, felix winkelmann wrote:
> On Wed, Mar 4, 2009 at 4:32 PM, Taylor Venable  wrote:
> > Hi all,
> >
> > When building Chicken 3.4.7 and higher (up to 3.5.2) on Ubuntu 8.10
> > x86_64 the chicken compiler goes into an infinite recursion. ?CPU
> > usage spikes, memory usage increases boundlessly, and no output is
> > ever produced. ?In Chicken 3.4.7 the file that when compiled triggers
> > this behaviour is utils.scm and for a build process I am using:
> >
> > ? ?make PLATFORM=linux bootstrap
> > ? ?make PLATFORM=linux CHICKEN=./chicken-boot
> >
> > The command that causes the infinite recursion is:
> >
> > ? ?./chicken-boot utils.scm -quiet -no-trace -optimize-level 2
> > -include-path . -include-path ./ -explicit-use -output-file utils.c
> >
> > If any other information would be helpful to diagnose this, let me
> > know and I can provide it. ?Thanks for any help.
> 
> Thanks for reporting this. If you say "infinite recursion", is there anything
> that indicates an actual recursion? Or does it just hang? Can you invoke
> the command above with an additional "-debug p" and show me the
> output?

I have no direct evidence that it was an infinite recursion.  It was
just a guess by the symptoms, but admittedly I have little knowledge
of Chicken's internals.  Sorry for the noise on that.  The symptoms
are that CPU usage increases to max, memory usage increases steadily,
and the process appears to hang.

Adding "-debug p" produces no output, even when removing "-quiet".
When I remove "-no-trace" and add "-debug p" it also fails in the same
way.  But when I remove both "-no-trace" and "-debug p" it works.  So
it fails when "-no-trace" and/or "-debug p" is specified, but works OK
when neither is specified.

Thanks,

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


[Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

2009-03-04 Thread Taylor Venable
Hi all,

When building Chicken 3.4.7 and higher (up to 3.5.2) on Ubuntu 8.10
x86_64 the chicken compiler goes into an infinite recursion.  CPU
usage spikes, memory usage increases boundlessly, and no output is
ever produced.  In Chicken 3.4.7 the file that when compiled triggers
this behaviour is utils.scm and for a build process I am using:

make PLATFORM=linux bootstrap
make PLATFORM=linux CHICKEN=./chicken-boot

The command that causes the infinite recursion is:

./chicken-boot utils.scm -quiet -no-trace -optimize-level 2
-include-path . -include-path ./ -explicit-use -output-file utils.c

If any other information would be helpful to diagnose this, let me
know and I can provide it.  Thanks for any help.

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


Re: [Chicken-users] Segmentation Fault in C_mutate on Chicken 3.5.0 (OpenBSD i386)

2009-02-26 Thread Taylor Venable
On Mon, Feb 23, 2009 at 08:14:41PM -0500, Taylor Venable wrote:
> Using Chicken 3.5.0 on OpenBSD 4.5-beta I get segmentation faults when using 
> the
> http egg.  This occurs every time when a 404 or 500 error is generated by the
> http-server. 

Happily, this seems to have been fixed by reverting the SRFI-18
implementation in devel release 3.5.1 - thanks!

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/


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


[Chicken-users] Segmentation Fault in C_mutate on Chicken 3.5.0 (OpenBSD i386)

2009-02-23 Thread Taylor Venable
Hello,

I sent this message to chicken-janitors but it was rejected, so I'm
hoping that it's OK to post bug reports here as well.

 BUG REPORT 

Date: Mon, 23 Feb 2009 19:48:26 -0500
From: Taylor Venable 
To: chicken-janit...@nongnu.org
Subject: Segmentation Fault in C_mutate on Chicken 3.5.0 (OpenBSD i386)

This is the output of chicken-bug which stated that it failed to send
the bug report automatically and directed me to post here.  I'm not
subscribed to the group so please reply to me directly for any ideas.
Hope this is enough information to figure something out, otherwise let
me know if I can provide anything else.  Thanks!

File added: gdb-output.txt

Using Chicken 3.5.0 on OpenBSD 4.5-beta I get segmentation faults when using the
http egg.  This occurs every time when a 404 or 500 error is generated by the
http-server.  I'm new to Chicken and don't really know if this is reproducible
outside of the http package (i.e. it's a larger bug) or if it is specific to the
way http does things.  Below is the source code which causes this problem
consistently, and beyond that a gdb backtrace of the code.  I built Chicken with
debugging symbols, but there are still some intervening places where there are
no symbols.  The method I used to build Chicken was:

gmake PLATFORM=bsd bootstrap
gmake PLATFORM=bsd CHICKEN=./chicken-boot DEBUGBUILD=1
gmake PLATFORM=bsd install

Here's the source of the script that fails.  I compiled it with:

csc -C -g -o http-test http-test.scm

  SOURCE CODE ==

(require-extension http-server)

(http:add-resource '("/")
   (lambda (r a)
 (let ([message (sprintf "~s" a)])
   (http:write-response-header r 200 "OK"
   `(("Content-type" . 
"text/html")
 ("Content-length" . 
,(string-length message
   (display message

((http:make-server ) #t)

  GDB OUTPUT ===

 33 [ taylor @ zeltennia ] : ~ > gdb http-test
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.5"...
(gdb) run
Starting program: /home/taylor/http-test
[waiting for requests...]
[request 0 from 127.0.0.1; thread0 (of 1) started...]
[read: "GET /foo HTTP/1.1"]
[request: method=GET, url=/foo, protocol=HTTP/1.1]
[attributes: (("cache-control" . "max-age=0") ("connection" . "keep-alive") 
("keep-alive" . "300") ("accept-charset" . "UTF-8,*") ("accept-encoding" . 
"gzip,deflate") ("accept-language" . "en-us,en;q=0.5") ("accept" . 
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8") 
("user-agent" . "Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.9.0.6) 
Gecko/2009020423 Firefox/3.0.6") ("host" . "localhost:"))]
[handling GET request...]
[raw request value: #]
[request handling:  args = ()  resource = #f]
[Error response: HTTP/1.1 404 Not Found]
[closing connection...]
[thread0 finished.]

Program received signal SIGSEGV, Segmentation fault.
0x09d28ca3 in C_mutate (slot=0x3a, val=-809714880) at runtime.c:2695
2695  return *slot = val;
(gdb) bt
#0  0x09d28ca3 in C_mutate (slot=0x3a, val=-809714880) at runtime.c:2695
#1  0x09c4b605 in f_1134r (t0=2112270952, t1=2112264396, t2=-809714880) at 
srfi-18.c:3076
#2  0x09c4b5c3 in f_1134 (c=3, t0=2112270952, t1=2112264396) at srfi-18.c:3066
#3  0x09d30a66 in C_do_apply (n=1, fn=2112270952, k=2112264396) at 
runtime.c:6228
#4  0x09d43401 in values_continuation (c=0, closure=2112270296, arg0=1) at 
runtime.c:6430
#5  0x0376ed43 in f_587 () from /usr/local/lib/chicken/3/http-server.so
#6  0x7de6afd8 in ?? ()
#7  0x0001 in ?? ()
#8  0x29aff350 in ?? () from /usr/local/lib/libchicken.so
#9  0x09d4321c in C_apply_values (c=3, closure=0, k=2112269784, lst=-809713632) 
at runtime.c:6371
#10 0x0376eae5 in f_635 () from /usr/local/lib/chicken/3/http-server.so
#11 0x7de6abac in ?? ()
#12 0x237689e0 in ?? () from /usr/local/lib/chicken/3/http-server.so
#13 0xcfbcbfd0 in ?? ()
#14 0x7de6a09c in ?? ()
#15 0x0376ed06 in f_594 () from /usr/local/lib/chicken/3/http-server.so
#16 0x7de6add8 in ?? ()
#17 0x29aff350 in ?? () from /usr/local/li