Re: [Chicken-users] [Chicken-hackers] [PATCH] Make library tests compare numbers within epsilon

[Jim Ursetto]

On May 29, 2013, at 3:53 PM, Peter Bex peter@xs4all.nl wrote:

 The fpsin expands to a C inline call to sin(), whereas the sin() call
 expands to a call to C_a_i_flonum_sin, which is not inlineable so it has
 to issue a proper function call.  This then goes through libm, which is
 potentially different from the sin() implementation in gcc.

That was my guess, but when I built library-tests with Chicken 4.8.0.1, both 
fpsin and sin expanded to C_a_i_flonum_sin.  This must have been user error on 
my part.  Since you observed an inline sin(), that's definitely the issue, and 
your patch looks correct.

BTW machine epsilon for double is closer to 1e-16 than 1e-10 but it should be 
ok for our purposes (as wise men said, when in doubt, consult a numerical 
analyst).

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

Re: [Chicken-users] problem building chicken 4.8.0.3 on mac 10.4

[Jim Ursetto]

Was that prior to the makefiles being completely rewritten, though?

Maybe the rewrite uses a feature not available until 3.81, rather than being a 
bug in 3.80.

On Jun 4, 2013, at 9:46, Felix fe...@call-with-current-continuation.org wrote:

 Hi!
 
 Using GNU Make 3.81 indeed solves the problem. Still I wonder what the problem
 is. This used to work, especially on said machine...
 
 
 cheers,
 felix
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] socket egg: socket-receive blocks?

[Jim Ursetto]

Hi,

It's a bug in the socket egg; nonblocking mode is only set during a 
socket-connect or socket-accept, which won't be called for UDP.

Temporary workaround: (use posix) and then, after creating the socket, do 
either:

