Custom Query (1631 matches)

When I try to evaluate the following program with csi, I get an error

% cat try.scm
(import srfi-19-date srfi-19-io)
(write (format-date "~Y-~m-~d" (current-date)))

% csi try.scm
CHICKEN
(c) 2008-2020, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.2.0 (rev 317468e4)
macosx-unix-clang-x86-64 [ 64bit dload ptables ]

Type ,? for help.
; loading try.scm ...
; loading /Data/tools/chicken-5.2.0/lib/chicken/11/srfi-19-date.import.so ...
; loading /Data/tools/chicken-5.2.0/lib/chicken/11/srfi-19-io.import.so ...
; loading /Data/tools/chicken-5.2.0/lib/chicken/11/srfi-19-date.so ...
; loading /Data/tools/chicken-5.2.0/lib/chicken/11/srfi-1.so ...
[..blah...]
; loading /Data/tools/chicken-5.2.0/lib/chicken/11/exn-condition.so ...
; loading /Data/tools/chicken-5.2.0/lib/chicken/11/srfi-29-install.so ...

Error: bad argument count - received 0 but expected 1: #<procedure (chicken.base#open-input-string string)>

	Call history:

	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:144: char-downcase-single	  
	utf8-case-map.scm:50: utf8-lolevel#write-utf8-char	  
	utf8-case-map.scm:224: loop	  
	<syntax>	  (write "date is ~a~%" (format-date "~Y-~m-~d" (current-date)))
	<syntax>	  (format-date "~Y-~m-~d" (current-date))
	<syntax>	  (current-date)
	<eval>	  (write "date is ~a~%" (format-date "~Y-~m-~d" (current-date)))
	<eval>	  (format-date "~Y-~m-~d" (current-date))
	<eval>	  (current-date)	<--

If instead I compile it with csc and run it, then I get:

% ./try

Error: bad argument count - received 0 but expected 1: #<procedure (chicken.base#open-input-string string)>

	Call history:

	utf8-case-map.scm:222: utf8-lolevel#read-utf8-char	  
	utf8-case-map.scm:223: char-downcase-locale	  
	utf8-case-map.scm:215: char-downcase*	  
	utf8-case-map.scm:143: char-map-multi-case	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:117: loop	  
	utf8-case-map.scm:144: char-downcase-single	  
	utf8-case-map.scm:50: utf8-lolevel#write-utf8-char	  
	utf8-case-map.scm:224: loop	  
	try.scm:2: srfi-19-date#current-date	  
	try.scm:2: srfi-19-io#format-date	  	<--

which seems to be clearly pointing towards the same thing.

I'm sure this used to work (maybe in 5.0.0), so this appears to be a regression.

If you try to install md5 twice in a row, it fails with an error:

$ ~/chickens/5.3.0rc4/bin/chicken-install -test md5
building md5
/home/sjamaan/.cache/chicken-install/md5/md5.h: No such file or directory

Error: shell command terminated with nonzero exit code
256
"sh /home/sjamaan/.cache/chicken-install/md5/md5.build.sh"

This also happens with 5.2.0, and also if you just build but not install (i.e., chicken-install -n md5).

Any idea why this happens? Is this a bug in chicken-install or in the egg?

The md5 egg's test suite will fail if you call chicken-install -test md5 when there is no csi binary in $PATH. I tried this just now while testing 5.3.0rc4 after installing it into a temporary directory.

This means if the CHICKEN binaries *are* in $PATH but uses PROGRAM_PREFIX or PROGRAM_SUFFIX it won't work either.

Worse, if the csi in $PATH is a different one from the one corresponding to the chicken-install being called, the results may be misleading - either failure if the one installed there is buggy, or passing tests if the one installed there works even if the egg that was just installed is buggy.

I notice that there's a fallback to use $CHICKEN_CSI and $CHICKEN_CSC, but it appears that chicken-install only passes those options to the build script, not the test script.

run.scm is already loaded from the correct csi, so for the interpreter I'd suggest just loading/including the test suite. But perhaps it's a good idea if chicken-install would export those same environment variables when invoking the test suite... And/or have some way to figure out how to call the chicken binaries by exposing them from a module? (but that would be backwards incompatible, so the test suite would need to deal with older CHICKEN versions gracefully anyway).