(##sys#file-nonblocking! (socket-fileno *socket*))

or equivalently

(file-control fcntl/setfl (socket-fileno *socket*)
 (bitwise-ior (file-control fcntl/getfl (socket-fileno *socket*))
  open/nonblock))

Neither workaround will work on Windows.

Permanent fix: We should probably make all sockets nonblocking at creation time 
instead, since our machinery assumes nonblocking sockets.  We could expose the 
set-nonblocking operation to the user, but since TCP is always nonblocking, 
doing this only for UDP would be strange.  Thoughts?

Jim

On Jun 14, 2013, at 11:01 AM, Kristian Lein-Mathisen kristianl...@gmail.com 
wrote:

 
 Hi Chickeners!
 
 I have come across a problem with multiple srfi-18 threads when tryping to 
 listen to UDP sockets:
 
 (use socket)
 (set! *socket* (socket af/inet sock/dgram ))
 (set! (so-reuse-address? *socket*) #t)
 (socket-bind *socket* (inet-address 0.0.0.0 5055))
 ;; (socket-receive ..) here blocks the prints below
 ;; after 1 s (about 10 hello's)
 (thread-start! (lambda ()
  (thread-sleep! 1)
  (print receiving ...)
  (print (socket-receive *socket* 1024))
  (print done)))
 
 (let loop ()
  (print hello from main-thread!)
  (thread-sleep! .1)
  (loop))
 
 ;; the hello's from the main thread continue after sending a udp packet:
 ;; $ echo test `date` | socat - UDP-DATAGRAM:127.0.0.1:5055,broadcast
 
 
 The documentation for socket clearly states that socket-receive should not 
 block:
 This call will block until data is available, but other threads can proceed.
 
 What is wrong with my socket fd?
 
 K.
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] socket egg: socket-receive blocks?

[Jim Ursetto]

Should be fixed in 0.2.3.  Let me know.

Jim

On Jun 14, 2013, at 3:24 PM, Jim Ursetto zbignie...@gmail.com wrote:

 Hi,
 
 It's a bug in the socket egg; nonblocking mode is only set during a 
 socket-connect or socket-accept, which won't be called for UDP.
 
 Temporary workaround: (use posix) and then, after creating the socket, do 
 either:
 
 (##sys#file-nonblocking! (socket-fileno *socket*))
 
 or equivalently
 
 (file-control fcntl/setfl (socket-fileno *socket*)
  (bitwise-ior (file-control fcntl/getfl (socket-fileno *socket*))
   open/nonblock))
 
 Neither workaround will work on Windows.
 
 Permanent fix: We should probably make all sockets nonblocking at creation 
 time instead, since our machinery assumes nonblocking sockets.  We could 
 expose the set-nonblocking operation to the user, but since TCP is always 
 nonblocking, doing this only for UDP would be strange.  Thoughts?
 
 Jim
 
 On Jun 14, 2013, at 11:01 AM, Kristian Lein-Mathisen kristianl...@gmail.com 
 wrote:
 
 
 Hi Chickeners!
 
 I have come across a problem with multiple srfi-18 threads when tryping to 
 listen to UDP sockets:
 
 (use socket)
 (set! *socket* (socket af/inet sock/dgram ))
 (set! (so-reuse-address? *socket*) #t)
 (socket-bind *socket* (inet-address 0.0.0.0 5055))
 ;; (socket-receive ..) here blocks the prints below
 ;; after 1 s (about 10 hello's)
 (thread-start! (lambda ()
  (thread-sleep! 1)
  (print receiving ...)
  (print (socket-receive *socket* 1024))
  (print done)))
 
 (let loop ()
  (print hello from main-thread!)
  (thread-sleep! .1)
  (loop))
 
 ;; the hello's from the main thread continue after sending a udp packet:
 ;; $ echo test `date` | socat - UDP-DATAGRAM:127.0.0.1:5055,broadcast
 
 
 The documentation for socket clearly states that socket-receive should not 
 block:
 This call will block until data is available, but other threads can proceed.
 
 What is wrong with my socket fd?
 
 K.
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users
 

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

Re: [Chicken-users] socket egg: socket-receive blocks?

[Jim Ursetto]

On Jun 14, 2013, at 4:29 PM, Michele La Monaca mikele.chic...@lamonaca.net 
wrote:
 
 I've already reported this issue in the list:
 
 http://lists.nongnu.org/archive/html/chicken-users/2013-05/msg00025.html

Sorry, it got lost in the shuffle.
Could you create a ticket for the other two issues you reported?  I don't have 
Solaris or Cygwin but I can try to fix it.

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

Re: [Chicken-users] Issues with socket egg

[Jim Ursetto]

On May 8, 2013, at 8:48 AM, Michele La Monaca mikele.chic...@lamonaca.net 
wrote:

 
 2) The egg doesn’t install on Cygwin due to the unbound identifier
 'SO_EXCLUSIVEADDRUSE' (mingw only?). Dropping the related option
 (so/exclusiveaddruse) solves the problem.

When you get a chance, can you check out this repository (a superset of socket, 
tcp6 and udp6):

https://bitbucket.org/ursetto/rfc2553

and run `chicken-install socket.setup` from the checkout directory to install 
it?

I believe this should fix the Cygwin problem.

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

Re: [Chicken-users] Issues with socket egg

[Jim Ursetto]

On Jun 14, 2013, at 6:07 PM, John Cowan co...@mercury.ccil.org wrote:

 
 You have to be a local Windows admin to set SO_EXCLUSIVEADDRUSE
 on at least some versions of Windows.

I know.  It falls back to SO_REUSEADDR in that case, which is broken on Windows 
but better than nothing.

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

Re: [Chicken-users] Issues with socket egg

[Jim Ursetto]

On Jun 17, 2013, at 12:10 PM, Michele La Monaca mikele.chic...@lamonaca.net 
wrote:

 On Sat, Jun 15, 2013 at 1:00 AM, Jim Ursetto zbignie...@gmail.com wrote:
 I believe this should fix the Cygwin problem.
 
 Yes, it does. Thanks.
 
 If you care, in Mingw/Msys installation works but it does complain
 about the redefinition of EINVAL and errno by socket.h

Indeed, these are both intentional redefinitions.  Thanks for testing this.

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

Re: [Chicken-users] pressed Ctrl-\ and got segmentation fault

[Jim Ursetto]

Ah, so the segfault also occurs with plain old `cat` then?  I think we can 
close this bug ;) Thanks for tracking this down further.

On Jun 23, 2013, at 7:14, Moritz Wilhelmy mor...@wzff.de wrote:

 On 21.06.2013 22:34, John Cowan wrote:
 I can confirm that on 32-bit Linux.  On Cygwin, however, typing ^\ does
 trigger a SIGSEGV with dumped core (except that it doesn't actually dump
 core because the Windows kernel can't do that).  Both systems are running
 version 4.8.2 (rev ea02c9a), and there is no .csirc file.  Readline is
 not involved: the config line says manyargs dload ptables only.
 
 Right.
 
 $ cat
 ^\
 Segmentation fault (core dumped)
 
 But:
 $ cat test.c
 #include stdio.h
 #include signal.h
 #include unistd.h
 
 void sighandler(int sig)
 {
printf(Caught signal: %d\n, sig);
 }
 
 main()
 {
struct sigaction s;
memset(s, 0, sizeof(s));
s.sa_handler = sighandler;

sigaction(SIGSEGV, s, 0);
sigaction(SIGQUIT, s, 0);
 
while (1)
sleep(1);
 
return 0;
 }
 $ ./test 
 [2] 3720
 $ kill -QUIT %2
 Caught signal: 3
 $ kill -SEGV %2
 Caught signal: 11
 $ ./test
 ^\
 Caught signal: 3
 
 If you comment out sigaction(SIGQUIT, s, 0); it prints
 Segmentation fault (core dumped)
 although it is actually killed by SIGQUIT, not SIGSEGV.
 
 This leads me to believe that something inside Cygwin just prints the
 wrong string for some reason, like for instance Windows or Cygwin
 returning a bogus value for WTERMSIG in the wait-syscall the shell
 makes, and that this is not a Chicken bug.
 
 However, this puzzles me:
 $ find /dev/null
 ^\
 Quit (core dumped)
 $ cat /dev/null
 ^\
 Segmentation fault (core dumped)
 $ cat /dev/zero /dev/null
 ^\
 Quit (core dumped)
 
 So it might be that processes which are killed while doing I/O print
 Quit and Segmentation fault otherwise.
 
 
 Best regards,
 
 Moritz
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] my errors with eval

[Jim Ursetto]

You can't access internal defines in an eval, just as you can't access the 
lexical variable a.

To get around this you could use set! instead to define the variables at 
toplevel.

(let ((a 1))
 (set! inc (lambda () (set! a (+ 1 a)) (print a)))
 (set! runTwice (lambda (op) (op) (op)))
 (eval '(runTwice inc)))
(inc)
;; prints: 2 3 4

Notice `inc` is accessible outside the `let` here.

Otherwise you have to use something like the currently nonfunctional 
`environments` egg.

On Jul 2, 2013, at 2:26 PM, Daniel Ajoy da.a...@gmail.com wrote:

 Hi,
 
 Both this
 
 (let ((a 1) )
  (define (inc)
   (set! a (+ 1 a ) ) )
  (define (runTwice op )
   (op)
   (op) )
  (eval '(runTwice inc ) )
  )
 
 and this
 
 (let* ((a 1) )
  (define (inc)
   (set! a (+ 1 a ) ) )
  (define (runTwice op )
   (op)
   (op) )
  (eval '(runTwice inc ) )
  )
 
 Give me the error:
 
 Error: unbound variable: runTwice
 
 I'm defining runTwice right before running the eval. What am I not 
 understanding?
 
 Daniel
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Exact flownums not properly displayed in mingw

[Jim Ursetto]

If you're really concerned about this (which is ultimately aesthetic) then you 
should consider setting flonum-print-precision to 17, which will make an actual 
difference in rare cases.  
http://api.call-cc.org/doc/library/flonum-print-precision

On Jul 9, 2013, at 10:15 AM, Michele La Monaca mikele.chic...@lamonaca.net 
wrote:

 On Tue, Jul 9, 2013 at 3:44 PM, John Cowan co...@mercury.ccil.org wrote:
 
 Chicken uses the local C's idea of number-to-string conversion.
 
 Not the best approach I think. I would rather prefer a consistent behavior.
 
 Since 1. is a valid Scheme inexact number, that's perfectly fine.
 
 Being a valid Scheme number it's not a valid reason to dislay it as it is, 
 IMHO.
 
 Michele
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Exact flownums not properly displayed in mingw

[Jim Ursetto]

Heh.  That is pretty amusing, but more a formatting issue on the part of 
chicken-status.  Or you could chalk it up to the egg's use of a flonum instead 
of a string or symbolic version number (0.2.3 is read as a symbol, whereas 0.2 
is read as a number).  For example, were you to use (version 1.00), it would 
read as a flonum and display 1.0 on UNIX, which is just as incorrect as 1. 
in my opinion.

One way to quickly fix this for your case is to change (version 1.0) to 
(version 1.0) in your .setup file.  I try to use string version numbers 
exclusively now for consistency's sake.

Jim

On Jul 9, 2013, at 12:12 PM, Michele La Monaca mikele.chic...@lamonaca.net 
wrote:

 On Tue, Jul 9, 2013 at 6:31 PM, Jim Ursetto zbignie...@gmail.com wrote:
 If you're really concerned about this (which is ultimately aesthetic)
 
 Is this acceptable?
 
 C:\TMPchicken-status | tail -3
 socket ... version: 0.2.3
 srfi-37 .. version: 1.3.1
 win32-msgbox  version: 1.
 
 then you should consider setting flonum-print-precision to 17, which will
 make an actual difference in rare
 cases.  http://api.call-cc.org/doc/library/flonum-print-precision
 
 It doesn't seem to do any difference (in this case at least). Thanks, anyway.
 
 Michele


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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

Hi there.

The culprit appears to be a bug in our use of sigsetjmp, which is actually 
already fixed in recent stability/4.8.0 (after 4.8.0.3) but is as yet 
unreleased.  I verified 32-bit builds now work on a 64-bit Mac.

If anyone has a 32-bit Mac (for example, an original Core Duo) could you verify 
it works on your system as well?  You will need to build stability/4.8.0 from 
git, or I can make a tarball if you aren't set up to build from git.

Jim

(P.S. On a 32-bit system it is redundant to add any options like ARCH or 
*_OPTIONS; `make PLATFORM=macosx` will suffice.)

On Jan 11, 2013, at 2:21 AM, Daniel P. Wright d...@dpwright.com wrote:

 Jim Ursetto (Thu, Jan 10, 2013 at 12:20:05PM -0600) 
 Dani,
 
 ASSEMBLER_OPTIONS is missing:
 
 make PLATFORM=macosx ARCH=x86 C_COMPILER_OPTIONS=-no-cpp-precomp 
 -fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -m32 
 ASSEMBLER_OPTIONS=-m32 LINKER_OPTIONS=-m32
 
 Seems obvious now you mention it!  Thanks, I also managed to build
 successfully with these build options.  But,
 
 The resulting chicken gives me a bus error though and I don't know how to 
 fix that.
 
 Me too.
 
 I have had the same bus error when building chicken on an old os x
 machine without specifying ARCH=x86-64, which I think was defaulting to
 a 32-bit build.  Perhaps 32-bit builds just don't play nicely on 64-bit
 macs?  I don't suppose it's a common use-case.
 
 Thanks for your input!  I guess I'll look into it a little further and
 see if I can get anywhere with it.  What is a bus error?
 
 Thanks,
 
 Dani.


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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

I put the tarball here:
http://3e8.org/pub/chicken/stability-tmp/chicken-4.8.0.3-b39ebad.tar.gz

On Jul 15, 2013, at 5:56 PM, Jim Ursetto zbignie...@gmail.com wrote:

 Hi there.
 
 The culprit appears to be a bug in our use of sigsetjmp, which is actually 
 already fixed in recent stability/4.8.0 (after 4.8.0.3) but is as yet 
 unreleased.  I verified 32-bit builds now work on a 64-bit Mac.
 
 If anyone has a 32-bit Mac (for example, an original Core Duo) could you 
 verify it works on your system as well?  You will need to build 
 stability/4.8.0 from git, or I can make a tarball if you aren't set up to 
 build from git.
 
 Jim
 
 (P.S. On a 32-bit system it is redundant to add any options like ARCH or 
 *_OPTIONS; `make PLATFORM=macosx` will suffice.)
 
 On Jan 11, 2013, at 2:21 AM, Daniel P. Wright d...@dpwright.com wrote:
 
 Jim Ursetto (Thu, Jan 10, 2013 at 12:20:05PM -0600) 
 Dani,
 
 ASSEMBLER_OPTIONS is missing:
 
 make PLATFORM=macosx ARCH=x86 C_COMPILER_OPTIONS=-no-cpp-precomp 
 -fno-strict-aliasing -fwrapv -fno-common -DHAVE_CHICKEN_CONFIG_H -m32 
 ASSEMBLER_OPTIONS=-m32 LINKER_OPTIONS=-m32
 
 Seems obvious now you mention it!  Thanks, I also managed to build
 successfully with these build options.  But,
 
 The resulting chicken gives me a bus error though and I don't know how to 
 fix that.
 
 Me too.
 
 I have had the same bus error when building chicken on an old os x
 machine without specifying ARCH=x86-64, which I think was defaulting to
 a 32-bit build.  Perhaps 32-bit builds just don't play nicely on 64-bit
 macs?  I don't suppose it's a common use-case.
 
 Thanks for your input!  I guess I'll look into it a little further and
 see if I can get anywhere with it.  What is a bus error?
 
 Thanks,
 
 Dani.
 


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

Re: [Chicken-users] Building 32-bit chicken scheme on OS X

[Jim Ursetto]

Thanks.  Nicholas confirmed 32-bit Macs work so I'm going to officially release 
4.8.0.4.

Jim

On Jul 15, 2013, at 11:12 PM, Daniel P. Wright d...@dpwright.com wrote:

 Hello,
 
 2013/7/16 Jim Ursetto zbignie...@gmail.com
 I put the tarball here:
 http://3e8.org/pub/chicken/stability-tmp/chicken-4.8.0.3-b39ebad.tar.gz
 
 Thanks!
  
 On Jul 15, 2013, at 5:56 PM, Jim Ursetto zbignie...@gmail.com wrote:
 
  Hi there.
 
  The culprit appears to be a bug in our use of sigsetjmp, which is actually 
  already fixed in recent stability/4.8.0 (after 4.8.0.3) but is as yet 
  unreleased.  I verified 32-bit builds now work on a 64-bit Mac.
 
  If anyone has a 32-bit Mac (for example, an original Core Duo) could you 
  verify it works on your system as well?  You will need to build 
  stability/4.8.0 from git, or I can make a tarball if you aren't set up to 
  build from git.
 
 My Mac is 64-bit, but for what it's worth I downloaded and built the tarball 
 you put up, and I can confirm that it works in my case also -- the problems 
 that led to my initial post have gone away.
 
 I'll have a hunt around and see if I can find a 32-bit Mac to test on, but 
 I'm afraid I don't have one to hand right now.
 
 -Dani.

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

Re: [Chicken-users] Big integers as statement parameters in sql-de-lite

[Jim Ursetto]

It's not that the values are too large, it's that srfi 19 represents them as 
bignums, which is not currently supported by sql-de-lite. However, they work as 
floats (they will be converted to integers before being passed to the database, 
due to the column type).  Even on 32-bit systems, we fully support handling 53 
bit integers in the database in this way.

The easiest way to do this is by calling exact-inexact on the result to force 
it to floating point. Such a small value need not be a flonum on 64-bit system, 
but it will still work correctly, and it's the easiest way to ensure it is not 
a bignum.  You can confirm the value was stored as an integer by using the 
typeof() SQL function, e.g. select typeof(date) from foo;

Or you can just store the UNIX timestamp obtained from the posix unit, which 
should be a lot easier ;)

Jim

On Jul 22, 2013, at 18:18, Matt Gushee m...@gushee.net wrote:

 Hi, Kon--
 
 On Mon, Jul 22, 2013 at 4:34 PM, Kon Lovett konlov...@gmail.com wrote:
 
 Do you need the range a SRFI-19 datetime provides? Maybe an epoch based 
 approach, like provided by the posix module.
 
 No, I don't need the range. In fact, my project is a lightweight
 blogging platform, and the date-times in question are creation and
 modification times for the content, which will normally be displayed
 to site visitors--possibly in localized formats; and other values
 having to do with authentication and sessions, which will normally be
 invisible. So I think it is safe to assume that all values that will
 ever be used will fall within a couple of decades beginning with 2013.
 
 I'm not sure if I need to use SRFI-19. For some reason I thought that
 it would be preferable from the POV of  localized formatting and time
 zone conversions, but looking again at the docs it doesn't seem like
 that is necessary.
 
 But I notice that the posix date/time functions work with values
 representing seconds, much like the values that are not working for
 me--except that in posix they are floats instead of integers. So maybe
 they won't cause errors? I'll give that a try.
 
 --
 Matt Gushee
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] new eggs

[Jim Ursetto]

On Jul 29, 2013, at 11:33, Mario Domenech Goulart mario.goul...@gmail.com 
wrote:

 I don't see why we should have/allow core units in .meta's forms.  Maybe
 I'm overlooking something.  If that's the case, please let me know.

There's one reason I can think of -- it makes it easier to move a core unit 
into an egg, without updating every dependent egg.

But I think it is a bit ugly overall, and you're prone to forget to add certain 
units anyway.

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

Re: [Chicken-users] Strange problems with args egg

[Jim Ursetto]

This patch to the args egg should fix things -- could you try it?
Jim
Index: args.scm
===
--- args.scm(revision 29488)
+++ args.scm(working copy)
@@ -268,7 +268,7 @@
  )
 
   (let* ((srfi37-names (map (lambda (name)
- (let ((str (-string name)))
+ (let ((str (symbol-string (strip-syntax 
name
(if (= (string-length str) 1)
(string-ref str 0)
str)))


On Aug 3, 2013, at 6:56 AM, Jonathan Chan j...@fastmail.fm wrote:

 Hello all,
 
 First off, I am very new to Chicken. I recently tried using the args egg
 and wrote a syntax-rules macro to let me clarify a bunch of copy-paste
 declarations, but seem to be running into some strange problem where
 numbers are appended to the names of certain symbols.
 
 Here is the smallest amount of args-using Chicken that will cause the
 problem:
 
 (define-syntax test
  (syntax-rules ()
((test)
 (begin
   (define opts (list (args:make-option (h help) #:none display
   this text (print foo
   (write (args:parse (command-line-arguments) opts))
 
 (test)
 
 ... and to a local copy I made of the args egg I added the following at
 the beginning of the definition of the args:parse function (included):
 
 (define (args:parse args options-list . optionals)
  (for-each (lambda (o)
  (write (option-names (args:option-option o
options-list)
  (newline)
 
 The strange thing is that h and help seem to have turned into (h390
 help391), causing problems.
 
 Is there something I need to change to fix the problem? Sorry for many
 misunderstandings.
 
 Here is the Chicken version I am running:
 
 CHICKEN
 (c) 2008-2013, The Chicken Team
 (c) 2000-2007, Felix L. Winkelmann
 Version 4.8.0.4 (stability/4.8.0) (rev 578619b)
 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
 compiled 2013-07-15 on aeryn.xorinia.dim (Darwin)
 
 Thanks,
 -- 
 Jonathan Chan
 j...@fastmail.fm
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Strange problems with args egg

[Jim Ursetto]

Did you try my patch?  You don't have to rewrite anything, it's a bug in the 
args egg.

On Aug 4, 2013, at 2:13 AM, Jonathan Chan j...@fastmail.fm wrote:

 Thank you for the help! This is definitely a very interesting language to 
 learn.
 
 On 08/03/2013 09:06 AM, John Cowan wrote:
 Jonathan Chan scripsit:
 
 Here is the smallest amount of args-using Chicken that will cause the
 problem:
 
 (define-syntax test
   (syntax-rules ()
 ((test)
  (begin
(define opts (list (args:make-option (h help) #:none display
this text (print foo
(write (args:parse (command-line-arguments) opts))
 
 [...]
 
 The strange thing is that h and help seem to have turned into (h390
 help391), causing problems.
 This is not a Chicken-specific problem, but a general problem
 with non-hygienic macros.  You are using the non-hygienic macro
 args:make-option within a hygienic macro.  The syntax-rules transformer
 doesn't know that h and help are being used literally here (because
 it cannot tell what args:make-option does), so it systematically renames
 them to avoid collisions.
 
 Is there something I need to change to fix the problem? Sorry for many
 misunderstandings.
 You can rewrite test as a non-hygienic (explicit renaming or implicit
 renaming) macro.
 
 
 -- 
 Jonathan Chan
 j...@fastmail.fm
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Strange problems with args egg

[Jim Ursetto]

No problem. The fix is now in args 1.4.4.

On Aug 5, 2013, at 21:54, Jonathan Chan j...@fastmail.fm wrote:

 Sorry for the delayed reply - I missed your message for some reason. The
 patch does work! Thanks for the help and for the useful egg.
 
 -- 
 Jonathan Chan
 
 On Sun, Aug 4, 2013, at 06:43 AM, Jim Ursetto wrote:
 Did you try my patch?  You don't have to rewrite anything, it's a bug in
 the args egg.
 
 On Aug 4, 2013, at 2:13 AM, Jonathan Chan j...@fastmail.fm wrote:
 
 Thank you for the help! This is definitely a very interesting language to 
 learn.
 
 On 08/03/2013 09:06 AM, John Cowan wrote:
 Jonathan Chan scripsit:
 
 Here is the smallest amount of args-using Chicken that will cause the
 problem:
 
 (define-syntax test
  (syntax-rules ()
((test)
 (begin
   (define opts (list (args:make-option (h help) #:none display
   this text (print foo
   (write (args:parse (command-line-arguments) opts))
 [...]
 
 The strange thing is that h and help seem to have turned into (h390
 help391), causing problems.
 This is not a Chicken-specific problem, but a general problem
 with non-hygienic macros.  You are using the non-hygienic macro
 args:make-option within a hygienic macro.  The syntax-rules transformer
 doesn't know that h and help are being used literally here (because
 it cannot tell what args:make-option does), so it systematically renames
 them to avoid collisions.
 
 Is there something I need to change to fix the problem? Sorry for many
 misunderstandings.
 You can rewrite test as a non-hygienic (explicit renaming or implicit
 renaming) macro.
 
 -- 
 Jonathan Chan
 j...@fastmail.fm
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users
 

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

Re: [Chicken-users] Lowdown sxml-serializer not working together

[Jim Ursetto]

I don't remember offhand what the rationale was for this in sxml-serializer -- 
I can take a look but it might not be until this weekend.

On Aug 21, 2013, at 22:38, Matt Gushee m...@gushee.net wrote:

 Hi, chickeneers--
 
 I am working on an application that uses the lowdown egg to process
 *some* of the input, and sxml-serializer to render the output. I'm
 running into an issue ... I'm not sure if it's really a bug, but it's
 at least an compatibility problem:
 
 markdown-sxml converts whitespace in the input to character objects,
 or lists of character objects, e.g.:
 
   '(#\space)
   #\newline
 
 ... but serialize-sxml can't handle these: evidently it wants either
 strings or symbols. I haven't found any arguments or parameters in
 either egg that seem to be able to affect this behavior.
 
 So, is there something that needs to be fixed in one of these eggs, or
 do I just need to convert the markdown-sxml output to something that
 serialize-sxml can handle? Please advise.
 
 --
 Matt Gushee
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Lowdown sxml-serializer not working together

[Jim Ursetto]

Matt,

On Aug 22, 2013, at 3:28 PM, Matt Gushee m...@gushee.net wrote:

 Sounds good. I was actually hoping to be able to blame lowdown for
 this, since I don't really like the way it makes every word and every
 space a separate text node. But maybe that's more efficient? And
 actually, I'm wondering if that character-in-list construction:
 
  '(#\space)
 
 is really allowed by the SXML spec. The narrative documentation
 doesn't address that, and I'm a bit out of practice reading EBNF, but
 maybe I can puzzle it out.

I've modified sxml-serializer in 0.3 to accept chars, symbols and nulls as text 
nodes, and to accept text nodes in list head position.  This should allow it to 
parse lowdown's variant of SXML.

 I note that lowdown
 outputs the '' and '' in string form, whereas the '' becomes #\.
 That seems like a peculiar inconsistency, but I suppose there's some
 reason for it.

Probably lowdown is using (abusing?) the fact that the 
universal-conversion-rules only escape string text nodes, whereas characters 
etc. are output verbatim; it's generally not necessary to escape the  sign.

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

Re: [Chicken-users] Lowdown sxml-serializer not working together

[Jim Ursetto]

On Aug 23, 2013, at 11:24 PM, Matt Gushee m...@gushee.net wrote:

 Hello again--
 
 Well, I'm running into a new problem with SRV:send-reply. By following
 the documentation, I managed to create a rule set that escaped problem
 characters i the manner I want. But now, working with the complete
 document, I discover that some of the non-element nodes are not
 handled properly. The SXML form of my document starts like this:
 
  (*TOP*
(@ (*NAMESPACES*
  (#f http://www.w3.org/1999/xhtml;)
  (cvt http://xmlns.therebetygers.net/civet/0.1;)))
(*PI* xml version=\1.0\ encoding=\utf-8\)
(html
  (@ (xml:lang en) (lang en))
 
 But when I serialize it with (SRV:send-reply (pre-post-order tree
 rules)), the output begins like this:
 
  *TOP*
  *NAMESPACES*=http://www.w3.org/1999/xhtml
   cvt=http://xmlns.therebetygers.net/civet/0.1;
  *PI*xmlversion=quot;1.0quot; encoding=quot;utf-8quot;/*PI*
  html xml:lang=en lang=en

This should serialize reasonably correctly with sxml-serializer.

(use sxml-serializer)

(print
 (serialize-sxml
 '(*TOP*
   (@ (*NAMESPACES*
   (#f http://www.w3.org/1999/xhtml;)
   (cvt http://xmlns.therebetygers.net/civet/0.1;)))
   (*PI* xml version=\1.0\ encoding=\utf-8\)
(html
 (@ (xml:lang en) (lang en))
 (cvt:template
  (cvt:head
   (cvt:locale (@ (lang en) (country US) (encoding utf-8
   (cvt:block (@ (name headerContent))
 #\ Single #\space (#\a #\r #\t #\i #\c #\l #\e) #\space page))

?xml version=1.0 encoding=utf-8?
html xml:lang=en lang=en
  cvt:template xmlns:cvt=http://xmlns.therebetygers.net/civet/0.1;
cvt:head
  cvt:locale lang=en country=US encoding=utf-8 /
/cvt:head
cvt:block name=headerContentlt;Single article pagegt;/cvt:block
  /cvt:template
/html

Unfortunately it doesn't declare the default namespace for html.  You can work 
around this by providing a default namespace prefix *and* using the actual 
prefix (below, xhtml:) on your elements.  This is kind of ugly.  However, the 
stock serializer didn't even support default namespaces (!) so I may have 
simply overlooked this case when adding support.  I'll see if I can look into 
it further.

(print
 (serialize-sxml
 '(*TOP*
   (@ (*NAMESPACES*
   (xh http://www.w3.org/1999/xhtml;)
   (cvt http://xmlns.therebetygers.net/civet/0.1;)))
   (*PI* xml version=\1.0\ encoding=\utf-8\)
(xh:html
 (@ (xml:lang en) (lang en))
 (cvt:template
  (cvt:head
   (cvt:locale (@ (lang en) (country US) (encoding utf-8
(cvt:block (@ (name headerContent))
 #\ Single #\space (#\a #\r #\t #\i #\c #\l #\e)
 #\space page
 ns-prefixes: '((*default* . http://www.w3.org/1999/xhtml;))
  ))

?xml version=1.0 encoding=utf-8?
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
  cvt:template xmlns:cvt=http://xmlns.therebetygers.net/civet/0.1;
cvt:head
  cvt:locale lang=en country=US encoding=utf-8 /
/cvt:head
cvt:block name=headerContentlt;Single article pagegt;/cvt:block
  /cvt:template
/html


Namespaces can be tricky.  Check my blog posts on the subject and feel free to
ask for help.

http://3e8.org/blog/2010/07/30/namespaces-in-sxml-part-1/
http://3e8.org/blog/2010/07/31/namespaces-in-sxml-part-2/
http://3e8.org/blog/2010/08/01/default-namespaces-in-sxml/

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

Re: [Chicken-users] Lowdown sxml-serializer not working together

[Jim Ursetto]

On Aug 24, 2013, at 5:25 PM, Jim Ursetto zbignie...@gmail.com wrote:

 Unfortunately it doesn't declare the default namespace for html.  You can 
 work around this by providing a default namespace prefix *and* using the 
 actual prefix (below, xhtml:) on your elements.  This is kind of ugly.  
 However, the stock serializer didn't even support default namespaces (!) so I 
 may have simply overlooked this case when adding support.  I'll see if I can 
 look into it further.

I've added support for the default (unqualified) namespace ID in the source 
SXML now; the code is available at https://github.com/ursetto/sxml-serializer 
while I run a couple more tests.  Formerly, you could render to unqualified 
names but not use them properly in the source.

[Note: below, unqualified names are rendering to the xhtml: namespace, because 
there is a list of default namespace URI - ID mappings, called 
conventional-ns-prefixes.  To override this and render them without 
qualification, add *default* as the 3rd arg of the namespace association (as 
the original prefix).  The word original is used as if the XML document was 
the original source and you had parsed it to SXML; the SXML prefix and XML 
prefix are permitted to differ.]


(use sxml-serializer)

(print
 (serialize-sxml
 '(*TOP*
   (@ (*NAMESPACES*
   (*default* http://www.w3.org/1999/xhtml;)
   (cvt http://xmlns.therebetygers.net/civet/0.1;)))
   (*PI* xml version=\1.0\ encoding=\utf-8\)
(html
 (@ (xml:lang en) (lang en))
 (cvt:template
  (cvt:head
   (cvt:locale (@ (lang en) (country US) (encoding utf-8
(cvt:block (@ (name headerContent))
 #\ Single #\space (#\a #\r #\t #\i #\c #\l #\e)
 #\space page
  ))

?xml version=1.0 encoding=utf-8?
xhtml:html xmlns:xhtml=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
  cvt:template xmlns:cvt=http://xmlns.therebetygers.net/civet/0.1;
cvt:head
  cvt:locale lang=en country=US encoding=utf-8 /
/cvt:head
cvt:block name=headerContentlt;Single article pagegt;/cvt:block
  /cvt:template
/xhtml:html


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

Re: [Chicken-users] (no subject)

[Jim Ursetto]

For whatever reason the docs are outdated and the example is too. You have to 
(use ports) if you want to compile it.
Jim

On Aug 28, 2013, at 10:20, Matthew Phillips matt...@phillipsoft.biz wrote:

 Im playing with this egg example:  http://wiki.call-cc.org/eggref/4/args. It 
 compiles fine, but when I run it with the -h flag I get this strange error:
 
  Error: unbound variable: with-output-to-port
 
 However if I load it from csi it works fine... and from csi i can clearly see 
 that with-output-to-port exists. So I am thinking that in compiling it the 
 reference is lost somehow. 
 
 From the documentation on unit ports: 
 http://wiki.call-cc.org/man/4/Unit%20ports it says: 
 
  This unit contains various extended port definitions. This unit is used 
 by default, unless the program is compiled with the -explicit-use option.
 
 I am not passing that option, or any option. Any idea on what is going on 
 here?
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] (no subject)

[Jim Ursetto]

The doc is erroneous -- you have to add (use ports) after (use args).
Jim

On Aug 28, 2013, at 10:20 AM, Matthew Phillips matt...@phillipsoft.biz wrote:

 Im playing with this egg example:  http://wiki.call-cc.org/eggref/4/args. It 
 compiles fine, but when I run it with the -h flag I get this strange error:
 
  Error: unbound variable: with-output-to-port
 
 However if I load it from csi it works fine... and from csi i can clearly see 
 that with-output-to-port exists. So I am thinking that in compiling it the 
 reference is lost somehow. 
 
 From the documentation on unit ports: 
 http://wiki.call-cc.org/man/4/Unit%20ports it says: 
 
  This unit contains various extended port definitions. This unit is used 
 by default, unless the program is compiled with the -explicit-use option.
 
 I am not passing that option, or any option. Any idea on what is going on 
 here?
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Timezone bugs in the posix module

[Jim Ursetto]

Posix is pretty much useless for handling timezones correctly; behavior varies 
greatly based on the OS, and I am fairly sure the direction of the wind plays a 
part as well.
Jim 

 On Sep 29, 2013, at 12:28, Andy Bennett andy...@ashurst.eu.org wrote:
 
 Hi,
 
 There seem to be some inconsistencies in the timezone handling in the
 posix module.
 
 
 http://api.call-cc.org/doc/library/current-seconds
 -
 (current-seconds) procedure
 
Returns the number of seconds since midnight, Jan. 1, 1970.
 -
 
 This seems to be true and it appears to be in Zulu time.
 
 On a machine in BST:
 
 -
 $ date; csi -p '(use posix) (current-seconds)'
 Sun Sep 29 18:06:50 BST 2013
 #unspecified
 1380474410.0
 -
 
 On a machine in CDT:
 
 -
 $ date; csi -p '(use posix) (current-seconds)'
 Sun Sep 29 12:06:50 CDT 2013
 #unspecified
 1380474410.0
 -
 
 ...we get the same value. All is well.
 
 
 
 However,
 
 http://api.call-cc.org/doc/posix/seconds-%3Estring
 -
 (seconds-string [SECONDS]) procedure
 
Converts the local time represented in SECONDS into a string of the
 form Tue May 21 13:46:22 1991. SECONDS defaults to the value of
 (current-seconds).
 -
 
 ..seems to be misleading as [SECONDS] is in Zulu time (as shown above).
 It is seconds-string itself which does the conversion to local time for
 the resulting string:
 
 -
 $ date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 12:08:15 CDT 2013
 #unspecified
 Wed Dec 31 18:00:00 1969
 -
 
 
 However, there's also a bug as I get the following on a machine in BST:
 
 -
 $ date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 18:09:02 BST 2013
 #unspecified
 Thu Jan  1 01:00:00 1970
 -
 
 
 ...and if I force that machine into BST:
 
 -
 $ export TZ=BST; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 17:21:34 BST 2013
 #unspecified
 Thu Jan  1 00:00:00 1970
 -
 
 
 ...and UTC:
 -
 $ export TZ=UTC; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 17:09:46 UTC 2013
 #unspecified
 Thu Jan  1 00:00:00 1970
 -
 
 
 ...and Europe/London:
 
 -
 $ export TZ=Europe/London; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 18:21:50 BST 2013
 #unspecified
 Thu Jan  1 01:00:00 1970
 -
 
 
 ...and a definitely bogus timezone:
 
 -
 $ export TZ=rubbish; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 17:25:47 rubbish 2013
 #unspecified
 Thu Jan  1 00:00:00 1970
 -
 
 ...so seconds-string sometimes ignores the timezone and doesn't throw
 an error.
 
 -
 $ wdate
 Sun Sep 29 12:15:19 CDT 2013 (America/Chicago)
 Sun Sep 29 17:15:19 UTC 2013 (UTC)
 Sun Sep 29 18:15:19 BST 2013 (Europe/London)
 Sun Sep 29 19:15:19 CEST 2013 (Europe/Rome)
 Mon Sep 30 06:15:19 NZDT 2013 (NZ)
 -
 
 
 
 
 On the machine in BST:
 
 -
 $ export TZ=CDT; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 17:10:58 CDT 2013
 #unspecified
 Thu Jan  1 00:00:00 1970
 -
 
 -
 $ export TZ=America/Chicago; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 12:11:43 CDT 2013
 #unspecified
 Wed Dec 31 18:00:00 1969
 -
 
 ...so it seems that the posix unit does not support the same names for
 timezones as the underlying operating system / date command (Linux in
 this case).
 
 
 -
 $ export TZ=Europe/Rome; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 19:12:52 CEST 2013
 #unspecified
 Thu Jan  1 01:00:00 1970
 
 $ export TZ=CEST; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 17:13:10 CEST 2013
 #unspecified
 Thu Jan  1 00:00:00 1970
 
 $ export TZ=NZ; date; csi -p '(use posix) (seconds-string 0)'
 Mon Sep 30 06:14:00 NZDT 2013
 #unspecified
 Thu Jan  1 12:00:00 1970
 
 $ export TZ=NZDT; date; csi -p '(use posix) (seconds-string 0)'
 Sun Sep 29 17:14:15 NZDT 2013
 #unspecified
 Thu Jan  1 00:00:00 1970
 -
 
 
 
 
 
 
 Regards,
 @ndy
 
 -- 
 andy...@ashurst.eu.org
 http://www.ashurst.eu.org/
 0x7EBA75FF
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] 4.8.0.5 compiled ... on message not quite correct

[Jim Ursetto]

There was some noise on the list a few months ago in re changing the 
compilation message to reflect where the .c to .o compile occurred. Not sure if 
it went anywhere.

I don't really care either way, it is basically cosmetic IMO.

 On Oct 30, 2013, at 11:02, Mario Domenech Goulart mario.goul...@gmail.com 
 wrote:
 
 Hi Matt,
 
 On Wed, 30 Oct 2013 08:57:26 -0700 Matt Welland estifo...@gmail.com wrote:
 
 When I compiled 4.8.0.5 from the tar this morning I get a curious
 message on starting csi:
 
 csi
 
 CHICKEN
 (c) 2008-2013, The Chicken Team
 (c) 2000-2007, Felix L. Winkelmann
 Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
 compiled 2013-10-03 on aeryn.xorinia.dim (Darwin)  Not true :)
 
 That's where the Scheme-C compilation took place.  When you built the
 code from the release tarball, you actually only compiled the C code.
 
 Yes, the banner is a bit misleading.
 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] 4.8.0.5 compiled ... on message not quite correct

[Jim Ursetto]

Matt,

Easiest way to fix this in the tarball is, prior to `make`:

echo #define C_BUILD_TAG \compiled $(date +%Y-%m-%d) on $(hostname)\  
buildtag.h

or

echo '#define C_BUILD_TAG '  buildtag.h

or whatever you want in that line.

You can't currently remove or truncate that file to get an empty buildtag; you 
have to define C_BUILD_TAG to .  The code could be updated to accept a 
missing build tag (and/or to remove the resulting blank line); I can provide a 
patch if you like.

Jim

On Oct 30, 2013, at 3:11 PM, Jim Ursetto zbignie...@gmail.com wrote:

 There was some noise on the list a few months ago in re changing the 
 compilation message to reflect where the .c to .o compile occurred. Not sure 
 if it went anywhere.
 
 I don't really care either way, it is basically cosmetic IMO.
 
 On Oct 30, 2013, at 11:02, Mario Domenech Goulart mario.goul...@gmail.com 
 wrote:
 
 Hi Matt,
 
 On Wed, 30 Oct 2013 08:57:26 -0700 Matt Welland estifo...@gmail.com wrote:
 
 When I compiled 4.8.0.5 from the tar this morning I get a curious
 message on starting csi:
 
 csi
 
 CHICKEN
 (c) 2008-2013, The Chicken Team
 (c) 2000-2007, Felix L. Winkelmann
 Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
 compiled 2013-10-03 on aeryn.xorinia.dim (Darwin)  Not true :)
 
 That's where the Scheme-C compilation took place.  When you built the
 code from the release tarball, you actually only compiled the C code.
 
 Yes, the banner is a bit misleading.
 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] 4.8.0.5 compiled ... on message not quite correct

[Jim Ursetto]

I've changed the build process for stability so that release tarballs have 
their build tag made more generic and more accurate.  This was the easiest 
workaround, I hope the wording is ok.  There's no provision in the build for 
recording C compilation, just Scheme-C compilation.  However, you can override 
the build tag manually as described below if you'd like to record your C 
compile environment.
Jim

CHICKEN
(c) 2008-2013, The Chicken Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
macosx-unix-clang-x86-64 [ 64bit manyargs dload ptables ]
bootstrapped 2013-10-31

On Oct 30, 2013, at 8:36 PM, Jim Ursetto zbignie...@gmail.com wrote:

 Matt,
 
 Easiest way to fix this in the tarball is, prior to `make`:
 
 echo #define C_BUILD_TAG \compiled $(date +%Y-%m-%d) on $(hostname)\  
 buildtag.h
 
 or
 
 echo '#define C_BUILD_TAG '  buildtag.h
 
 or whatever you want in that line.
 
 You can't currently remove or truncate that file to get an empty buildtag; 
 you have to define C_BUILD_TAG to .  The code could be updated to accept a 
 missing build tag (and/or to remove the resulting blank line); I can provide 
 a patch if you like.
 
 Jim
 
 On Oct 30, 2013, at 3:11 PM, Jim Ursetto zbignie...@gmail.com wrote:
 
 There was some noise on the list a few months ago in re changing the 
 compilation message to reflect where the .c to .o compile occurred. Not sure 
 if it went anywhere.
 
 I don't really care either way, it is basically cosmetic IMO.
 
 On Oct 30, 2013, at 11:02, Mario Domenech Goulart mario.goul...@gmail.com 
 wrote:
 
 Hi Matt,
 
 On Wed, 30 Oct 2013 08:57:26 -0700 Matt Welland estifo...@gmail.com 
 wrote:
 
 When I compiled 4.8.0.5 from the tar this morning I get a curious
 message on starting csi:
 
 csi
 
 CHICKEN
 (c) 2008-2013, The Chicken Team
 (c) 2000-2007, Felix L. Winkelmann
 Version 4.8.0.5 (stability/4.8.0) (rev 5bd53ac)
 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
 compiled 2013-10-03 on aeryn.xorinia.dim (Darwin)  Not true :)
 
 That's where the Scheme-C compilation took place.  When you built the
 code from the release tarball, you actually only compiled the C code.
 
 Yes, the banner is a bit misleading.
 
 Best wishes.
 Mario
 -- 
 http://parenteses.org/mario
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users
 


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

Re: [Chicken-users] schemish/chickenish way to make configurable executables?

[Jim Ursetto]

There is also the feature-test egg which is useful in combination with the FFI.
Jim

 On Nov 3, 2013, at 9:56, Matt Welland estifo...@gmail.com wrote:
 
 Hi Peter,
 
 It looks like cond-expand does enough to achieve what I want. Thanks!
 
 Matt
 -=-
 
 
 On Sun, Nov 3, 2013 at 2:58 AM, Peter Bex peter@xs4all.nl wrote:
 On Sat, Nov 02, 2013 at 11:35:22PM -0700, Matt Welland wrote:
  I'm curious to hear opinions on conditional complication and configuration
  using Chicken scheme.
 
  Say for example I want to enable or disable the use of a particular library
  or feature and I want there to be no trace of it in the executable.
 
  I can use a preprocessor such as cpp but I imagine there is a better way.
  Any strategies or methodologies you all can share? Are macros good for 
  this?
 
 Hi Matt,
 
 Usually when I want to do something like this, I use cond-expand and
 provide the feature via -feature provide-foo:
 
 (define (foo)
   (cond-expand
 (provide-foo (do-whatever-foo-does))
 (else (error support for foo is disabled
 
 This is used extensively by the crypt egg to select which
 fallback implementations need to be provided and for which
 implementations it can use the one provided by libc.
 
 This is of course only available when compiling from Scheme.
 If you want to ship precompiled C files (so you'll only need
 a C compiler and libchicken), you'd have to use C preprocessor
 and/or conditional compilation of various different implementation
 files through Make like CHICKEN itself does (for posixunix/posixwin,
 and for things like HAVE_POSIX_POLL).  This is a lot trickier to
 do right, and I wouldn't recommend it unless you really have to.
 
 Cheers,
 Peter
 --
 http://www.more-magic.net
 
 
 
 -- 
 Matt
 -=-
 90% of the nations wealth is held by 2% of the people. Bummer to be in the 
 majority...
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] html-sxml (html-parser egg) does not decode entities in html attributes, ideas why?

[Jim Ursetto]

Alex,

Looks like there's a regression of sorts in html-parser 0.5.1.

0.5.0

#; (html-sxml foo bar/foo)
(*TOP* (foo (@ (bar

0.5.1

#; (html-sxml foo bar/foo)
Error: (cadr) bad argument type: ()

Arguably, empty attributes should result in a value of  as per 
http://dev.w3.org/html5/markup/syntax.html#syntax-attr-empty ; for example,

#; (html-sxml foo bar/foo)
(*TOP* (foo (@ (bar 

although I'd also be satisfied with a return to the status quo ante, in which a 
null cdr signifies empty.

Jim

On Sep 8, 2013, at 7:30 AM, Alex Shinn alexsh...@gmail.com wrote:

 On Thu, Sep 5, 2013 at 12:39 AM, Philip Kent phi...@knodium.com wrote:
 Hi Alex,
 
 Excellent! Thanks for looking into it and for the tip re custom parsers - I 
 was trying to understand that code!
 
 It should work now, let me know if you have any problems.
 
 -- 
 Alex
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Bug in socket egg and patch

[Jim Ursetto]

Thanks. I'll take a look this weekend.
Jim

 On Nov 27, 2013, at 2:29, Jonathan Chan j...@fastmail.fm wrote:
 
 Hello,
 
 While writing a socket server in Chicken for kicks I think I run into a
 bug in the sockets egg where socket-accept would not handle the error
 generated by select() if the listener socket had been closed - the error
 is already handled in the egg when selecting for writing.
 
 I am not sure how the procedure for reporting bugs for eggs or
 submitting patches works and am still very new to Chicken, but the
 chicken-install utility has been very nice so far and has made it very
 easy to test modifications (with -R and just chicken-install to
 reinstall a local version). Thanks for that, for the useful
 implementation, and for the egg!
 
 I have attached a patch that I believe fixes the bug.
 
 Regards,
 -- 
  Jonathan Chan
  j...@fastmail.fm
 handle-errors-in-socket-accept.patch
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Bug in socket egg and patch

[Jim Ursetto]

Patch looks good, applied in socket 0.2.5.  Thanks.
Jim

On Nov 27, 2013, at 2:29 AM, Jonathan Chan j...@fastmail.fm wrote:

 Hello,
 
 While writing a socket server in Chicken for kicks I think I run into a
 bug in the sockets egg where socket-accept would not handle the error
 generated by select() if the listener socket had been closed - the error
 is already handled in the egg when selecting for writing.
 
 I am not sure how the procedure for reporting bugs for eggs or
 submitting patches works and am still very new to Chicken, but the
 chicken-install utility has been very nice so far and has made it very
 easy to test modifications (with -R and just chicken-install to
 reinstall a local version). Thanks for that, for the useful
 implementation, and for the egg!
 
 I have attached a patch that I believe fixes the bug.
 
 Regards,
 -- 
  Jonathan Chan
  j...@fastmail.fm
 handle-errors-in-socket-accept.patch___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] Nevermind--Re: Problem with read-line

[Jim Ursetto]

The http://api.call-cc.org/doc/big-chicken extension is good for times like 
these.
Jim

 On Dec 5, 2013, at 16:50, Dan Wilckens dwilck...@gmx.com wrote:
 
 On 12/4/2013 7:01 PM, Dan Wilckens wrote:
 Hi,
 
 I built Chicken 4.8.0.5 from source on the mingw-msys platform (under 
 windows vista).  After attempting to port and debug a program I wrote 
 originally for Gambit scheme it seems that I've run into an issue with the 
 read-line command.  Specifically, if I type
 
 (display read-line)
 
 in the interpreter it prints #procedure...  # as you would expect.  But if 
 I write the exact same command into a blank file, Test.scm, and compile it 
 with gsc, running it only prints:
 
 Error: unbound variable: read-line
 
 I really can't figure this out if it's anything other than a bug. FWIW I 
 chicken-installed sfri-34.  I think the other two extensions I use (sfri-69 
 and irregex) were already installed. Thanks for any help you can provide!
 
 Dan
 Apparently I had to (require-extension extras) since those functions are not 
 included in csc by default as the are in csi.
 I didn't catch that at first in the documentation.  It's a little bit 
 confusing though to have it work in csi but not csc.  Sorry for any effort 
 you might have expended...
 Dan
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Declare large expressions as read-only and not gc-able?

[Jim Ursetto]

I'll bet if you define a 100MB literal, the resulting C file would be at least 
a gigabyte and neither CHICKEN nor gcc would be able to handle it.  You could 
try it and let us know.

You could evict it theoretically, but for something that big, you may have to 
create your own data structure in C and malloc it.

I'm curious what this expression is for.

On Jan 5, 2014, at 11:07, Sven Hartrumpf hartru...@gmx.net wrote:

 Hi all.
 
 Is there a recommended way to declare some large expressions ( 100 MB)
 in a compiled program as read-only and more importantly
 as not gc-able (the garbage collector should be saved from traversing
 these large structures again and again)?
 Should the constant value be compiled in or should it be read from a file?
 Is define-constant the right way to go?
 (How do other Scheme implementation handle such cases?)
 
 Ciao
 Sven
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Declare large expressions as read-only and not gc-able?

[Jim Ursetto]

On Jan 5, 2014, at 11:48, Peter Bex peter@xs4all.nl wrote:

 Perhaps you can use object-evict!, but
 
 that means it won't ever be reclaimed by the GC.  I haven't used
 this myself yet, so I don't know if there's a way to un-evict the
 object when it can be GC'ed.
 

http://api.call-cc.org/doc/lolevel/object-unevict

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

Re: [Chicken-users] Declare large expressions as read-only and not gc-able?

[Jim Ursetto]

Not sure why this message got truncated, but it was in reference to moving an 
object back into the heap, in other words unevicting it.

Felix says object-evict! is considered harmful, so keep that in mind.  (It 
works fine in the limited context I have used it.)

On Jan 5, 2014, at 15:27, Jim Ursetto zbignie...@gmail.com wrote:

 On Jan 5, 2014, at 11:48, Peter Bex peter@xs4all.nl wrote:
 
 Perhaps you can use object-evict!, but [message truncated by my mail client]
 
 http://api.call-cc.org/doc/lolevel/object-unevict
 
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] 4.8.0.5 syntax weirdness

[Jim Ursetto]

This is the fix:

commit f8230a466ce3a86f360178f115fb62ee124448b9
Author: Peter Bex peter@xs4all.nl
Date:   Sun Jun 30 18:50:09 2013 +0200

Fix meta-evaluation to actually take place in the meta environment and add 
tests

Signed-off-by: Christian Kellermann ck...@pestilenz.org


It seems pretty simple and applies cleanly to stability and tests out ok.  Do 
you think I should apply it?

Jim

On Mar 10, 2014, at 2:08 PM, Peter Bex peter@xs4all.nl wrote:

 On Mon, Mar 10, 2014 at 07:37:36PM +0100, Sandra Snan wrote:
 I couldn't quite get this to work:
 
 It still can't find s-contains.
 If I move the entire (define-syntax create-tickets ...) sexp to the end
 of begin-for-syntax, it can't find create-tickets when called later.
 
 This is unfortunate: I just tested your code and it works with 4.8.4, but
 not with 4.8.0.5.  Most likely this was a large change we considered too
 dangerous to include in the stability branch.  I'm not sure which of
 the many changes it was that fixed this.
 
 I'm afraid your only options are to stick with 4.7.0 or use the
 4.8.4 development snapshot (or git master) until 4.9.0 has been
 released. The good news is that both the development snapshot and
 master should be pretty stable since we're this close to a release.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] 4.8.0.5 syntax weirdness

[Jim Ursetto]

Ok. May not be able to make a full release for a few days but will push out the 
change Wednesday, at least.

 On Mar 11, 2014, at 2:31, Peter Bex peter@xs4all.nl wrote:
 
 On Mon, Mar 10, 2014 at 11:22:53PM -0500, Jim Ursetto wrote:
 This is the fix:
 
 commit f8230a466ce3a86f360178f115fb62ee124448b9
 Author: Peter Bex peter@xs4all.nl
 Date:   Sun Jun 30 18:50:09 2013 +0200
 
Fix meta-evaluation to actually take place in the meta environment and 
 add tests
 
Signed-off-by: Christian Kellermann ck...@pestilenz.org
 
 
 It seems pretty simple and applies cleanly to stability and tests out ok.  
 Do you think I should apply it?
 
 Thanks for checking that, Jim!
 
 Considering we have a few other post-4.8.0.5 patches, it might be worth
 tagging a 4.8.0.6 release.  That will be quicker than waiting for the two
 remaining patches, starting the release cycle with release candidates,
 having periods of testing etc.
 
 Cheers,
 Peter
 -- 
 http://www.more-magic.net

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

Re: [Chicken-users] CHICKEN 4.9.0rc1 is available

[Jim Ursetto]

Success--

Operating system: Mac OS X 10.9.2
Hardware platform: x86-64
C Compiler: Xcode 5.0.2 gcc -- Apple LLVM version 5.0 (clang-500.2.79) (based 
on LLVM 3.3svn)
Installation works?: yes
Tests work?: yes
Installation of eggs works?: yes (pastiche, chickadee)
Execution of eggs works?: yes (chicken-doc-admin, chickadee)

On Apr 18, 2014, at 8:12 AM, Mario Domenech Goulart mario.goul...@gmail.com 
wrote:

 Hi,
 
 The first release candidate for CHICKEN 4.9.0 has been released.  It's
 available at
 http://code.call-cc.org/dev-snapshots/2014/04/17/chicken-4.9.0rc1.tar.gz
 
 See http://code.call-cc.org/dev-snapshots/2014/04/17/NEWS for the list
 of changes.
 
 Please, give it a test and report back to the mailing list your
 findings.
 
 Here's a suggested test procedure:
 
  $ make PLATFORM=platform PREFIX=some dir install check
  $ some dir/bin/chicken-install pastiche
 
 If you want to build CHICKEN with a compiler other than the default one,
 just use C_COMPILER=the compiler (e.g., C_COMPILER=clang) on the make
 invocation.
 
 Of course, feel free to explore other supported build options (see the
 README file for more information) and actually use CHICKEN 4.9.0rc1 for
 your software.
 
 If you can, please let us know the following information about the
 environment you tested the RC tarball on:
 
 Operating system: (e.g., FreeBSD 10.0, Debian 7, Windows XP mingw-msys)
 Hardware platform: (e.g., x86, x86-64, PPC)
 C Compiler: (e.g., GCC 4.8.1, clang 3.0-6.2)
 Installation works?: yes or no
 Tests work?: yes or no
 Installation of eggs works?: yes or no
 
 Thanks in advance.
 
 The CHICKEN Team
 -- 
 http://www.call-cc.org
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] sxml and more

[Jim Ursetto]

I've got a couple of blog posts on SXML and namespaces, if you haven't already 
seen them:

http://3e8.org/blog/2010/07/30/namespaces-in-sxml-part-1/
http://3e8.org/blog/2010/07/31/namespaces-in-sxml-part-2/
http://3e8.org/blog/2010/08/01/default-namespaces-in-sxml/

but these are higher-level and so perhaps not useful to you.

There's definitely very little documentation and only marginally more code 
examples.  Most of this I reverse engineered from docs I pieced together and 
the original code itself.  Peter did a great job at adding a lot of 
documentation, for example to the sxpath low-level functions, but there are 
still large gaps.  There's also bugs and missing functionality.  And as noted, 
it's a grab-bag of parts which don't necessarily work together, or provide an 
80% solution.  Case in point, the lack of namespace support in sxml-modify.

If you have specific questions you could try asking here, or on the Sourceforge 
list.  I haven't used sxml-modify myself.  Which low-level tools did you want 
to learn about?

On Jul 25, 2014, at 1:54 PM, Nathaniel Rudavsky-Brody n...@studio.cm wrote:

 Hello,
 
 Since this is my first post, let me say how happy I've been since I 
 discovered Chicken: thanks everyone for creating such a well-thought-out 
 environment.
 
 I've got a general question about the sxml tools. I've been using the 
 top-level functions for a while now, for tasks I could do in XSLT, but prefer 
 doing in Scheme. I've always found the lower-level interface(s) a bit 
 intimidating. 
 
 But recently I got stuck on the lack of namespaces in sxml-modify, and 
 started wondering if it would be possible to rewrite it, and then... well 
 more generally, whether it's worth learning how to use the low-level tools, 
 and what I could do with them. Or are pre-post-order and sxpath and sxml-path 
 as good as it gets, for an average user like me? When I search around the 
 web, I can't seem to find examples of more advanced uses of the tools (or at 
 least, well-documented ones...).
 
 Many thanks for your thoughts,
 
 Nathaniel
 
 
 
 -- 
 Caractères mobiles
 production ebook artisanale
 http://studio.cm
 +32 (0) 485 136 458
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Help with udp6 / socket

[Jim Ursetto]

I’ve documented the family parameter to udp-open-socket and fleshed out the 
examples (including a daytime client/server pair).  
Hope this helps.

http://api.call-cc.org/doc/udp6

Jim

 On Feb 17, 2015, at 03:56, Scott McCoid mccoid.sc...@gmail.com wrote:
 
 Hi Jim,
 
 This completely worked for me, thanks for the clear example! I didn't even 
 think to check if (udp-open-socket) also accepted extra arguments. 
 
 Thanks again!
 Scott
 
 On Tue, Feb 17, 2015 at 4:17 AM, Jim Ursetto zbignie...@gmail.com 
 mailto:zbignie...@gmail.com wrote:
 Scott,
 
 This works on my system (10.10.2, CHICKEN 4.8.0.6).  Note the undocumented 
 argument to udp-open-socket… not sure what I was thinking.
 If this works for you, I will document the argument and add the example to 
 the wiki.
 
 
 (use udp6)
 
 (define s (udp-open-socket 'inet6))
 (udp-bind! s :: 1337);; unspecified address; accept both ipv4 and ipv6
 (let loop ()
   (receive (len str host port) (udp-recvfrom s 1024)
 (print received  len  bytes from [ host ]: port  :  str))
   (loop))
 (udp-close-socket s)
 
 
 ;; Then we can run netcats using IPv4 and IPv6:
 
 $ nc -6 -u localhost 1337
 hello
 ^C
 
 $ nc -4 -u localhost 1337
 hi
 ^C
 
 ;; And you should get the following output:
 
 received 6 bytes from [::1]:62028 : hello
 received 3 bytes from [:::127.0.0.1]:61031 : hi
 
 
 On Feb 16, 2015, at 07:06, Scott McCoid mccoid.sc...@gmail.com 
 mailto:mccoid.sc...@gmail.com wrote:
 
 Hi Christian!
 
 Thanks for the quick help and netcat tip. I was able to send from my script 
 and receive with netcat (for example: nc -u -6 -l 8000) without any 
 problems. (sending to port 8000 in my script)
 
 I've tried doing the reverse situation, where I receive on the script side 
 and send using netcat, but I haven't been able to get this to work. I don't 
 have any errors, but I'm not receiving anything for some reason. 
 
 I'll work on some chicken scripts that talk to each other and see if I can 
 get this to work properly. 
 
 Thanks again for your help!
 Scott
 
 On Mon, Feb 16, 2015 at 11:49 AM, Christian Kellermann ck...@pestilenz.org 
 mailto:ck...@pestilenz.org wrote:
 Hi Scott!
 
 Scott McCnoid mccoid.sc...@gmail.com mailto:mccoid.sc...@gmail.com 
 writes:
 
  I'm reasonably new to chicken-scheme (and scheme in general), and I'm
  having trouble with the udp6 (and likewise, socket) eggs. I'm trying to run
  the example code, but the connection is always refused.
 
  *Error: (socket-receive!) cannot read from socket - Connection refused:
  #socket fd:4 af/inet sock/dgram*
 
  I looked into the socket code and it seems that this is probably not the
  fault of these eggs per se, but probably something I'm doing wrong. For
  example, the *%socket-receive!* function makes a call to the sys/socket.h
  *recv* function, which always returns -1. I've tried using other port
  numbers to connect to, but this doesn't seem to make a difference.
 
  I'm on Mac OS *10.10.2* using chicken scheme v.* 4.9.0.1 *(stability/4.9.0)
  (rev 8b3189b)
 
  I'm happy to help track this down if it's a bug, just let me know.
 
 The most likely reason is that on Mac OS X there is noone listening on
 port 13.
 
 You can check that manually with nc localhost 13.
 
 The next problem is that noone is actually listening on ipv6 for that
 port. I ran into this when trying to simulate the datetime service with:
 
 date | sudo nc -u -l -p 13
 
 Connecting with v4 works, with v6 it doesn't.
 
 My suggestion is to test this with a known open service on your system
 or by creating a server explicitly bound to a v6 address.
 
 Please don't hesitate to report further issues and troubles!
 
 Kind regards,
 
 Christian
 
 --
 May you be peaceful, may you live in safety, may you be free from
 suffering, and may you live with ease.
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org mailto:Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users 
 https://lists.nongnu.org/mailman/listinfo/chicken-users
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org mailto:Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users 
 https://lists.nongnu.org/mailman/listinfo/chicken-users
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Help with udp6 / socket

[Jim Ursetto]

Scott,

This works on my system (10.10.2, CHICKEN 4.8.0.6).  Note the undocumented 
argument to udp-open-socket… not sure what I was thinking.
If this works for you, I will document the argument and add the example to the 
wiki.


(use udp6)

(define s (udp-open-socket 'inet6))
(udp-bind! s :: 1337);; unspecified address; accept both ipv4 and ipv6
(let loop ()
  (receive (len str host port) (udp-recvfrom s 1024)
(print received  len  bytes from [ host ]: port  :  str))
  (loop))
(udp-close-socket s)


;; Then we can run netcats using IPv4 and IPv6:

$ nc -6 -u localhost 1337
hello
^C

$ nc -4 -u localhost 1337
hi
^C

;; And you should get the following output:

received 6 bytes from [::1]:62028 : hello
received 3 bytes from [:::127.0.0.1]:61031 : hi


 On Feb 16, 2015, at 07:06, Scott McCoid mccoid.sc...@gmail.com wrote:
 
 Hi Christian!
 
 Thanks for the quick help and netcat tip. I was able to send from my script 
 and receive with netcat (for example: nc -u -6 -l 8000) without any problems. 
 (sending to port 8000 in my script)
 
 I've tried doing the reverse situation, where I receive on the script side 
 and send using netcat, but I haven't been able to get this to work. I don't 
 have any errors, but I'm not receiving anything for some reason. 
 
 I'll work on some chicken scripts that talk to each other and see if I can 
 get this to work properly. 
 
 Thanks again for your help!
 Scott
 
 On Mon, Feb 16, 2015 at 11:49 AM, Christian Kellermann ck...@pestilenz.org 
 mailto:ck...@pestilenz.org wrote:
 Hi Scott!
 
 Scott McCnoid mccoid.sc...@gmail.com mailto:mccoid.sc...@gmail.com writes:
 
  I'm reasonably new to chicken-scheme (and scheme in general), and I'm
  having trouble with the udp6 (and likewise, socket) eggs. I'm trying to run
  the example code, but the connection is always refused.
 
  *Error: (socket-receive!) cannot read from socket - Connection refused:
  #socket fd:4 af/inet sock/dgram*
 
  I looked into the socket code and it seems that this is probably not the
  fault of these eggs per se, but probably something I'm doing wrong. For
  example, the *%socket-receive!* function makes a call to the sys/socket.h
  *recv* function, which always returns -1. I've tried using other port
  numbers to connect to, but this doesn't seem to make a difference.
 
  I'm on Mac OS *10.10.2* using chicken scheme v.* 4.9.0.1 *(stability/4.9.0)
  (rev 8b3189b)
 
  I'm happy to help track this down if it's a bug, just let me know.
 
 The most likely reason is that on Mac OS X there is noone listening on
 port 13.
 
 You can check that manually with nc localhost 13.
 
 The next problem is that noone is actually listening on ipv6 for that
 port. I ran into this when trying to simulate the datetime service with:
 
 date | sudo nc -u -l -p 13
 
 Connecting with v4 works, with v6 it doesn't.
 
 My suggestion is to test this with a known open service on your system
 or by creating a server explicitly bound to a v6 address.
 
 Please don't hesitate to report further issues and troubles!
 
 Kind regards,
 
 Christian
 
 --
 May you be peaceful, may you live in safety, may you be free from
 suffering, and may you live with ease.
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org mailto:Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users 
 https://lists.nongnu.org/mailman/listinfo/chicken-users
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] csc/csi man pages deficient

[Jim Ursetto]

If you have chicken-doc installed, another option is to run e.g.

chicken-doc csi

or consult either of these links, from which the above is taken:

http://api.call-cc.org/doc/csi
http://wiki.call-cc.org/man/4/Using%20the%20interpreter

 On Jan 12, 2015, at 12:57, Evan Hanson ev...@foldling.org wrote:
 
 Hi Andrew,
 
 Of course you're right. I've created a ticket[1] to track this issue
 (really, a feature request for normal man pages).
 
 Best regards,
 
 Evan
 
 [1]: https://bugs.call-cc.org/ticket/1177
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


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

Re: [Chicken-users] about egg/pty

[Jim Ursetto]

1024 is the default value of FD_SETSIZE i.e. the largest fd one can use with 
select(), so I think you have the right idea.  Use of a magic constant might be 
reconsidered though.  Could also convert the code to use poll() like Chicken 
core was some time ago.
Jim


 On Feb 20, 2015, at 02:27, Christian Kellermann ck...@pestilenz.org wrote:
 
 Hi!
 
 Chaos Eternal chaoseter...@shlug.org writes:
 
 uses a magic number 1024 , which used to pack master fd and slave fd
 into one integer to return.
 
 but why 1024 and what happens when the slave fd is greater than 1024?
 
 I am not the author but 1024 happens to be the default maximum number of
 open files for most systems(tm).
 
 And yes if that assumption is wrong it will break and do strange things.
 
 As I see it it's just a quick hack to get both values out of C without
 further FFI tricks. Maybe I am wrong and Alex can explain the rationale
 behind it, if there is any.
 
 Kind regards,
 
 Christian
 
 -- 
 May you be peaceful, may you live in safety, may you be free from
 suffering, and may you live with ease.
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Termbox using

[Jim Ursetto]

Hi frad,

If I may make a suggestion. Lists are not random-access like arrays are. 
Similarly, checking a list's length traverses the whole list.

You should always iterate over a list by using car and cdr, not list-ref. So, 
to your do loop, you could add another loop variable over the list called L, 
iterate over it using cdr, and as the termination condition, test with null?. 
Then your list-ref becomes car. The way you have it, the algorithm is O(n^2). 
If you need random access you should use a vector, however that is not 
necessary for your test program.

Jim

 On May 2, 2015, at 07:34, f...@indexi.net wrote:
 
 Hi,
 
 (Sorry for my English)
 
 Newbie with Scheme, i try to use the termbox egg.
 It seems me a very nice and cool library and the documentation helps me a lot.
 I am learning Scheme and appreciate Chicken implementation.
 Here a little piece of code to print a simple text menu.
 But this code isn't in the functionnal way (very iterative).
 
 
 (use termbox)
 (init)
 
 (define running (make-parameter #t))
 (define choice 1)
 
 (define (menu x y lst)
  (let loop ()
(if ( choice (length lst)) (set! choice 1))
(if ( choice 1) (set! choice (length lst)))
(do ((i 0 (+ i 1)))
((= i (length lst)))
(if (= choice (+ i 1))
(bprintf x (+ y i) (style black) (style white) (list-ref lst i))
(bprintf x (+ y i) (style white) (style black) (list-ref lst i
(present)
(poll (lambda (mod key ch)
  (cond
((eq? key key-arrow-down) (set! choice (+ choice 1)))
((eq? key key-arrow-up) (set! choice (- choice 1)))
((eq? key key-enter) (running #f
  (lambda (w h) (loop)))
(when (running) (loop
 
 ;; an example
 (menu 5 8 '(Choice 1 Choice 2 Choice 3 Other))
 
 (shutdown)
 
 (printf Your choice: ~a\n choice)
 
 
 Maybe, someone could give me some advices or corrections to make it better.
 
 Regards,
  frad
 
 http://blog.indexi.net
 
 
 
 
 
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] Minor problem with args egg

[Jim Ursetto]

 On May 13, 2015, at 11:55, Jim Ursetto zbignie...@gmail.com wrote:
 
 #t does seem to make sense ... the existing behavior comes from the srfi-37 
 implementation which sets the value to #f for #:none args.  I could modify 
 the args egg to change #f to #t in this case; I don't think this would cause 
 any problems.  Will think it over tonight.
 

In args 1.5.1, #:none options now return a value of #t instead of the srfi-37 
default of #f, so they are effectively booleans.  This would also set up the 
possibility for —no-xx options which set option ‘xx' to #f; naturally, 
that is not yet implemented.

#:optional options will still return #f when an argument is not provided, since 
it is not nice to explicitly test against #t to distinguish between argument 
provided and not.  Also, optional arguments should not be boolean in my 
opinion.  An argument value of #f allows you to implement a default of “1 by 
placing this in the body:

 (set! arg (or arg “1”))

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

Re: [Chicken-users] Minor problem with args egg

[Jim Ursetto]

On Wed, May 13, 2015 at 4:52 AM, Peter Bex pe...@more-magic.net wrote:

 On Wed, May 13, 2015 at 03:38:41AM -0600, Matt Gushee wrote:
  Anyway, it seems that if you specify an option with no arguments, e.g.
 
 (args:make-option (v version) #:none
Display compiled versions.)
 
  ... then when the user invokes the program with that option, you get:
 
 '((v . #f) (version . #f))
 
  ... which means that alist-ref will not tell you whether the user passed
  that option, or it simply isn't present. I wonder if it wouldn't be
 better
  for a no-arg option to produce a symbol, #:undefined perhaps?

 I would expect #t to be present if the user passed the option.  This
 allows for easy presence-checking, and it's similar to an option that
 accepts yes or no.


#t does seem to make sense ... the existing behavior comes from the srfi-37
implementation which sets the value to #f for #:none args.  I could modify
the args egg to change #f to #t in this case; I don't think this would
cause any problems.  Will think it over tonight.

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

Re: [Chicken-users] Inserting Binary Data with sql-de-lite

[Jim Ursetto]

Andy,
What if you convert the string to a blob before passing it in?
Jim

 On Jun 22, 2015, at 12:16, Andy Bennett andy...@ashurst.eu.org wrote:
 
 Hi,
 
 I'm using a parameterized statement to insert binary data into sql-de-lite 
 (0.6.6) on CHICKEN 4.10rc1.
 
 When I call sql-de-lite's exec procedure I get:
 
 -
 Error: (##sys#make-c-string) cannot represent string with NUL bytes as C 
 string: ╴╴\x00...
 
 ...
 
Call history:
 
sql-de-lite.scm:459: lru-cache#lru-cache-capacity
sql-de-lite.scm:188: ##sys#block-set!
sql-de-lite.scm:461: lru-cache#lru-cache-set!
sql-de-lite.scm:175: ##sys#block-set!
sql-de-lite.scm:567: bind-parameter-count
sql-de-lite.scm:581: keyword?
sql-de-lite.scm:583: bind
sql-de-lite.scm:594: %bind-int
sql-de-lite.scm:605: bind-parameter-count
sqlite3-api.scm:155: ##sys#make-c-string
sql-de-lite.scm:584: loop
sql-de-lite.scm:581: keyword?
sql-de-lite.scm:583: bind
sql-de-lite.scm:594: %bind-int
sql-de-lite.scm:605: bind-parameter-count
sqlite3-api.scm:155: ##sys#make-c-string--
 -
 
 
 What's the recommended way to do or fix this? In the CHICKEN 4.7 days I have 
 taken binary data *out* of SQLite but I've not done it since the NUL-string 
 problems were addressed.
 
 The data gets into CHICKEN by reading it from a port using http-client.
 
 
 Thanks for your help.
 
 Sorry I'm light on details: I can send more sensible stuff on request.
 
 
 
 -- 
 andy...@ashurst.eu.org
 http://www.ashurst.eu.org/
 http://www.gonumber.com/andyjpb
 0x7EBA75FF
 
 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] regex to be actively deprecated some day?

[Jim Ursetto]

Matt,

In fact, there might be a bug in the \1 substitution mechanism, so it is not a 
bad idea to use the irregex-style replacement anyway, even if you are sticking 
with POSIX REs.  I noticed this a few days ago when attempting to escape 
characters using a backslash.  On the other hand, I could just be doing it 
wrong.

This is correct:

#;354> (print (irregex-replace/all "([:@{}>])" "{foo:}" "\\" 1))
\{foo\:\}   

This is obviously not correct:

#;355> (print (string-substitute "([:@{}>])" "1" "{foo:}" #t))  
\\1foo\\1\\1  

But, when prefixing the character with something other than backslash, \1 works 
fine:
  
#;356> (print (string-substitute "([:@{}>])" "^\\1" "{foo:}" #t))   
^{foo^:^}   

This is with 4.8.0.6 (although I don’t think it matters) and the latest regex.

Jim

> On Sep 7, 2015, at 21:07, Matt Welland  wrote:
> 
> Ok, I sort of panicked when I saw what looked like regex being deprecated 
> (read my original message below if you wish). After re-reading the irregex 
> egg wiki page a few times it looks like all is well assuming these two things:
> 
> 1. irregex unit will continue to support reading the pcre syntax
> 2. those using the backslash substitution destination string syntax be 
> prepared to write a parser/converter.
> 
> As a request to the developers - please consider adding the function from the 
> regex egg that parses the \N type dest strings to irregex.
> 
> Thanks.
> 
> Matt
> -=-
> == my original "panicked"message =
> 
> From a comment to Chicken-janitors regarding bug #1189 I saw this: 
> 
> "This seems to be an undocumented feature of the substring-replace
>  function, which allows you to escape the backslash. I would recommend
>  using irregex, the regex egg's API is kind of deprecated anyway, and it's
>  also not very efficient."
> 
> Then in the regex egg wiki page I see:
> 
> "It is a thin wrapper around the functionality provided by irregex 
>  and is mostly intended to keep 
> old code working."
> 
> These statements leave me a little concerned as I use the regex egg a fair 
> amount and I don't have the energy to learn yet another abstraction or to go 
> back and rewrite old code. More importantly I expose the use of regexes to 
> users of Megatest and logpro and they have no tolerance for doing something 
> considered a "standard" in a different way, especially if it means using 
> something that looks like Scheme.
> 
> From re-reading the irregex egg wiki page I think the only thing I rely on 
> that is missing is the \1 substitution mechanism. Is there an alternative 
> syntax? All I see is the following:
> (irregex-replace "(.)(.)" "ab" 2 1 "*")
> Which would be implemented using a destination of "\2\1*" in 
> string-substitute. Converting an old-style destination string to the list of 
> numbers and strings would not be too hard I suppose.
> 
> Thanks,
> 
> Matt
> -=-
> 
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

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

Re: [Chicken-users] regex to be actively deprecated some day?

[Jim Ursetto]

Well, shoot.  Other fearless Chickeneers already noticed this bug and marked it 
as invalid in (http://bugs.call-cc.org/ticket/1189#comment:2 
<http://bugs.call-cc.org/ticket/1189#comment:2>) due to order of operations.  
Basically, in “1” the backslash is itself backslashed, so it becomes the 
text \1.

Anyway, the upshot is, the irregex version is better.

Jim

> On Sep 9, 2015, at 23:24, Jim Ursetto <zbignie...@gmail.com> wrote:
> 
> Matt,
> 
> In fact, there might be a bug in the \1 substitution mechanism, so it is not 
> a bad idea to use the irregex-style replacement anyway, even if you are 
> sticking with POSIX REs.  I noticed this a few days ago when attempting to 
> escape characters using a backslash.  On the other hand, I could just be 
> doing it wrong.
> 
> This is correct:
> 
> #;354> (print (irregex-replace/all "([:@{}>])" "{foo:}" "\\" 1))
> \{foo\:\}   
> 
> This is obviously not correct:
> 
> #;355> (print (string-substitute "([:@{}>])" "1" "{foo:}" #t))  
> \\1foo\\1\\1   
> 
> But, when prefixing the character with something other than backslash, \1 
> works fine:
>   
> #;356> (print (string-substitute "([:@{}>])" "^\\1" "{foo:}" #t))   
> ^{foo^:^}   
> 
> This is with 4.8.0.6 (although I don’t think it matters) and the latest regex.
> 
> Jim
> 
>> On Sep 7, 2015, at 21:07, Matt Welland <mattrwell...@gmail.com 
>> <mailto:mattrwell...@gmail.com>> wrote:
>> 
>> Ok, I sort of panicked when I saw what looked like regex being deprecated 
>> (read my original message below if you wish). After re-reading the irregex 
>> egg wiki page a few times it looks like all is well assuming these two 
>> things:
>> 
>> 1. irregex unit will continue to support reading the pcre syntax
>> 2. those using the backslash substitution destination string syntax be 
>> prepared to write a parser/converter.
>> 
>> As a request to the developers - please consider adding the function from 
>> the regex egg that parses the \N type dest strings to irregex.
>> 
>> Thanks.
>> 
>> Matt
>> -=-
>> == my original "panicked"message =
>> 
>> From a comment to Chicken-janitors regarding bug #1189 I saw this: 
>> 
>> "This seems to be an undocumented feature of the substring-replace
>>  function, which allows you to escape the backslash. I would recommend
>>  using irregex, the regex egg's API is kind of deprecated anyway, and it's
>>  also not very efficient."
>> 
>> Then in the regex egg wiki page I see:
>> 
>> "It is a thin wrapper around the functionality provided by irregex 
>> <http://wiki.call-cc.org/man/4/Unit%20irregex> and is mostly intended to 
>> keep old code working."
>> 
>> These statements leave me a little concerned as I use the regex egg a fair 
>> amount and I don't have the energy to learn yet another abstraction or to go 
>> back and rewrite old code. More importantly I expose the use of regexes to 
>> users of Megatest and logpro and they have no tolerance for doing something 
>> considered a "standard" in a different way, especially if it means using 
>> something that looks like Scheme.
>> 
>> From re-reading the irregex egg wiki page I think the only thing I rely on 
>> that is missing is the \1 substitution mechanism. Is there an alternative 
>> syntax? All I see is the following:
>> (irregex-replace "(.)(.)" "ab" 2 1 "*")
>> Which would be implemented using a destination of "\2\1*" in 
>> string-substitute. Converting an old-style destination string to the list of 
>> numbers and strings would not be too hard I suppose.
>> 
>> Thanks,
>> 
>> Matt
>> -=-
>> 
>> 
>> ___
>> Chicken-users mailing list
>> Chicken-users@nongnu.org <mailto:Chicken-users@nongnu.org>
>> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 

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

Re: [Chicken-users] example from rpc egg crashes at around 2k calls for me ....

[Jim Ursetto]

It would coincide with a typical fd ulimit of 2048.  If the issue is actually 
too many tcp connections, I can't see why, as both the client and server should 
close the connection after completion. And, you are running these client 
connections serially. Maybe try dummying out the database calls. I think Peter 
is right that it's trying to serialize a database exception and failing. One 
option would be to handle the db open or query exception yourself in your 
server and print out the exception (before reraising it).
Jim

> On Dec 8, 2015, at 17:42, Matt Welland  wrote:
> 
>> On Tue, Dec 8, 2015 at 12:44 AM, Peter Bex  wrote:
>> On Mon, Dec 07, 2015 at 10:38:33PM -0700, Matt Welland wrote:
>> > I don't understand why this is crashing. I'm guessing I'm failing to close
>> > a connection or finalize something. I also saw the same problem when I used
>> > sqlite3 instead of sql-de-lite. Any help or suggestions of where to look
>> > would be appreciated.
>> 
>> From the call chain, it looks like something broke during query execution
>> and it's trying to serialize the exception object, which probably contains
>> a reference to the database connection (which is a pointer).
>> 
>> Try catching all exceptions and raising a placeholder exception with a
>> simple (error "foo")
> 
> Thanks Peter. I'm not sure where to add this but I'll experiment with it 
> tonight.
> 
> I did test on a different system today and it kept going past 6k calls. 
> However running "netstat|wc -l" showed a rapidly increasing number of TCP 
> connections. It seems likely I'm not closing the connection but I don't see 
> where to add the close.
>  
>> 
>> Cheers,
>> Peter
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Bug with #:optional in args egg?

[Jim Ursetto]

On Jun 19, 2017, at 4:25 PM, Diego A. Mundo  wrote:
> 
> With the example on the args eggref 
> (http://wiki.call-cc.org/eggref/4/args#examples 
> ) slightly modified to this:
> 
…

> You can see how the behavior of using required arguments (-e or --elephant) 
> differs from using optional arguments (-d or --depth). More specifically, -e 
> and --elephant work, parsing their arguments as expected, whereas -d produces 
> #f except when the option is passed directly after the flag with no spaces 
> (-d10, for example), and --depth always returns #f.

Basically, SRFI-37 is a bit broken and, as a thin layer on top of it, the args 
egg should probably be considered deprecated because of that (although, it does 
work in a pinch). Not to mention the questionable use of macro syntax the args 
egg demands.

The issues you mention are documented, in a sense, in args-examples.scm in the 
SVN repository. Unfortunately it looks like I didn’t actually put this in the 
wiki documentation proper:

;;; Note that missing required args can only be detected if their option 
appears last,
;;; and optional args must not be separated from their option by a space
;;; (e.g. -d2 or --debug=2, not -d 2 or --debug 2).

Optional arguments are a little iffy in the first place. To avoid confusion in 
parsing, you basically have to implement them as in SRFI-37, requiring an = or 
no interceding space, because otherwise it’s too easy to interpret an operand 
or option as an optional argument value. The SRFI specifies that operands and 
options can be intermingled in any order, making this even more important.

Another problem with SRFI-37 is that (as mentioned above) missing required 
arguments can only be detected if they come last on the command line — because 
the reference implementation, at least, will consider “--foo --bar” to be an 
option of “--foo” with a value of “--bar”, so the value can never be missing! 
It’s possible the SRFI-37 implementation could be rewritten to consider “--bar” 
to always be an option, never an argument, unless occurring after the “--“ end 
of option string.

Anyway, I would avoid using the args egg because the behavior of SRFI-37 as 
specified is not really what we expect from modern argument parsers.

Jim___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] cenv -- Chicken 5 virtual environments

[Jim Ursetto]

Hola, amigos. I’ve written a little script, cenv, which takes the pain out of 
using user repositories. It's called cenv because coops was taken. It’s modeled 
somewhat on Python virtualenv, though it’s more simplistic.

See https://github.com/ursetto/cenv , or 
simply curl -O https://raw.githubusercontent.com/ursetto/cenv/master/cenv.scm 
 .

## Description

A single `csi` script, `cenv.scm`, which creates a self-contained Chicken 5 
environment in a specified directory. It remembers which Chicken you used to 
create it, and it keeps its own repository of eggs, which extends that base 
Chicken.

When the environment is active, `csi` and `csc` and compiled programs use this 
repository, falling back to the base repository if an extension does not exist. 
`chicken-install` installs eggs into this new repository. `chicken-uninstall` 
is limited to the new repository, and `chicken-status` shows both. Generally, 
everything behaves as you expect.

`cenv` could be useful if:

- You are a regular user using the system Chicken and you have no permissions 
to, or don't want to, install eggs systemwide.
- You want to test or switch between different versions of eggs, without 
creating an entire Chicken installation to house them.___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: Docker container of Chicken's git master

[Jim Ursetto]

Neat, I started something like this for Chicken and Chickadee about a year ago 
and never released it.
Feel free to mine my code on the slight chance there is anything useful.

https://github.com/ursetto/chicken-docker 

https://github.com/ursetto/chickadee-docker 



> On May 3, 2020, at 11:05 AM, Lassi Kortela  wrote:
> 
> docker run -it schemers/chicken:head
> 
> Currently updated manually. The release containers also continue to be 
> maintained:
> 
> docker run -it schemers/chicken:4
> docker run -it schemers/chicken:5
> 

Re: chicken-doc instructions recommend extracting tar file as root

[Jim Ursetto]

Hi there,

Thanks for your interest. I recommend checking out a copy of the svn wiki repo 
and using chicken-doc-admin to import it, instead of using the tarball. For 
details see the Quick Start section in 
https://api.call-cc.org/5/doc/chicken-doc-admin.

Or, extract the tarball somewhere in your home directory with normal user 
permissions, and set CHICKEN_DOC_REPOSITORY to the extraction path, as 
mentioned in the documentation.

You may also use the public server https://api.call-cc.org if browser based 
docs are ok.

Jim

> On May 8, 2021, at 2:49 PM, Lassi Kortela  wrote:
> 
> Currently https://wiki.call-cc.org/eggref/5/chicken-doc instructs users to 
> run:
> 
> curl https://3e8.org/pub/chicken-doc/chicken-doc-repo-5.tgz | sudo tar zx
> 
> in a directory that's often located within /usr. This is not ideal from a 
> security perspective, especially given that that the remote file changes 
> daily so some users can be expected to repeat the command lots of times.
> 
> An immediate safeguard is to edit the wiki page to add the verbose flag to 
> the suggested tar command, causing it to show the pathnames of all the files 
> it extracts.
> 
> For a proper fix, could chicken-doc be modified to download the tar file, 
> sanity-check its contents, and unpack it safely into the user's home 
> directory instead?
> 
> Alternatively, if the documentation is shipped in some kind of file format 
> with an index for fast lookup, it doesn't need to be extracted into multiple 
> files at all. There are reasonably simple databases like CDB and Berkeley DB 
> for jobs like this.
> 
> -l
> 

Re: Make the args egg stop truncating long options in args:usage

[Jim Ursetto]

> On Sep 9, 2021, at 3:00 PM, T. Kurt Bond  wrote:
> 
> I know that you can parameterize args:width to change the width of the
> options display, but wouldn't it be better to NOT truncate things if
> args:width is too narrow, and instead output the whole option display,
> end the line, and then output the docstring on the next line, like
> this:

Applied in args 1.6.2. —Jim

Re: After upgrade to 5.3.0 chickadee is broken

[Jim Ursetto]

This does look suspicious. I don’t remember seeing this in 5.2 though (you had 
opened this ticket 16 months ago). Did this just manifest itself suddenly?

> On Dec 24, 2021, at 11:06, Kon Lovett  wrote:
> 
> similar - https://bugs.call-cc.org/ticket/1721
> 
>> On Dec 24, 2021, at 8:49 AM, T. Kurt Bond  wrote:
>> 
>> Ok, I've figured out what went wrong, but I'm not sure why that happened.  
>> Again, this is happening on macOS using homebrew to install CHICKEN Scheme 
>> 5.3.0.  
>> 
>> The chickadee.install.sh commands that create .../share/chicken and copy the 
>> directory chickadee to it use 
>> /usr/local/Cellar/chicken/5.3.0/usr/local/Cellar/chicken/5.3.0/share/chicken 
>> instead of /usr/local/Cellar/chicken/5.3.0/share/chicken.  That is, it 
>> repeats the /usr/local/Cellar/chicken/5.3.0/ part, so the files end up in 
>> the wrong place.
>> 
>> Here are the commands from chickadee.install.sh:
>> 
>> mkdir -p 
>> "${DESTDIR}"'/usr/local/Cellar/chicken/5.3.0/usr/local/Cellar/chicken/5.3.0/share/chicken'
>> cp -v -r '/Users/tkb/.cache/chicken-install/chickadee/chickadee' 
>> "${DESTDIR}"'/usr/local/Cellar/chicken/5.3.0/usr/local/Cellar/chicken/5.3.0/share/chicken'
>> 
>> So, something is going wrong when chickadee.install.sh is generated.
>> 
>> I've added an issue in the chickadee github repository: 
>> https://github.com/ursetto/chickadee/issues/1
>> 
>> On Thu, Dec 23, 2021 at 12:30 PM T. Kurt Bond  wrote:
>>> I'm using macOS with chicken from homebrew.
>>> 
>>> I installed chicken-doc and then chickadee, but now when I run "chickadee 
>>> serve" I get the following message:
>>> 
>>> $ chickadee  serve
>>> 
>>> Error: (change-directory) cannot change current directory - No such file or 
>>> directory: "/usr/local/Cellar/chicken/5.3.0/share/chicken/chickadee"
>>> 
>>> Call history:
>>> 
>>> spiffy.scm:548: chicken.condition#with-exception-handler
>>> spiffy.scm:548: ##sys#call-with-values
>>> spiffy.scm:548: scheme#eval
>>>   (let () (import openssl) ssl-port?)
>>>   (##core#let () (import openssl) ssl-port?)
>>> spiffy.scm:548: k691
>>> spiffy.scm:547: g694
>>> spiffy.scm:610: dynamic-import
>>> spiffy.scm:548: scheme#call-with-current-continuation
>>> spiffy.scm:548: chicken.condition#with-exception-handler
>>> spiffy.scm:548: ##sys#call-with-values
>>> spiffy.scm:548: scheme#eval
>>>   (let () (import openssl) ssl-port->tcp-port)
>>>   (##core#let () (import openssl) ssl-port->tcp-port)
>>> spiffy.scm:548: k691
>>> spiffy.scm:547: g694   <--
>>> 
>>> And, indeed, that directory is missing.  I've uninstalled chickadee and 
>>> installed it again, but that made no difference. 
>>> 
>>> Any idea of what is going wrong?
>>> -- 
>>> T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
>> 
>> 
>> -- 
>> T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
> 

Re: Reository Path, FAQ, and Index Questions

[Jim Ursetto]

> On Nov 15, 2021, at 8:06 AM, Christian Himpe 
>  wrote:
> 
> Lastly, I would like to ask if CHICKEN Scheme has a function/symbol index, as 
> for example Chez Scheme has:
> 
> https://www.scheme.com/csug8/csug_1.html

https://api.call-cc.org/5/doc  might do what you 
want. Although not a single-page index, you can search for any identifier, and 
you can get a list (“contents") of all identifiers documented in an egg. This 
documentation is sourced from the wiki, just presented in a different format.

As others suggested, it is possible to run a copy of chickadee (web) or 
chicken-doc (backend) locally. But the web version is convenient and needs no 
setup.

Jim

Re: new egg: cmark

[Jim Ursetto]

> On Nov 3, 2021, at 3:44 PM, Harley Swick  wrote:
> 
> There is a different cmark egg for Chicken 4. Since my additions are 
> significantly larger than
> the total of the old egg, I didn't feel it was fair to drop a bunch of 
> strange code on someone
> who may not want to be stuck maintaining it. I have added aliases to make 
> this egg
> a compatible replacement for users upgrading from 4 to 5. I don't foresee any 
> issues with conflicts since
> this egg only works with Chicken 5.

Harley,

Welcome. I would recommend adding a similar explanation to your wiki page, just 
that the 5 egg is a totally new codebase but has backwards-compatibility via 
aliases. Probably not critical since 4.x is old now, but might be nice if 
anyone is curious.

It’s also customary to add license information and a simple changelog / version 
history inline. In this case it would just be e.g. “0.1.0 Initial release for 
Chicken 5” or something like that. Check out other eggs for details.

Jim

Re: Not compiling statically

[Jim Ursetto]

On Feb 22, 2023, at 4:20 AM, felix.winkelm...@bevuta.com wrote:
> 
>> Hi everyone. Sorry if this is an obvious question, but can I *not* compile 
>> an extension statically?
> 
> I think this may require a csc option (to override the
> default setting). I can look into this, but currently it
> is not supported.

Thanks Felix, I wouldn’t really worry about it. It is just making CI take 
longer than expected, but that is not a big deal.

Jim

Not compiling statically

[Jim Ursetto]

Hi everyone. Sorry if this is an obvious question, but can I *not* compile an 
extension statically?

In other words, I’m trying to build chickadee, and I believe it's taking around 
twice as long as expected because it is building every egg dependency 
dynamically and then again statically.

Is it possible to not do this? This seems to be controlled by 
`default-extension-linkage` and by each individual extension with the `linkage` 
property, but there doesn’t seem to be a way to control this at runtime or 
build a whole set of dependencies dynamically only.

Jim