Re: [Chicken-users] Crash with multithreaded TCP code
Did I miss the source to threadtest.scm here? The file that contains the variable num-threads? I don't see it. -a On Sun, Jul 06, 2014 at 05:41:44PM -0700, Christopher Collins wrote: Version info: ** CHICKEN ** (c) 2008-2013, The Chicken Team ** (c) 2000-2007, Felix L. Winkelmann ** Version 4.8.0.3 (stability/4.8.0) (rev 091c3d9) ** linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] ** compiled 2013-03-12 on aeryn.xorinia.dim (Darwin) Hi, ** I'm encountering a crash with some multithreaded tcp code.** I am at a loss as to what I'm doing wrong; I was hoping someone else could spot my mistake. Below is a simple program which produces the crash.** When I run it, I get the following output: ** *** Error in `/usr/bin/csi': realloc(): invalid next size: 0x01c05210 *** I run the program as follows: 1. Start two instances of nc; one listening on [1]192.168.1.101:9000, the other on [2]192.168.1.101:9001.** Redirect a ~1KB file to nc, such that nc will send the file to whomever connects to it. 2. Run the scheme script e.g.: ** nc -l 192.168.1.101 -p 9000 ~/tmpfile ** nc -l 192.168.1.101 -p 9001 ~/tmpfile ** ./threadtest.scm ** If I change the definition of num-threads from 2 to 1, the program runs to completion. Any ideas? Thanks, Christopher References Visible links 1. http://192.168.1.101:9000/ 2. http://192.168.1.101:9001/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] no type error calling |append!|
The following produces a correct type error: $ csi -n #;1 (append foo bar '()) Error: (append bad argument type - not a proper list: foo) Whereas this does not: $ csi -n #;1 (use srfi-1) #;2 (append! foo bar '()) () I would expect to see the error in example 1 repeated in example 2. types.db shows |append| declared as: (append (#(procedure #:clean) append (list #!rest) *)) and |append!| declared as: (append! (#(procedure #:enforce) append! (#!rest list) *)) Should the signature of |append!| be updated to mirror the signature of |append|? (I'm speculating, as this is the first time I've opened types.db.) -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] help with implicit renaming macro
I have a routine with several input arguments and one output argument. I want to write a macro to wrap my output argument such that I can pass the results of my input arguments to my output argument. (See below) I have this working with an explicit renaming macro, but this is overkill. I could find myself capturing variables other than my input arguments. I'd like to rewrite this macro as an implicit renaming macro, which seems to require that I traverse form and insert (inject arg1) wherever I find arg1, and to do the same for arg2. I do not otherwise need to transform the symbolic expression bound to output. Is there some idiomatic way to traverse a tree and perform a set of replacement operations on matching leaves? (define (doit #!key arg1 arg2 output) (output arg1: arg1 arg2: arg2)) ; er-macro-transformer works, but it might capture ; more than arg1, arg2. Can I rewrite this to ; explicitely inject arg1 and arg2? ; (define-syntax do-output (er-macro-transformer (lambda (form rename compare?) `(lambda (#!key arg1 arg2) (list ,@(cdr form)) (doit arg1: hello arg2: world output: (do-output arg1 arg2)) = (hello world) Thank you, -Alan -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] help with implicit renaming macro
On Mon, Nov 11, 2013 at 09:36:48PM +0100, Peter Bex wrote: On Mon, Nov 11, 2013 at 01:22:40PM -0701, Alan Post wrote: I'd like to rewrite this macro as an implicit renaming macro, which seems to require that I traverse form and insert (inject arg1) wherever I find arg1, and to do the same for arg2. Hi Alan, Actually, you only need to inject the args where they are introduced. This will cause them to be bound unhygienically, which means they'll capture any local variables with that same literal name. So unless I'm completely misunderstanding what you're trying to do, this will suffice: (define-syntax do-output (ir-macro-transformer (lambda (e i c) `(lambda (#!key ,(i 'arg1) ,(i 'arg2)) (list ,@(cdr e)) I do not otherwise need to transform the symbolic expression bound to output. Is there some idiomatic way to traverse a tree and perform a set of replacement operations on matching leaves? SSAX has foldts which can fold over trees, but I think it's overkill to load an XML library just to transform your macros :) Finally, you might want to take a look at some of Juergen Lorenz's eggs, they provide some tools to deal with low-level macros a bit more conveniently. Aha, I missed the quote to the inject parameter, got an error about arg1, and assumed it was happening during expansion to report an unbound variable. pebkac. This does indeed work, fantastic. Really stellar feature, ir-macros. I have the most experience with defmacro, and it took me some time to come to terms with define-syntax/syntax-rules, though the vast majority of my macros fit easily and comfortably in that rubric. This was the first time in a long while I've wanted to do something more than simple transformation. I appreciate your guidance here! -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] bind-let* evaluates argument three times
The following program: (use list-bindings) (bind-let* (((x) `(,(map write '(0 1 2) x) produces the output: 012012012 I would expect the output to be: 012 This is... unfortunate, as the particular iteration I'm performing is expensive. One can obviously work-around this problem by moving expensive/side-effect code out of the bind-let* construct, but it's troubling all the same. ju, are you still active in Chicken Scheme? Care to accept a bug report? The problem also occurs with bind-let. -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] missing change-directory* in posix.import.scm
It would appear that change-directory* is not in the export list for the posix unit. This is causing a compile-time warning (which then upgrades to an error) when I use that function from an egg: --- posix.import.scm~ Fri Nov 8 10:14:14 2013 +++ posix.import.scmFri Nov 8 10:12:15 2013 @@ -30,6 +30,7 @@ call-with-input-pipe call-with-output-pipe change-directory + change-directory* change-file-mode change-file-owner close-input-pipe -Alan -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] undefined references in egg
I have a situation that resembles the following, where I have a definition |foo| that calls an undefined-by-the-module |bar|: ++ t.setup (compile -s t.scm) (install-extension 't `(t.so t.import.so)) -- ++ t.scm (module t * (import scheme) (import chicken) (define (foo) (bar))) -- Running chicken-install, I get the following warning and error: Warning: reference to possibly unbound identifier `bar' in: Warning:foo Error: module unresolved: t Reading the code, it seems the above warning is converted to a fatal error, though there may be cases where it does not. Here is my problem: I have an egg that, while initializing, defines bar, but bar isn't defined at compile-time, so I'm getting this error. This works when I compile the code outside of a module, but there seems to be an additional constraint when I wrap it around (module ...). Can I tell chicken-install that I know this symbol is undefined, and that things will be ok? Do I need to create a compile-time dummy definition? How should I handle cases where my egg uses but doesn't define a symbol in the runtime environment? Thank you, -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] undefined references in egg
On Fri, Nov 08, 2013 at 06:50:58PM +0100, Peter Bex wrote: On Fri, Nov 08, 2013 at 10:42:10AM -0700, Alan Post wrote: Running chicken-install, I get the following warning and error: Warning: reference to possibly unbound identifier `bar' in: Warning:foo Error: module unresolved: t Reading the code, it seems the above warning is converted to a fatal error, though there may be cases where it does not. Yeah, the warnings are normal Scheme warnings which you'd get in regular compilation units. However, the module system can't handle unresolved references so it'll error out. Here is my problem: I have an egg that, while initializing, defines bar, but bar isn't defined at compile-time, so I'm getting this error. This works when I compile the code outside of a module, but there seems to be an additional constraint when I wrap it around (module ...). What you're asking does not make sense in the presence of a module system. No module can define an identifier into another module (at least, not without relying on weird implementation details). A simple way to fix this is to provide BAR as a hook which the module exposes, and expects another module to implement: (module foo (foo bar) (import chicken scheme) (define bar (parameter (lambda _ (error Hook not implemented (define (foo) ((bar (module something-else () (import chicken scheme foo) (bar (lambda () 42))) You can also use the functors module syntax if you want to get fancy: https://wiki.call-cc.org/man/4/Modules#functors Cheers, Peter -- http://www.more-magic.net Thank you Peter, that makes sense. My case will be served by parameterizing my currently undefined variables like you suggest. Well, assuming the core team gets my patch for the posix unit committed. -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] missing change-directory* in posix.import.scm
On Fri, Nov 08, 2013 at 07:18:07PM +0100, Peter Bex wrote: On Fri, Nov 08, 2013 at 10:15:26AM -0700, Alan Post wrote: It would appear that change-directory* is not in the export list for the posix unit. This is causing a compile-time warning (which then upgrades to an error) when I use that function from an egg: Thanks, Alan. I've pushed this to master and updated the stability branch with it, which means 4.8.0.6 will include this fix. Cheers, Peter -- http://www.more-magic.net Thank you sir. -a -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segmentation fault
When i've had problems of this sort, it is because I haven't sorted out my unit declarations, and I'm either missing the main hook or the complicity of declarations in each file doesn't quite line up. Without seeing the scripts you're compiling it might be difficult to provide much help. Would you post them here? -Alan On Mon, Jul 08, 2013 at 10:32:11AM -0400, Frank wrote: Hi, * * Using 4.8.0.3, I*compile two scripts separately and then compile the *.o files into the binary and, upon running the binary, receive a segmentation fault. Can Anyone point Me in the direction of information on how the determine the cause, such as, is it in My scripts or the csc? Sincerely, ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segmentation fault
.icoi do go'i ra'o .ui Whatever is convenient for you, with the caveat that you meant pastiche when you said pastebin. ;-) http://paste.call-cc.org/ -Alan On Mon, Jul 08, 2013 at 10:49:58AM -0400, Frank wrote: coi alyn. .i tcegleki :-) * * I will do so as soon as I*am back at My desk. Should I attach them to an e-mail or provide a pastebin link? Sincerely, On Monday, July 8, 2013, Alan Post wrote: When i've had problems of this sort, it is because I haven't sorted out my unit declarations, and I'm either missing the main hook or the complicity of declarations in each file doesn't quite line up. Without seeing the scripts you're compiling it might be difficult to provide much help. *Would you post them here? -Alan On Mon, Jul 08, 2013 at 10:32:11AM -0400, Frank wrote: * *Hi, * ** * Using 4.8.0.3, I*compile two scripts separately and then compile the * **.o files into the binary and, upon running the binary, receive a * *segmentation fault. Can Anyone point Me in the direction of information on * *how the determine the cause, such as, is it in My scripts or the csc? * *Sincerely, ___ Chicken-users mailing list [1]Chicken-users@nongnu.org [2]https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: [3]http://c0redump.org/ References Visible links 1. javascript:; 2. https://lists.nongnu.org/mailman/listinfo/chicken-users 3. http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] link error with PROGRAM_PREFIX and compiling eggs
attached. On Thu, May 09, 2013 at 10:21:23PM +0200, Felix wrote: From: Alan Post alanp...@sunflowerriver.org Subject: [Chicken-users] link error with PROGRAM_PREFIX and compiling eggs Date: Wed, 8 May 2013 19:03:39 -0601 I have built chicken using the PROGRAM_PREFIX option: $ gmake PROGRAM_PREFIX=foo- ... When I try to install an egg, using foo-chicken-install, I get an error from gcc that it cannot locate -lchicken: installing iset:1.8 ... changing current directory to /tmp/temp835e.3607/iset /home/a/wa/foo/bin/foo-csi -bnq -setup-mode -e (require-library setup-api) -e (import setup-api) -e (setup-error-handling) -e (extension-name-and-version '(\iset\ \1.8\)) /tmp/temp835e.3607/iset/iset.setup /home/a/wa/foo/bin/foo-csc -feature compiling-extension -setup-mode -s -O3 -inline -d1 iset.scm -j iset /usr/bin/ld: cannot find -lchicken collect2: ld returned 1 exit status Error: shell command terminated with non-zero exit status 256: gcc iset.o -o iset.so - shared -L/usr/X11R6/lib -L/usr/local/lib -L/home/a/wa/foo/lib -Wl,-R/home/a/wa/foo/lib -lchicken -lm -lpthread This would be expected, as it should be trying to find -lfoo-chicken. Looking at the code, it appears there is some confusion between -host and PROGRAM_PREFIX: $ foo-csc -libs -lchicken -lm -lpthread $ foo-csc -host -libs -lfoo-chicken -lm -lpthread The chicken-install code is apparently expecting the first command here, 'foo-csc -libs', to return '-lfoo-chicken'. I'm not sure what the command-line should be when -host is specified. Can you show us the output of foo-chicken-bug? cheers, felix -- my personal website: http://c0redump.org/ -- This is a bug report generated by chicken-bug(1). Date: Thu May 9 15:28:10 2013 User information: (a * 1000 1000 Alan Post /home/a /bin/ksh) Host information: machine type: x86 software type: unix software version: openbsd build platform: gnu CHICKEN version is: Version 4.8.0.3 (stability/4.8.0) (rev 091c3d9) openbsd-unix-gnu-x86 [ manyargs dload ptables ] compiled 2013-03-12 on aeryn.xorinia.dim (Darwin) Home directory: /home/a/wa/foo/share/foo-chicken Include path: (/home/a/wa/foo/share/foo-chicken) Features: chicken chicken-4 chicken-4.8 data-structures dload extras files gnu hygienic-macros irregex irregex-is-core-unit little-endian manyargsmodule-environments openbsd ports ptables srfi-0 srfi-10 srfi-12 srfi-13 srfi-14 srfi-17 srfi-2 srfi-23 srfi-28 srfi-30 srfi-39 srfi-46 srfi-55 srfi-6 srfi-6 srfi-61 srfi-62 srfi-88 srfi-9 srfi-98 syntax-rulestcp unix utils x86 chicken-config.h: /* GENERATED */ #define HAVE_DIRENT_H 1 #define HAVE_DLFCN_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_LIMITS_H 1 #define HAVE_LONG_LONG 1 #define HAVE_MEMMOVE 1 #define HAVE_MEMORY_H 1 #define HAVE_POSIX_POLL 1 #define HAVE_SIGACTION 1 #define HAVE_SIGSETJMP 1 #define HAVE_STDINT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRERROR 1 #define HAVE_STRINGS_H 1 #define HAVE_STRING_H 1 #define HAVE_STRTOLL 1 #define HAVE_STRTOQ 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_UNISTD_H 1 #define HAVE_UNSIGNED_LONG_LONG 1 #define STDC_HEADERS 1 #define HAVE_ALLOCA 1 #define HAVE_GRP_H 1 #define HAVE_ERRNO_H 1 #define HAVE_SYSEXITS_H 1 #define C_STACK_GROWS_DOWNWARD 1 #define C_HACKED_APPLY #define C_CHICKEN_PROGRAM foo-chicken #ifndef C_INSTALL_CC # define C_INSTALL_CC gcc #endif #ifndef C_INSTALL_CXX # define C_INSTALL_CXX g++ #endif #ifndef C_INSTALL_RC_COMPILER # define C_INSTALL_RC_COMPILER #endif #ifndef C_INSTALL_CFLAGS # define C_INSTALL_CFLAGS -fno-strict-aliasing -DHAVE_CHICKEN_CONFIG_H -DC_ENABLE_PTABLES -Os -fomit-frame-pointer #endif #ifndef C_INSTALL_LDFLAGS # define C_INSTALL_LDFLAGS #endif #ifndef C_INSTALL_PREFIX # define C_INSTALL_PREFIX /home/a/wa/foo #endif #ifndef C_INSTALL_SHARE_HOME # define C_INSTALL_SHARE_HOME /home/a/wa/foo/share/foo-chicken #endif #ifndef C_INSTALL_BIN_HOME # define C_INSTALL_BIN_HOME /home/a/wa/foo/bin #endif #ifndef C_INSTALL_EGG_HOME # define C_INSTALL_EGG_HOME /home/a/wa/foo/lib/foo-chicken/6 #endif #ifndef C_INSTALL_LIB_HOME # define C_INSTALL_LIB_HOME /home/a/wa/foo/lib #endif #ifndef C_INSTALL_LIB_NAME # define C_INSTALL_LIB_NAME foo-chicken #endif #ifndef C_INSTALL_STATIC_LIB_HOME # define C_INSTALL_STATIC_LIB_HOME /home/a/wa/foo/lib #endif #ifndef C_INSTALL_INCLUDE_HOME # define C_INSTALL_INCLUDE_HOME /home/a/wa/foo/include/foo-chicken #endif #ifndef C_INSTALL_MORE_LIBS
[Chicken-users] link error with PROGRAM_PREFIX and compiling eggs
I have built chicken using the PROGRAM_PREFIX option: $ gmake PROGRAM_PREFIX=foo- ... When I try to install an egg, using foo-chicken-install, I get an error from gcc that it cannot locate -lchicken: installing iset:1.8 ... changing current directory to /tmp/temp835e.3607/iset /home/a/wa/foo/bin/foo-csi -bnq -setup-mode -e (require-library setup-api) -e (import setup-api) -e (setup-error-handling) -e (extension-name-and-version '(\iset\ \1.8\)) /tmp/temp835e.3607/iset/iset.setup /home/a/wa/foo/bin/foo-csc -feature compiling-extension -setup-mode-s -O3 -inline -d1 iset.scm -j iset /usr/bin/ld: cannot find -lchicken collect2: ld returned 1 exit status Error: shell command terminated with non-zero exit status 256: gcc iset.o -o iset.so - shared -L/usr/X11R6/lib -L/usr/local/lib -L/home/a/wa/foo/lib -Wl,-R/home/a/wa/foo/lib -lchicken -lm -lpthread This would be expected, as it should be trying to find -lfoo-chicken. Looking at the code, it appears there is some confusion between -host and PROGRAM_PREFIX: $ foo-csc -libs -lchicken -lm -lpthread $ foo-csc -host -libs -lfoo-chicken -lm -lpthread The chicken-install code is apparently expecting the first command here, 'foo-csc -libs', to return '-lfoo-chicken'. I'm not sure what the command-line should be when -host is specified. Will you help me sort this out? -Alan -- my personal website: http://c0redump.org/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Pipe and thread problem
On Wed, Oct 24, 2012 at 09:32:35AM +0200, Peter Bex wrote: On Wed, Oct 24, 2012 at 03:21:15AM -0400, Felix wrote: Anyone with a better understanding of Chicken's internals able to comment on which cases poll() is called and how the timeout value is selected? poll(2) is not used in the runtime system. I think some libcs might implement select() in terms of poll? In that case, poll is what you'd see in a syscall trace. That's correct, libpthread on (at least my) version of OpenBSD implements select in terms of poll. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Pipe and thread problem
For me, that program is blocking on a call to poll(), which must be something that is happening in chicken's threading code. It is polling on two file descriptors with an infinite timeout, and clearly never coming back up for air. the produce thread is hanging on the thread-sleep call, and the consume thread is hanging on the read-line call. This means (and I confirm in the ktrace) that your pipe is being written to. If I add a (newline writer) between your write and your flush, read-line finishes once (I'd expect that) and then blocks again on read-line, but the writing thread never wakes up. I'm not sure why a (thread-sleep! 1) would ever cause poll to be called with an infinite timeout, but a quick analysis shows that some case is not waking up produce and you get to a point where both ends of the pipe are waiting for the other one. Anyone with a better understanding of Chicken's internals able to comment on which cases poll() is called and how the timeout value is selected? -Alan On Tue, Oct 23, 2012 at 02:30:57PM -0700, Aaron Patterson wrote: Hi, I'm trying to simulate reading from a TTY that writes every two seconds. I want to do this with a pipe and two threads, one thread writes every N seconds, while the other reads any data available on the pipe. Unfortunately, my code just hangs. After speaking with the fine people in #chicken, it seems that this may be a bug. We played with different calls to put the threads to sleep, and different functions to read data, but they all ended up freezing at some point. Here is the program: (use srfi-18) (use posix) (define (produce writer) (thread-start! (lambda () (print producer started) (let loop ((i 0)) (display (conc hello i ) writer) (flush-output writer) (thread-sleep! 1) (loop (+ i 1)) (define (consume reader) (thread-start! (lambda () (print consumer started) (let loop () (print (read-line reader)) (loop) (define (stream-test in-fd out-fd) (let ((reader (open-input-file* in-fd)) (writer (open-output-file* out-fd))) (produce writer) (thread-join! (consume reader (call-with-values create-pipe stream-test) Any help would be greatly appreciated. Thanks! -- Aaron Patterson http://tenderlovemaking.com/ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] patch to move my eggs to github
On Sun, Oct 07, 2012 at 01:29:51PM +0200, Peter Bex wrote: On Sat, Oct 06, 2012 at 06:57:11PM -0600, Alan Post wrote: I've just migrated my eggs from the chicken-eggs svn repository into github. Will someone with the appropriate permission apply the patch? Hello Alan, I had a look at your github repos and noticed that you didn't create git tags corresponding to the tags in svn, but the release-info file still mentions these releases. This means that henrietta-cache will be unable to download these old releases. Currently it has cached these, but the idea of a cache is that you should be able to blow it away at any time without affecting functionality. I don't have tags in my github repository, but I do have branches. Trying the uri: https://github.com/alanpost/genturfahi/tarball/1.0.1 Does get me a file. I believe I created all of the labels that are present in svn: https://github.com/alanpost/genturfahi/branches It must specifically be a tag? Thank you, -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] utf8 egg patch
Attached is a patch that should allow the utf8 egg to build against master. I hope I didn't miss anything, the patch is simple... I hope that this patch will clean up most of these regression test failures: http://tests.call-cc.org/master/linux/x86/2012/10/06/salmonella-report/rev-dep-graphs/utf8.html -Alan -- .i ma'a lo bradi cu penmi gi'e du Index: utf8/trunk/utf8.setup === --- utf8/trunk/utf8.setup (revision 27569) +++ utf8/trunk/utf8.setup (working copy) @@ -1,3 +1,4 @@ +(use make) (define version 3.3.4) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Alex Shinn, Kon Lovett: list of eggs needing new releases
Based on recently deprecated functions in core, the following eggs need new releases: condition-utils: patch to trunk attached. lookup-table:patch to trunk attached. srfi-41: 1.2.2 no longer works, but trunk has been updated. stack: patch to trunk attached. utf8:attached patch in previous message, but patch repeated here. It appears that the deprecated features used in these eggs are the primary reasons for the majority of the test failures. The owners of these eggs are active here: Alex Shinn + utf8 Kon Lovett + condition-utils + lookup-table + srfi-41 + stack I don't have the required permission in svn to correct these issues, though I'm happy to be granted sufficient privilege to patch, test and cut new releases for these eggs. Otherwise, I've done what I can and goddess speed both of you. ^_^ -Alan -- .i ma'a lo bradi cu penmi gi'e du Index: condition-utils/trunk/condition-utils.setup === --- condition-utils/trunk/condition-utils.setup (revision 27569) +++ condition-utils/trunk/condition-utils.setup (working copy) @@ -4,9 +4,6 @@ (verify-extension-name condition-utils) -(required-extension-version - check-errors 1.12.0) - (setup-shared-extension-module 'condition-utils (extension-version 1.0.0) #:compile-options '( -fixnum-arithmetic Index: stack/trunk/stack.setup === --- stack/trunk/stack.setup (revision 27569) +++ stack/trunk/stack.setup (working copy) @@ -4,9 +4,6 @@ (verify-extension-name 'stack) -(required-extension-version - 'check-errors 1.9.0) - (setup-shared-extension-module (extension-name) (extension-version 2.1.2) #:compile-options '( -disable-interrupts Index: lookup-table/trunk/lookup-table.setup === --- lookup-table/trunk/lookup-table.setup (revision 27569) +++ lookup-table/trunk/lookup-table.setup (working copy) @@ -4,12 +4,6 @@ (verify-extension-name lookup-table) -(required-extension-version - miscmacros 2.91 - synch 2.1.0 - record-variants0.5 - check-errors 1.10.0) - ;; MAGIC-LIMIT - Element count when hash-table faster (YMMV) (define opts '(-scrutinize Index: utf8/trunk/utf8.setup === --- utf8/trunk/utf8.setup (revision 27569) +++ utf8/trunk/utf8.setup (working copy) @@ -1,3 +1,4 @@ +(use make) (define version 3.3.4) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] patch to move my eggs to github
I've just migrated my eggs from the chicken-eggs svn repository into github. Will someone with the appropriate permission apply the patch? Thank you! -Alan -- .i ma'a lo bradi cu penmi gi'e du Index: egg-locations === --- egg-locations (revision 27569) +++ egg-locations (working copy) @@ -162,7 +162,7 @@ (gap-buffer http://code.call-cc.org/release-info?egg=gap-buffer;) ;; (gazette-tools http://code.call-cc.org/release-info?egg=gazette-tools;) ; untagged (gdbm http://code.call-cc.org/release-info?egg=gdbm;) -(genturfahi http://code.call-cc.org/release-info?egg=genturfahi;) +(genturfahi https://raw.github.com/alanpost/genturfahi/master/genturfahi.release-info;) ;; (geoip http://code.call-cc.org/release-info?egg=geoip;) ; untagged (getopt-long http://code.call-cc.org/release-info?egg=getopt-long;) (git https://raw.github.com/evhan/chicken-git/master/git.release-info;) @@ -223,7 +223,7 @@ (iset http://code.call-cc.org/release-info?egg=iset;) (iup http://code.call-cc.org/release-info?egg=iup;) (javahack http://code.call-cc.org/release-info?egg=javahack;) -(jbogenturfahi http://code.call-cc.org/release-info?egg=jbogenturfahi;) +(jbogenturfahi https://raw.github.com/alanpost/jbogenturfahi/master/jbogenturfahi.release-info;) (jsmin https://raw.github.com/mario-goulart/jsmin/master/jsmin.release-info;) (jso http://code.call-cc.org/release-info?egg=jso;) (json http://code.call-cc.org/release-info?egg=json;) @@ -231,7 +231,7 @@ (kalaha https://raw.github.com/DerGuteMoritz/kalaha/master/kalaha.release-info;) (kanren http://code.call-cc.org/release-info?egg=kanren;) (kd-tree http://code.call-cc.org/release-info?egg=kd-tree;) -(kiksispehi http://code.call-cc.org/release-info?egg=kiksispehi;) +(kiksispehi https://raw.github.com/alanpost/kiksispehi/master/kiksispehi.release-info;) (kvlists https://raw.github.com/klutometis/kvlists/master/kvlists.release-info;) (lalr http://code.call-cc.org/release-info?egg=lalr;) (latch http://code.call-cc.org/release-info?egg=latch;) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Alex Shinn, Kon Lovett: list of eggs needing new releases
Thank you Alex for responding so quickly! I believe all of the below issue have now been fixed! I'm Looking forward to seeing a better nightly regression test. Happy hacking, -Alan On Sun, Oct 07, 2012 at 01:42:14PM +0900, Alex Shinn wrote: On Sun, Oct 7, 2012 at 8:09 AM, Mario Domenech Goulart mario.goul...@gmail.com wrote: Hi, On Sat, 6 Oct 2012 16:24:22 -0600 Alan Post alanp...@sunflowerriver.org wrote: Based on recently deprecated functions in core, the following eggs need new releases: condition-utils: patch to trunk attached. lookup-table:patch to trunk attached. srfi-41: 1.2.2 no longer works, but trunk has been updated. stack: patch to trunk attached. utf8:attached patch in previous message, but patch repeated here. It appears that the deprecated features used in these eggs are the primary reasons for the majority of the test failures. The owners of these eggs are active here: Alex Shinn + utf8 Kon Lovett + condition-utils + lookup-table + srfi-41 + stack I don't have the required permission in svn to correct these issues, though I'm happy to be granted sufficient privilege to patch, test and cut new releases for these eggs. Otherwise, I've done what I can and goddess speed both of you. ^_^ Notice that to use (use make) in .setup files, you need (depends make) in the corresponding .meta files, since make is now an egg. (needs make) was already in the .meta file. I've added (use make) and bumped the version. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Building Chicken Scheme for Android
Off topic, but I've played with several mobile devices and none of them have ever really 'stuck.' I wind up back on my laptop happier than I was when I wandered away. After enough of these experiences, I came to realize that not having a C compiler+native development environment was the common denominator in my negative experiences. Now I've been seeing more and more android stuff, and wondering whether one of these devices is going to fall in my lap, so I ask: can you get a C compiler and native development environment on these devices? What does that look like compared to what you've got here? Thank you, -Alan On Mon, Oct 01, 2012 at 03:10:29PM +0200, Kristian Lein-Mathisen wrote: Hi guys, I just thought I'd point out I've started a build-system for getting Chicken Scheme runtime running on Android. You can take a peek here:**[1]https://github.com/kristianlm/chicken-android. Note that it only builds the runtime system (you generally don't have a C compiler on your Android device). I did not plug into Chicken's existing build system because the Android NDK build-system is tricky, and the general recommendation is to stick with 'ndk-build' rather than patching up existing makefiles. Additionally, it makes it easier to embedd the Chicken into existing Android projects. K. References Visible links 1. https://github.com/kristianlm/chicken-android ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg authors: help us to keep eggs in good shape
I noticed some of my eggs stopped working while looking at the RSS report. I'm sorry I let that go so long, I'll figure out what is wrong and correct the problem. -Alan On Thu, May 17, 2012 at 10:36:40PM -0400, Mario domenech Goulart wrote: Dear egg authors, We currently have a lot of open bugs reported on our bug tracking system and lots of warnings and installation/test failures reported by salmonella. Please take a look at our bug tracking system (http://bugs.call-cc.org) and at the daily salmonella reports (http://tests.call-cc.org). The most recent salmonella report at the moment is http://tests.call-cc.org/master/linux/x86/2012/05/17/salmonella-report/ Several problems can be trivially fixed. Consider joining the CHICKEN Janitors mailing list (https://lists.nongnu.org/mailman/listinfo/chicken-janitors) to receive notifications from the bug tracking system. Thanks in advance. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] amb egg bug/confusion
On Thu, Mar 15, 2012 at 01:38:19AM +0100, Thomas Chust wrote: On Wed, 2012-03-14 at 18:23 -0600, Alan Post wrote: [...] (pretty-print (let ((s (amb 0 1 2))) (amb-collect s))) [...] produces: [...] (0) [...] Hello, to me this behaviour looks correct. amb-collect is supposed to collect all the different values its argument can take on, but in your example s is not an ambivalent expression -- the fact that s is bound to a value produced by amb only makes the let expression ambivalent. To phrase it more technically: Every amb-collect creates a new dynamic scope for backtracking. Any ambivalence introduced in that dynamic scope will be resolved and the results will be collected but any outer dynamic scope will not be affected. Thomas, John, Thank you both very much. I did manage to start properly using the amb egg, and completed a one-off homework assignment: https://github.com/alanpost/permaculture-design-course/blob/master/guild/README amb is very neat. I'll likely throw larger datasets and more interesting constraints at it as I continue to explore this problem space. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] amb egg bug/confusion
On Mon, Mar 19, 2012 at 09:18:29AM -0700, Matt Welland wrote: On Mon, Mar 19, 2012 at 5:55 AM, Alan Post [1]alanp...@sunflowerriver.org wrote: On Thu, Mar 15, 2012 at 01:38:19AM +0100, Thomas Chust wrote: On Wed, 2012-03-14 at 18:23 -0600, Alan Post wrote: [...] * (pretty-print (let ((s (amb 0 1 2))) (amb-collect s))) [...] produces: [...] * (0) [...] Hello, to me this behaviour looks correct. amb-collect is supposed to collect all the different values its argument can take on, but in your example s is not an ambivalent expression -- the fact that s is bound to a value produced by amb only makes the let expression ambivalent. To phrase it more technically: Every amb-collect creates a new dynamic scope for backtracking. Any ambivalence introduced in that dynamic scope will be resolved and the results will be collected but any outer dynamic scope will not be affected. Thomas, John, Thank you both very much. *I did manage to start properly using the amb egg, and completed a one-off homework assignment: [2]https://github.com/alanpost/permaculture-design-course/blob/master/guild/README amb is very neat. *I'll likely throw larger datasets and more interesting constraints at it as I continue to explore this problem space. Wow, another permaculturist on the chicken scheme list, what is the probability of that? I got my design certification just over a year ago. Nice work on the guild design! Do you have further plans for the code? * Ossum! I'm inclined to agree with Jorg and say it's because it's *Chicken* Scheme. _ I do have further plans for the code. I'm taking a 7-weekend course, with 2 weeknds left. I won't be working on it again until I finish the course, which happens at the end of April. I'm not sure in which direction I'll go first: it really depends on which problem in front of me I have the best data on. This project convinced me that I needed to start compiling and collecting such data: the constraint exploration was the finishing touch and my playground, and the more data I have the more options I have to play with. A local-to-me ecologist is interested in sitting down and brainstorming, I hope something interesting comes of that. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] amb egg bug/confusion
On Mon, Mar 19, 2012 at 10:05:19PM +0100, Jörg F. Wittenberger wrote: On Mar 19 2012, Alan Post wrote: On Mon, Mar 19, 2012 at 09:18:29AM -0700, Matt Welland wrote: On Mon, Mar 19, 2012 at 5:55 AM, Alan Post A local-to-me ecologist is interested in sitting down and brainstorming, I hope something interesting comes of that. -Alan Alan, now I you made me curious. Which of the ecologists is going to sit down? Will the result relate more to plants? Or is the egg system going to get a layer where one can bind those tentative identifiers used within the implementation of the importing module by specifying constraints instead of source locations upon import? I'd love it! The things I found myself wanting: + I wanted to know why some elements were excluded. What constraints were filtering which plants? Basically: why did my final group represent only a fraction of my available plants? I wanted reporting data that I could see and play with. + I wanted a constraint library. stuff like require one of a set to have a property with value foo. and require every element of this set to have the property value foo. But also ensure 4 out of 5 property values are present. I can see myself developing this library if I use amb more. + I wanted to compare runs when I had different constraints. I'm confused on what exactly I want to compare: mostly I think I want to store the output along with the set of constraints in a notebook so I can refer to previous explorations. Any work I do here is pretty likely to be specific to my problem domain (plants), but perhaps something general would emerge. You've probably never heard of the ecologist, he's pretty obscure (hehe, I think it's a student at my local uni, but I'm not sure, we haven't met in real life.) -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] amb egg bug/confusion
I'm confused by the following behavior in the amb egg: (require-extension extras amb) (pretty-print (amb-collect (amb 0 1 2))) (pretty-print (let ((s (amb 0 1 2))) (amb-collect s))) (exit) produces: (0 1 2) (0) I would expect both forms to produce (0 1 2). What am I missing? I'm trying to do something more complicated than the above, but this was the test case I was able to produce. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken Sprint starting tomorrow
May this be a success! I have a solid agenda for myself: * add utf-8 code to genturfa'i * bring the documentation up to the same standard as the code. I'll be attending over IRC Saturday, and hope to see some nice work get done! -Alan On Thu, Dec 08, 2011 at 10:15:24PM +0100, Christian Kellermann wrote: Dear Chicken fans, this is a friendly reminder that the Chicken sprint will start tomorrow on friday 9th. Chicken enthusiast will gather in Nuremberg, Germany and #chicken on freenode for the weekend. The people in Nuremberg will meet tomorrow evening at the location around 8pm and setup infrastructure. (We will not have access earlier.) So before that the usual socialising will take place, which might go unnoticed for the online crowd. So expect first successful reports later in the evening. If you are in the area and want to drop by then saturday is a good day to do so. I haven't spoken to the others yet but if you come by at 11 am or later on saturday, someone will be there and hacking... The address is: U43 Uhlandstr. 43 90408 Nürnberg Same goes for sunday I guess but, you know, we are agile CHICKENs and will make up the plan as we go along. We will announce our whereabouts and evening plans on #chicken as they evolve. If you have further questions or need directions please don't hesitate to contact me. If you have a problem, if no one else can help, and if you can find them, maybe you can hire... The CHICKEN team ;) Good night, Christian -- Who can (make) the muddy water (clear)? Let it be still, and it will gradually become clear. Who can secure the condition of rest? Let movement go on, and the condition of rest will gradually arise. -- Lao Tse. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Why does the JSON egg map JSON structs to Scheme vectors instead of alists?
On Sun, Nov 27, 2011 at 06:39:52PM +0100, Moritz Heidkamp wrote: Vok Vojwo cev...@gmail.com writes: I think the Medea egg intends to do it the right way. But it seems to be buggy. And it has a voracious appetite It does indeed :-) Medea fails to parse the data: (use medea) (read-json json) ;; = #f Thanks for the hint. I managed to bisect it down to a Unicode character in one of the strings (’). Looking at medea's test suite I found this: ;; (test-read '#(Дҫ) [\Дҫ\]) ; FIXME genturfahi needs utf8 support for that to work So thanks for the reminder, I should mention this limitation in medea's documentation. Alan, would it be possible to make genturfahi UTF-8 aware? Yes. I will accomplish it over the hackathon weekend. My first attempt didn't go well, though it was because I was having trouble getting basic UTF-like things working in Chicken at all. I actually have some of the required support ready to be checked in here in my local repository. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] c-string return question
On Thu, Oct 13, 2011 at 07:24:12PM +0200, Jörg F. Wittenberger wrote:
IMHO the moral of the story: Never trust you C compiler too much.
I've had to get more familiar with gcc's -f flag, as the years have
gone by. '-fno-strict-aliasing' is one that I've personally needed
(and chicken requires too, I believe) for some time now, and
variously I've had to turn those on and off based on writing C that
was a little too comfortable with the underlying machine
architecture.
A favorite trick of mine, for instance:
struct string {
size_t string_size;
char string_buffer[1]; /* note the single character string */
}
Where I then malloc 'sizeof(struct string)+strlen(str)' all as one
block of memory and write the string past the end of the struct.[1]
You might find a wonderful playground of debugging potential if you
try this code fiddling with your -f options: start with the ones
that get defined with -O3, particularly those that aren't defined
in -O2.
-Alan
1: this stores both the size of the string and an extra character
for the null pointer, which I do on purpose.
--
.i ma'a lo bradi cu penmi gi'e du
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] c-string return question
On Thu, Oct 13, 2011 at 02:07:04PM -0400, John Cowan wrote: Jörg F. Wittenberger scripsit: So I'll stick with the test case and remove the static keyword from the buffer definition once I have an updated gcc in my production environment. Program testing can be used to show the presence of bugs, but never to show their absence! --Edsger Dijkstra And this is especially true for Heisenbugs like this. Keep the 'static' permanently: it's safe and it costs essentially nothing. It does make the routine non-reentrant. Does that matter here? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] c-string return question
On Thu, Oct 13, 2011 at 02:46:30PM -0400, John Cowan wrote: Alan Post scripsit: It does make the routine non-reentrant. Does that matter here? I don't see how. This routine is called from Chicken, and the string gets copied into a Chicken string right away. I suppose you might want to shut off interrupts. Right! I was laboring under the illusion of posix threads. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A proposal for egg category reassignment
One of my (still being written) eggs, kiksispe'i[1], is in the misc category and is more properly described as being a game. -Alan 1: http://wiki.call-cc.org/eggref/4/kiksispehi On Wed, Oct 12, 2011 at 09:42:05AM +0200, Moritz Heidkamp wrote: Hi Ivan, first of all, thanks for your effort! Ivan Raikov ivan.g.rai...@gmail.com writes: * kalaha - Miscellaneous * ssql - Databases * ssql-postgresql - Databases I have changed or added those eggs' categories accordingly and tagged new releases for each so they should show up correctly soon unless I made a mistake somewhere. While we're at it: kalaha is a game, maybe a category Entertainment would be a useful addition, too? Moritz ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [PATCH] Compatability between eggs and chicken releases: a report on progress, and a patch!
On Tue, Oct 11, 2011 at 11:05:55PM +0100, Alaric Snell-Pym wrote:
The user-agent strings it generates look like:
chicken-install 4.7.0.3-st linux x86-64
Rather than the previous:
chicken-install 4.5.0
I think we should include the operating system version as well as
the operating system and hardware platform.
Given the way linux is distributed, I'm used to including:
os+os version = Debian 5.0
kernel+kernel version = Linux 2.6
to distinguish Debian 5 from Linux 2.6.
If I get to dream a bit, I'd love to include the compiler and it's
version as well. I'll take the opportunity to attach one of my
favorite C programs: it outputs the name and version of the compiler
it was compiled with.
-Alan
--
.i ma'a lo bradi cu penmi gi'e du
/*
* this file is in the public domain.
*
* determine which c compiler we are being compiled by
*/
static char rcsid[]=$Id: ccinfo.c,v 1.1.1.1 2006/05/17 21:32:06 apost Exp $;
#include stdio.h
#include stdlib.h
main()
{
custom();
borland();
gcc();
msc();
sunpro();
unknown();
exit(0);
}
custom()
{
if(getenv(CC_HOST)) {
char *cc;
cc=custom;
printf(%s-\n, cc);
exit(0);
}
}
borland()
{
#ifdef __BORLANDC__
char *cc;
unsigned major, minor;
cc=bcc;
major=__BORLANDC__/0x100U;
minor=__BORLANDC__%0x100U;
while(minor 0x0U==minor%0x10U) minor/=0x10U;
printf(%s-%x.%x\n, cc, major, minor);
exit(0);
#endif
}
gcc()
{
#ifdef __GNUC__
char *cc;
unsigned major, minor, patch;
cc=gcc;
major=__GNUC__;
minor=__GNUC_MINOR__;
#ifdef __GNUC_PATCHLEVEL__
patch=__GNUC_PATCHLEVEL__;
printf(%s-%u.%u.%u\n, cc, major, minor, patch);
#else
patch=0U;
printf(%s-%u.%u\n, cc, major, minor);
#endif
exit(0);
#endif
}
msc()
{
#ifdef _MSC_VER
char *cc;
unsigned major, minor;
cc=msc;
major=_MSC_VER/100U;
minor=_MSC_VER%100U;
while(minor 0U==minor%10U) minor/=10U;
printf(%s-%u.%u\n, cc, major, minor);
exit(0);
#endif
}
sunpro()
{
#ifdef __SUNPRO_C
char *cc;
unsigned major, minor;
cc=sunpro;
major=__SUNPRO_C/0x100U;
minor=__SUNPRO_C%0x100U;
while(minor 0x0U==minor%0x10U) minor/=0x10U;
printf(%s-%x.%x\n, cc, major, minor);
exit(0);
#endif
}
unknown()
{
char *cc;
cc=unknown;
printf(%s-\n, cc);
exit(0);
}
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] more: news from the valgrind front - another test case
This came to my mail reader manged, I'm not sure I'm reading it correctly. I don't think the line breaks were properly preserved. If I'm reading it correctly, this pattern could well be repeated incorrectly in other #define lines nearby--I'd want to check C_unfix, for instance, just looking at the lines in the patch, rather than chicken.h. My favorite bug of this sort happens on arm, which has an unsigned, rather than signed char, and is therefor wonderful for finding stuff like. Good find, -Alan On Sat, Oct 08, 2011 at 02:09:30PM +0200, Jörg F. Wittenberger wrote: Hi all, finally I've been able squash that one! Turns out to be a one line change to chicken.h . Otherwise valgrind is right to complain. (It shut up now too.) The missing cast would allow the compiler to write only sizeof(char). This turned out to be most often ok (whenever the rest of the word are already zero bits), but sometimes the compiler might be smarter. That's way this was highly dependant on various compiler options. CC-flags that is, not chicken. And at the same time sensitive to all sorts of memory management details, which makes it kinda random. Best Regards /Jörg --- /home/jfw/build/Scheme/chicken-core/chicken.h 2011-10-05 00:03:16.0 +0200 +++ chicken.h 2011-10-08 14:01:57.770611923 +0200 @@ -937,7 +937,7 @@ #define C_demand_2(n) (((C_word *)C_fromspace_top + (n)) (C_word *)C_fromspace_limit) #define C_fix(n) (((C_word)(n) C_FIXNUM_SHIFT) | C_FIXNUM_BIT) #define C_unfix(x) ((x) C_FIXNUM_SHIFT) -#define C_make_character(c) c) C_CHAR_BIT_MASK) C_CHAR_SHIFT) | C_CHARACTER_BITS) +#define C_make_character(c) C_word)(c) C_CHAR_BIT_MASK) C_CHAR_SHIFT) | C_CHARACTER_BITS) #define C_character_code(x) (((C_word)(x) C_CHAR_SHIFT) C_CHAR_BIT_MASK) #define C_flonum_magnitude(x) (*((double *)(((C_SCHEME_BLOCK *)(x))-data))) #define C_c_string(x) ((C_char *)(((C_SCHEME_BLOCK *)(x))-data)) On Oct 7 2011, Jörg F. Wittenberger wrote: On Oct 7 2011, Alan Post wrote: Given the odd behavior you're experiencing, I would suggest expanding your test case: Good point. Here the results: Now watch the interesting value (should be all 4 true a/a,i/i,a/i,i/a): #t#t#f#f That is: (equal? *all-chars* *all-chars*) = #t (equal? `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10)) `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) = #t (equal? *all-chars* `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) = #f (equal? `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10)) *all-chars* ) = #f Or: comparison of just initialised value fails to be equal? to the literal value. Can you/anyone reproduce this result? (So far valgrind not envolved, just this debug code in irregex-core.scm!) /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] more: news from the valgrind front - another test case
Given the odd behavior you're experiencing, I would suggest expanding your test case: (display (equal? *all-chars* *all-chars*) (current-error-port)) (newline (current-error-port)) (display (equal? `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) (current-error-port)) (newline (current-error-port)) (display (equal? *all-chars* `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) (current-error-port)) (newline (current-error-port)) Basically, hit every ridiculous but equivalent combination you can to both reduce the chance you've made a basic mistake and to tease out any underlying behavior for which the comparison you're doing might be a surface detail. -Alan On Fri, Oct 07, 2011 at 09:58:23PM +0200, Jörg F. Wittenberger wrote: There is one more - very interesting - occurrence of valgrind complaints, which point towards some possible (or highly probably that is) issue. # Current Situation I've got a pretty complex program from which I'm trying to derive test cases. At this time I see this program run for quite some time. (Before, when C_a_i_string_to_number reported issues valgrind did quit after so many messages. Now I'm watching it run for several seconds [which would be several hundreds under normal execution]. While this would cover all sorts of complicated issues there are only four valgrind complaints. Those arise both very early in the initialisation process. (According to -:D logs) Somewhere in irregex-core.scm. However this appears to be just the first case in execution order; nothing special about irregex so far. # The Test Case The test case is kind of uncommon. Sorry. I can't do better right now. (Keep in mind: this is not about irregex; more low level.) There steps ahead: 1. I'll first show that there is no problem at all. ;-) 2. Insert a stupid display statement, which is supposed to be always #t 3. Receive either #t or #t as output and an valgrind complaint when it displays #f ## 1. Proof that the problem is sort of contained: From the command line you want to run: valgrind --log-file=/tmp/csi.vg --track-origins=yes csi Now follow the file /tmp/csi.vg in another window to see when valgrind reports errors. Next wait for the friendly chicken prompt and go on: (c)2008-2011 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.7.4 (custom) linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] compiled 2011-10-07 on ajax (Linux) #;1 (use irregex) ; loading /usr/lib/chicken/6/irregex.import.so ... ; loading library irregex ... At this moment you should *not yet* have an error message. Everything *seems* fine. Exit this session. # 2. Insert Stupid Debug Code Find irregex-core.scm and insert this code right after (define (cset-complement ... -- which would be the last reference to *all-chars*. Where exactly will probably not matter at all as long as it if after the (define *all-chars*: --cut here--- % --- % --- (display \n Now watch the interesting value (should be true): (current-error-port)) (display (equal? *all-chars* `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) (current-error-port)) (display \n So much for the difference. \n (current-error-port)) --cut here--- % --- % --- This would compare *all-chars* to be EQUAL? to a literate copy of its own definition. Recompile (best with DEBUGBUILD=1) and retry the test case. Now watch the interesting value (should be true): #f So much for the difference. ## 2b. Remove valgrind from the test: jfw@ajax:~/build/chickenvg$ csi -e '(use irregex)' Now watch the interesting value (should be true): #f So much for the difference. # 3. Make it Random Case 2b (debug code plus csi) will reliably print #f (at least for about 50+ manual tries). The complex app you better don't know about will actually run printing #t in about 70% of startups (and run wild otherwise). Hrm. .. I can't find it. Best Regards /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] strange error messages when compiling with -O3 switch
On Fri, Oct 07, 2011 at 04:53:29PM +0200, j...@jugilo.de wrote: Hello all, after having rewritten my tuples egg and tried to install it with chicken-install, I got a lot of warnings of type warning: at toplevel: in procedure call in 'g..', expectet x arguments, but was given 0 I can't understand the reason for that, because according to the tests the egg works. Moreover, compiling with -O2 instead of -O3 no warnings appear. Can anyone help me? Thanks in advance Juergen My initial thought, reading this, was to wonder if you compiled your chicken with too old a chicken compiler, not performing a bootstrap. And as such you've got an inconsistent compiling generating this error message. Do other eggs/codes work? Can you reproduce this outside of the tuples egg? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] more: news from the valgrind front - another test case
On Fri, Oct 07, 2011 at 10:49:42PM +0200, Jörg F. Wittenberger wrote: On Oct 7 2011, Alan Post wrote: Given the odd behavior you're experiencing, I would suggest expanding your test case: Good point. Here the results: Now watch the interesting value (should be all 4 true a/a,i/i,a/i,i/a): #t#t#f#f That is: (equal? *all-chars* *all-chars*) = #t (equal? `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10)) `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) = #t (equal? *all-chars* `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10))) = #f (equal? `(/ ,(integer-char 0) ,(integer-char #xD7FF) ,(integer-char #xE000) ,(integer-char #x10)) *all-chars* ) = #f Or: comparison of just initialised value fails to be equal? to the literal value. Can you/anyone reproduce this result? It would assume, looking at this output, that *all-chars* is not the value of the string you're comparing it too: * it compares #t to itself. * the list compare #t to itself. * they don't ocmpare #t to each other. This suggests that *all-chars* has some value other than what you'r comparing it to. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] sandbox egg: C_emit_trace_info
The sandbox egg makes a call to the runtime.c procedure: C_emit_trace_info In commit 2d5244dd01d4e91ed6f73bb566e92f04a2ab6361 of core, this procedure was deprecated in favor of: C_emit_eval_trace_info C_emit_syntax_trace_info Below is the patch bringing the sandbox egg up-to-date with this API change. I noted that the C_emit_trace_info was mapped to C_emit_eval_trace_info, so I changed all of the calls in the sandbox egg to C_emit_eval_trace_info. Would someone that better understands this egg verify that none of the calls should instead be to C_emit_syntax_trace_info? Will someone with access rights apply this patch to the trunk branch of the sandbox egg? -Alan ++ sandbox-trace-info.patch Index: sandbox.scm === --- sandbox.scm (revision 25270) +++ sandbox.scm (working copy) @@ -455,8 +455,8 @@ (and (list? lst) (length lst) ) ) - (define (emit-trace-info info) -(##core#inline C_emit_trace_info info #f ##sys#current-thread) ) + (define (emit-eval-trace-info info) +(##core#inline C_emit_eval_trace_info info #f ##sys#current-thread) ) (define (compile-call x e) (let* ([fn (compile (car x) e #f)] @@ -466,25 +466,25 @@ (case argc [(#f) (##sys#syntax-error-hook syntax error - malformed expression x)] [(0) (lambda (v) - (emit-trace-info info) + (emit-eval-trace-info info) (check-point fuel/lambda) ((##core#app fn v)) ) ] [(1) (let ([a1 (compile (car args) e #f)]) (lambda (v) -(emit-trace-info info) +(emit-eval-trace-info info) (check-point fuel/lambda) ((##core#app fn v) (##core#app a1 v))) ) ] [(2) (let* ([a1 (compile (car args) e #f)] [a2 (compile (list-ref args 1) e #f)] ) (lambda (v) -(emit-trace-info info) +(emit-eval-trace-info info) (check-point fuel/lambda) ((##core#app fn v) (##core#app a1 v) (##core#app a2 v))) ) ] [(3) (let* ([a1 (compile (car args) e #f)] [a2 (compile (list-ref args 1) e #f)] [a3 (compile (list-ref args 2) e #f)] ) (lambda (v) -(emit-trace-info info) +(emit-eval-trace-info info) (check-point fuel/lambda) ((##core#app fn v) (##core#app a1 v) (##core#app a2 v) (##core#app a3 v))) ) ] [(4) (let* ([a1 (compile (car args) e #f)] @@ -492,12 +492,12 @@ [a3 (compile (list-ref args 2) e #f)] [a4 (compile (list-ref args 3) e #f)] ) (lambda (v) -(emit-trace-info info) +(emit-eval-trace-info info) (check-point fuel/lambda) ((##core#app fn v) (##core#app a1 v) (##core#app a2 v) (##core#app a3 v) (##core#app a4 v))) ) ] [else (let ([as (map (lambda (a) (compile a e #f)) args)]) (lambda (v) - (emit-trace-info info) + (emit-eval-trace-info info) (check-point fuel/lambda) (apply (##core#app fn v) (map (lambda (a) (##core#app a v)) as))) ) ] ) ) ) -- -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Fri, Sep 30, 2011 at 09:30:13AM +0100, Alaric Snell-Pym wrote: Your other points about multiple signals sugget it should be a proper queue, not just a bitmask. Although I have a vague feeling that Unix was allowed to coalesce pending signals as it just used a bitmask itself... Meh, I dunno, I only look into signal handling occasionally! I was misremembering a statement from APUE (Advanced Programming in the Unix Environment), which talks about signal queuing being *permitted* by Posix, but not required. And no one does it. A test program on *BSD confirms that this operating system does not, and Linux likely follows. So we don't need that queue--I think I managed to see Chicken drop one signal testing last night, but I've not confirmed this yet and it wouldn't be a crisis should it actually do so. I haven't tried a more complex case I think Chicken does suffer from, which is near-arrival of two separate signals. At any rate, my suggestion of a signal queue was based on an incorrect understanding of the signal mechanism and I withdraw it. And that we also *must* handle deferred signals before making another syscall, whether that syscall happened from user code or whether we're making a syscall in service to the need of the runtime. The one tricky case I can think of is when the chicken signal handler needs more RAM (so the GC is invoked) and the GC needs to malloc things in the heap and the heap needs to grow, so a mmap (which is what sbrk seems to be called these days) occurs... Do you need it run before ALL syscalls, or just ones that might block on something the signal handler might be needed to relieve? AIUI mmap of /dev/zero (to allocate more empty heap) can't block on very much... I'm currently hoping that it can be run just before the ones that block, which is an astute observation, thank you. I'll probably need to sit down with the signals one-by-one to be sure, but I think this weaker constraint is fully correct. I think is a fantastic outline of what needs to happen. I will work on a patch, with no guarantee of how fast I will be. Tell me if I can help - I want to gain a deeper understanding of the Chicken scheduler! Thank you! -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
Your other points about multiple signals sugget it should be a proper
queue, not just a bitmask. Although I have a vague feeling that Unix was
allowed to coalesce pending signals as it just used a bitmask itself...
In the old days, yes. Now signals have guaranteed delivery, at least if
you use sigaction() to catch them. I suspect that most of our systems
in fact will work with signal(), as it's just a thin layer over sigaction(),
but better not to rely on that.
I wrote a test program (below) to test signal delivery from C. I
was surprised to find signals being coalesced on OpenBSD, my test
system. This program for me receives far fewer than 256 signals.
I think your point about signal being a wrapper around sigaction
deserves to be repeated: it's my understanding too, and means that
as it stands, my sigaction patch is essentially or completely a
no-op on most platforms. Jerry's experience with it confusingly
not-withstanding.
-Alan
++ gcc -o child child.c ./child
#include sys/types.h
#include sys/wait.h
#include unistd.h
#include stdio.h
#include signal.h
#include stdlib.h
#include errno.h
volatile sig_atomic_t child_count=0;
void
chld(int signum)
{
++child_count;
}
main()
{
struct sigaction sa;
int i, status;
pid_t pid;
sa.sa_handler=chld;
sa.sa_flags = 0;
sigemptyset(sa.sa_mask);
sigaddset(sa.sa_mask, SIGCHLD);
sigaction(SIGCHLD, sa, 0);
for(i=0; i256; ++i) {
switch(pid=fork()) {
case -1:
fprintf(stderr, fork: %s\n, strerror(errno));
continue;
case 0:
_exit(0);
default:
break;
}
}
for(i=0; i256; ++i) {
restart_wait:
if(-1==waitpid(WAIT_ANY, status, 0)) {
if(EINTR==errno) goto restart_wait;
fprintf(stderr, wait: %s\n, strerror(errno));
break;
}
}
printf(%d\n, child_count);
exit(0);
}
--
--
.i ma'a lo bradi cu penmi gi'e du
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] EINTR with self-pipe signal trampoline
On Wed, Sep 28, 2011 at 05:29:46PM -0601, Alan Post wrote: Below is a test case for a problem I'm seeing in some multi-process code I'm writing. I'm getting the error: Error: (file-read) cannot read from file - Interrupted system call because a signal handler is going off while my main thread is in an iowait state. In C, I have always handled this by manually restarting a system call when EINTR is called. In my attached test case, I'm trying to use SA_RESTART in sigaction(2) for the same affect, and that isn't working for me. Does that actually work? I'm trying to determine which direction to head in to fix this problem, and I was surprised that SA_RESTART didn't work. Will one of you with access to a linux machine try running this code? Both in the version as seen here and also run uncommenting the two foreign-code lines. This code might have bugs that prevent it from running as intended--I'm not able to test past my EINTR problem. I'm now planning on patching file-read and file-write to restart on EINTR, unless someone has a better idea! Can I catch this exception at runtime? -Alan I investigated this further last night and can articulate better the problem. 1) The main thread sets a signal handler. 2) In then calls read(2) and blocks. 3) A signal arrives, which is handled by an internal signal handler. 4) read(2) returns -1 with errno set to EINTR. What I need to have happen here, is for the signal handling code to then be run, which will write(2) to the pipe. I then need the signal handler to be run (which happens on the main thread) At which point I *then* need to restart the read(2) call, which now will have pending data. I can't introduce a version of read(2) that restarts on EINTR: doing that causes the signal handler to never be run, so we pause forever in a deadlock. I don't understand enough about the scheduler to know when interrupts get handled. Can it happen while executing the scheme code in file-read? If signals get delivered at a reliable point, read can likely be restarted knowing the signal has been handled. If not, I'm left with needing to catch the error, somehow guarantee that the signal handler has been run, then call my code again (to re-enter read) When does the scheduler handle interrupts? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] EINTR with self-pipe signal trampoline
On Thu, Sep 29, 2011 at 01:11:49PM +0200, Jörg F. Wittenberger wrote: On Sep 29 2011, Alan Post wrote: Below is a test case for a problem I'm seeing in some multi-process code I'm writing. I'm getting the error: Error: (file-read) cannot read from file - Interrupted system call There are two ways to fix that: either make the posix unit thread safe (recall my recent message how to avoid process-wait having a bad effect). The other one is working around the problem. That's what I'm doing based on some code Felix supplied ages ago. It wraps the file descriptors into custom ports those are properly restarted on EINTR. However I'd be rather interested to learn what exactly the problem is you observe. Recently (maybe 4.7.3 or .4) I'm seeing missbehavior from formerly well working code. I can't say that's chickens fault but neither I can say it's not. If I understand the part of the code below that wraps read/write, it can't be used as-is for my problem. Because chicken defers signals, a signal is delivered, deferred, then read/write return with EINTR. If I immediately restart these syscalls (all in the same C call), the deferred signal has not be delivered, and the code deadlocks, as read/write pauses--blocking the signal handler from ever being run. I need a way to deliver deferred signals after a syscall returns EINTR, before restarting that syscall. You may well not notice this in non-blocking code, as no data would be ready on the file descriptor and the code would continue running--eventually to deliver the deferred signal and unwedge everything. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] remove enable/disable interrupt flag
This patch removes the enable/disable interrupt flag from the scheduled. I can't see that this code is referenced. I'm not sure someone would just write this feature for fun, however. Is this code actually used? I'm preparing a larger patch for the signal handling code, so knowing whether this is used (and how) is important for getting my next set of patches correct. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 07:12:20AM -0600, Alan Post wrote:
This patch removes the enable/disable interrupt flag from the
scheduled.
I can't see that this code is referenced. I'm not sure someone
would just write this feature for fun, however. Is this code
actually used?
I'm preparing a larger patch for the signal handling code, so
knowing whether this is used (and how) is important for getting
my next set of patches correct.
-Alan
--
.i ma'a lo bradi cu penmi gi'e du
Let's attach the patch, shall we? Reviewing this, I had to add a
thunk to the C_fudge routine, case 14. It is not the least bit
obvious what that routine does, or how case 14 gets called. What
is that? It's the only part I don't consider straightforward, other
than my already mentioned use of this feature I'm not seeing.
diff --git a/chicken.h b/chicken.h
index 8c6eff3..1739fb9 100644
--- a/chicken.h
+++ b/chicken.h
@@ -1527,8 +1527,6 @@ C_fctexport C_word C_fcall C_callback_wrapper(void *proc,
int argc);
C_fctexport void C_fcall C_callback_adjust_stack(C_word *base, int size);
C_fctexport void CHICKEN_parse_command_line(int argc, char *argv[], C_word
*heap, C_word *stack, C_word *symbols);
C_fctexport void C_fcall C_toplevel_entry(C_char *name) C_regparm;
-C_fctexport C_word C_fcall C_enable_interrupts(void) C_regparm;
-C_fctexport C_word C_fcall C_disable_interrupts(void) C_regparm;
C_fctexport void C_fcall C_paranoid_check_for_interrupt(void) C_regparm;
C_fctexport void C_zap_strings(C_word str);
C_fctexport void C_set_or_change_heap_size(C_word heap, int reintern);
diff --git a/runtime.c b/runtime.c
index c0c91bc..980f303 100644
--- a/runtime.c
+++ b/runtime.c
@@ -331,7 +331,6 @@ C_TLS int
C_gui_mode = 0,
C_abort_on_thread_exceptions,
C_enable_repl,
- C_interrupts_enabled,
C_disable_overflow_check,
#ifdef C_COLLECT_ALL_SYMBOLS
C_enable_gcweak = 1,
@@ -697,7 +696,6 @@ int CHICKEN_initialize(int heap, int stack, int symbols,
void *toplevel)
chicken_is_running = chicken_ran_once = 0;
interrupt_reason = 0;
last_interrupt_latency = 0;
- C_interrupts_enabled = 1;
C_initial_timer_interrupt_period = INITIAL_TIMER_INTERRUPT_PERIOD;
C_timer_interrupt_counter = INITIAL_TIMER_INTERRUPT_PERIOD;
memset(signal_mapping_table, 0, sizeof(int) * NSIG);
@@ -2669,7 +2667,7 @@ C_regparm void C_fcall C_reclaim(void *trampoline, void
*proc)
/* assert(C_timer_interrupt_counter = 0); */
- if(interrupt_reason C_interrupts_enabled)
+ if(interrupt_reason)
handle_interrupt(trampoline, proc);
/* Note: the mode argument will always be GC_MINOR or GC_REALLOC. */
@@ -4102,8 +4100,9 @@ C_regparm C_word C_fcall C_fudge(C_word fudge_factor)
case C_fix(13): /* debug mode */
return C_mk_bool(debug_mode);
+ /* XXX: Where is this called from, how do we deprecate it? */
case C_fix(14): /* interrupts enabled? */
-return C_mk_bool(C_interrupts_enabled);
+return C_mk_bool(1);
case C_fix(15): /* symbol-gc enabled? */
return C_mk_bool(C_enable_gcweak);
@@ -4244,34 +4243,16 @@ C_regparm void C_fcall
C_paranoid_check_for_interrupt(void)
C_regparm void C_fcall C_raise_interrupt(int reason)
{
- if(C_interrupts_enabled) {
-saved_stack_limit = C_stack_limit;
+ saved_stack_limit = C_stack_limit;
#if C_STACK_GROWS_DOWNWARD
-C_stack_limit = C_stack_pointer + 1000;
+ C_stack_limit = C_stack_pointer + 1000;
#else
-C_stack_limit = C_stack_pointer - 1000;
+ C_stack_limit = C_stack_pointer - 1000;
#endif
-interrupt_reason = reason;
-interrupt_time = C_cpu_milliseconds();
- }
-}
-
-
-C_regparm C_word C_fcall C_enable_interrupts(void)
-{
- C_timer_interrupt_counter = C_initial_timer_interrupt_period;
- /* assert(C_timer_interrupt_counter 0); */
- C_interrupts_enabled = 1;
- return C_SCHEME_UNDEFINED;
-}
-
-
-C_regparm C_word C_fcall C_disable_interrupts(void)
-{
- C_interrupts_enabled = 0;
- return C_SCHEME_UNDEFINED;
+ interrupt_reason = reason;
+ interrupt_time = C_cpu_milliseconds();
}
--
.i ma'a lo bradi cu penmi gi'e du
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] replace signal with sigaction
This patch replaces signal with sigaction for registering signals.
sigaction is a newer API for signal processing that fixes some
deficiencies of the original signal API. One fix can be seen in
this patch: we don't have to reregister the signal handler after
a signal is sent.
That prevents a race condition whereby a signal is delivered, our
signal handler is reset, and before we can reregister our signal
handler, another signal is sent (which we then miss).
I'm not sure even signal() behaves this way these days.
It used to be one tested for sigaction in the same way you might
test for other features. I'm not sure if chicken runs on a
platform that doesn't have sigaction--do I need to add a feature
test for this and preserve the existing capability on platforms
without sigaction?
-Alan
diff --git a/chicken.h b/chicken.h
index 1739fb9..4f5847a 100644
--- a/chicken.h
+++ b/chicken.h
@@ -859,7 +859,7 @@ DECL_C_PROC_p0 (128, 1,0,0,0,0,0,0,0)
# define C_isatty isatty
# define C_fileno fileno
# define C_select select
-# define C_signal signal
+# define C_sigactionsigaction
# define C_getrusagegetrusage
# define C_tolower tolower
# define C_toupper toupper
diff --git a/runtime.c b/runtime.c
index 980f303..eb64f92 100644
--- a/runtime.c
+++ b/runtime.c
@@ -982,7 +982,6 @@ void initialize_symbol_table(void)
void global_signal_handler(int signum)
{
C_raise_interrupt(signal_mapping_table[ signum ]);
- signal(signum, global_signal_handler);
}
@@ -4259,11 +4258,18 @@ C_regparm void C_fcall C_raise_interrupt(int reason)
C_regparm C_word C_fcall C_establish_signal_handler(C_word signum, C_word
reason)
{
int sig = C_unfix(signum);
+ struct sigaction new, old;
- if(reason == C_SCHEME_FALSE) C_signal(sig, SIG_IGN);
- else {
+ new.sa_flags = 0;
+ sigemptyset(new.sa_mask);
+
+ if(reason == C_SCHEME_FALSE) {
+new.sa_handler = SIG_IGN;
+C_sigaction(sig, new, old);
+ } else {
signal_mapping_table[ sig ] = C_unfix(reason);
-C_signal(sig, global_signal_handler);
+new.sa_handler = global_signal_handler;
+C_sigaction(sig, new, old);
}
return C_SCHEME_UNDEFINED;
--
.i ma'a lo bradi cu penmi gi'e du
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] EINTR with self-pipe signal trampoline
On Thu, Sep 29, 2011 at 03:26:22PM +0200, Jörg F. Wittenberger wrote: Attempt work around: defer the signal even more: until next schedule time. I'm not yet satisfied with that solution. (But at least it allows me to run arbitrary code in the signal handler.) (I intended so far to try whether it would be better to run it close to the finalizers; that is at the end of garbage collection. But that again is just an experiment TBD.) Given your situation I hope we can devise a better way. I'd need to understand your situation better. I need a way to deliver deferred signals after a syscall returns EINTR, before restarting that syscall. I see. I understand you need minimum latency - right? May I ask for more details. I need to understand where this latency requirement is important. Let me try a demonstration showing just the main thread: (define (restart-read fd buf isize) ; call read(2), on the self-pipe, which blocks (let ((r (file-read fd buf isize))) (if (= -1 r) ; ah, a signal was delivered. In Chicken, the signal ; delivery to the prcoess causes this error, but the ; Scheme code signal handler might not have been ; delivered. In this case, it means that I haven't ; written a byte to the self-pipe yet. ; (if (= errno EINTR) ; restart the read. Normally, we would have written ; to our self-pipe already (as the signal is delivered ; the moment we return from our syscall.), but in ; Chicken, I'm not sure our deferred Scheme code has ; been called. When does that happen? If it hasn't ; happened yet, I'll block in this routine, and the ; deferred signal handler will never run. ; ; I need a way to guarantee that the deferred signal ; handler has already been run, before I call any other ; syscall. ; (restart-read fd buf isize)) ; something else went wrong, die. (io-error read Does that story make more sense? Chicken may already behave this way, I'm not sure how long it waits/when it delivers a deferred signal. The critically important thing is that it do so before making another syscall. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 03:43:16PM +0200, Jörg F. Wittenberger wrote: On Sep 29 2011, Alan Post wrote: This patch removes the enable/disable interrupt flag from the scheduled. I can't see that this code is referenced. I'm not sure someone would just write this feature for fun, however. Is this code actually used? Be careful! I found it to be win to actually reference and use that code. I do lot's of process-fork. The childs will soon be replaced by another program. Why should they spend time in garbage collection before the exec call? Futhermore it's dangerous to leave all threads enabled after a fork. I've seen cases when those subprocess managed to write to file descriptors used by the parent. That's one the the things on my list: find some better way to do the fork. So far I do (define-foreign-variable C_interrupts_enabled bool C_interrupts_enabled) (define (chicken-enable-interrupts!) (set! C_interrupts_enabled #t)) (define chicken-disable-interrupts! (foreign-lambda void C_disable_interrupts)) (let ((pid (begin (chicken-disable-interrupts!) ((foreign-lambda int fork)) )) (if (not (= pid 0)) (chicken-enable-interrupts!)) ... ) I figured if someone was using this, it would be you! Thank you for this use case. I'll account for it now. I withdraw this patch--I do consider this code broken--including the test case above (it has a race condition where a signal might be delivered before the fork but after the disable interrupts), though this is not the only case in the signal handling code where this is true. I'll resubmit a new patch. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] EINTR with self-pipe signal trampoline
On Thu, Sep 29, 2011 at 03:26:22PM +0200, Jörg F. Wittenberger wrote: Signal handlers as they are in chicken might be problematic. I can't find the message, but I recall a reply these days, which informed me that it's true that chicken interrupt handlers are in fact in a restricted dialect of Scheme: they can not allocate memory. I'm not sure how one would write a signal handler in chicken that doesn't allocate memory. It seems even relatively primitive signal handlers, like my example case, do so: (file-write output-pipe (string (integer-char signum I count that as two boxing operations, one that might not be doable on the stack (I don't know yet how Chicken Scheme allocates strings and therefor whether it does so on the stack. Then of course whatever memory is required to traverse the sexpr--I don't know how Chicken handles that yet either. The objects allocated could be done in advance, as you know what signal numbers you'll be receiving, but I've just assumed the deferral mechanism for signals is done in part to allow memory to be allocated inside them, because they're called in the main thread (or some rough equivalent). *C* signal handlers can't allocate memory, for sure--I'd consider it poor form to do something in a Chicken signal handler that isn't adviseable from a C signal handler, but the runtime environment makes that boundary fuzzy, for me. I started to read into it. I too, still don't understand all of the C_reclaim procedure. But it's obvious that the interrupt handler is invoked at the begin of the garbage collection. Wild guess: there is no memory available for allocation at that time. Given that a thread or a signal handler get their own stacks, and that Chicken uses the stack as a first-generation semispace/nursery, I'm not sure why conceptually one couldn't just execute the runtime inside a signal handler. There are things I'd forbid: no signals delivered during GC, no GC in the signal handler, c. It may well be nothing but hair all the way down, but architecturally I haven't imagined anything to prevent it. Attempt work around: defer the signal even more: until next schedule time. I'm not yet satisfied with that solution. (But at least it allows me to run arbitrary code in the signal handler.) (I intended so far to try whether it would be better to run it close to the finalizers; that is at the end of garbage collection. But that again is just an experiment TBD.) Interesting approach. In conversation with you, I have determined that what has to happen to preserve the execution model is that signals are delivered before a syscall is performed. It appears to me right now that any time at all between a return from a syscall and the next syscall are fine for signal delivery--that leaves a lot of room. .i ko .e mi ze'aca kelgu'a (let's keep hacking), -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] replace signal with sigaction
On Thu, Sep 29, 2011 at 10:44:42AM -0400, John Cowan wrote: Alan Post scripsit: It used to be one tested for sigaction in the same way you might test for other features. I'm not sure if chicken runs on a platform that doesn't have sigaction--do I need to add a feature test for this and preserve the existing capability on platforms without sigaction? Win32 systems (not including Cygwin) have signal() but not sigaction(). The only signals on Win32 are SIGABRT, SIGFPE, and SIGSEGV. SIGILL and SIGTERM can be trapped, but they can only happen if you raise them yourself with raise(). SIGINT can also be trapped, but that's a bad idea, because the handler will be run on a separate Win32 thread. All of our other hosts implement sigaction(). I'm very happy you had this information to hand--I had not quite remembered how the signal() interface survived C ANSI-fication and you just laid it out for me. Does the ANSI C behavior specify that a signal must be re-registered after it is called? Is it more reliable for me to follow the ANSI C standard or the w32 documentation on this interface? If w32, where do I find that? I will submit a new patch that includes a feature test so this code will work on w32. .i.ioki'edo mu'o mi'e .alyn. -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 04:35:04PM +0100, Alaric Snell-Pym wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 04:25 PM, Jörg F. Wittenberger wrote: POSIX says that fork needs to produce only a single surviving POSIX thread in the child. Perhaps Chicken fork needs to do the same with Chicken threads. Alaric, that's exactly the effect and reason why I'm using this disable-interrupts/enable-interrupts around fork: to make sure there is only this one Chicken-threads running in the child. With interrupts disabled there is no scheduling in chicken. (At least not until you run into a thread-yield! anyway.) And therefore I'd really recommend to keep it in the runtime. I think a better mechanism would be a way to abort all threads but the current one, triggered after the fork in the child, with no interrupts until the thread murder is complete. If you just go off and exec after the fork it'd be better to uninterruptably vfork-then-exec, but we have procedures to do that already! Aborting all threads but the one that asked for the fork also gives one the opportunity to inform them of this fact, should any of them leave useful data structures in incosistent states with locks held. There's something to be said for requesting permission to fork from all threads before doing so, so they can make sure they finish any operations on shared state in the parent, but that'll be complex, and a potential performance bottleneck, so probably not worth it! ABS In posix threads, this is what pthread_atfork() is for--to clean up resources in the process of joining threads across a fork. The way Chicken is currently implemented, any signal that arrives during this time is discarded, which also makes me unhappy with this situation. A lot of blood and tears were spilled over signal handling on Unix to get to reliable signal delivery. I don't think Chicken should implement unreliable signal delivery on top of a reliable mechanism. It seems that the thread-like nature of signal handling and the thread-like nature of threading have been intermixed in the scheduler, and this particular feature is at cross-purposes. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] replace signal with sigaction
On Thu, Sep 29, 2011 at 05:45:46PM +0200, Jörg F. Wittenberger wrote:
Here an interesting finding:
On Sep 29 2011, Alan Post wrote:
This patch replaces signal with sigaction for registering signals.
sigaction is a newer API for signal processing that fixes some
deficiencies of the original signal API. One fix can be seen in
this patch: we don't have to reregister the signal handler after
a signal is sent.
That prevents a race condition whereby a signal is delivered, our
signal handler is reset, and before we can reregister our signal
handler, another signal is sent (which we then miss).
Since I'm quite old school I've been used to the meaning of signals
to be almost reliable. Except under arbitrary complex usage
restrictions.
Hence I rarely ever tried to count signals, but use them as a hint,
which operation would be in order.
This might have been not enough!
Turn out that with your patch applied something changed:
I had one usage case, which almost sure (say ~50%+-25%) would run
into that eat-all-memory condition. I tried too often, I fail to
reproduce the condition.
However at this time I can't convince myself that this is not a false
positive. :-/
Even with my patch, there is still a bug in the chicken signal
handler:
void global_signal_handler(int signum)
{
C_raise_interrupt(signal_mapping_table[ signum ]);
}
This signal handler will notify the main thread that signal X has
been raised, but it doesn't keep track of how often that happens.
By the time we get around to handling this signal, it could have
been raised more than once, and we only fire our signal handler
once regardless of how many signals were delivered between the
original interrupt and executing the deferred handler.
If you're doing anything at all that is reasonably interrupt
heavy, you're going to be seeing this behavior. The quick test
would be to fork a few hundred children (that all immediately
exit) all at once and count the number of times SIGCHLD is raised.
I haven't written this test yet, it's my next test case to follow
my EINTR test--though I suspect you'll get fewer SIGCHLD interrupts
than you had spawned children.
I also suspect there is a condition here where the signal handler
flags the interrupt to be raised, but we're already servicing the
deferred signal, and it goes ahead and resets the
signal_mapping_table before the signal currently being raised is
handled by deferral. If you're coping with unreliable delivery
from the above method, maybe you're seeing this case instead, which
would be a different class of behavior.
Rather than 1 or more deferred signals being delivered for N signals
raised, you might well see 0 under this condition--If this can happen
at all. I'm assuming it can, looking at the code, but haven't
verified yet.
-Alan
--
.i ma'a lo bradi cu penmi gi'e du
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 05:06:54PM +0100, Alaric Snell-Pym wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 04:47 PM, Alan Post wrote: It seems that the thread-like nature of signal handling and the thread-like nature of threading have been intermixed in the scheduler, and this particular feature is at cross-purposes. So it seems... Signals should always end up being handled somewhere, unlessly explicitly set to be ignored; in that case, ignoring it IS handling it, but not otherwise. I'll add too that signals have an API-level mechanism for ignoring them, which we should probably use. And yes. IIRC, signals are handled by setting a flag and poking the stack limit then returning. A GC is then invoked as soon as the interrupted thread tries to allocate memory, due to the poked stack limit, but the GC checks for the signal flag and goes off to do the signal if it has to. I presume that invoking the Chicken runtime inside the C-level signal handler is unsafe on account of Chicken wanting to call non-signal-safe C functions. It would be something of a minor miracle were this not true. I think it is technically achievable, though I say that with zero understanding of the actual effort involved. It's more my ideal case worth banging my head against a few times than something I think we can do in practice. I presume that allocating memory in a Chicken-level signal handler is risky as you might have actually been at or near the stack limit when the signal happened. I have not looked at the mechanism in code - just heard hearsay about it - - so please take this suggestion with a pinch of salt: 1) Have a (signal-safe) data structure containing pending signals. This might just be a bitmask, or if we want to be flash, a queue of generic pending software interrupts if there's uses for it other than signals. 2) C-level signal handlers poke an entry into the structure indicating the need to invoke a Chicken signal handler, and poke the stack limit [all of the above is basically what I think we already have] 3) The GC, invoked due to the stack limit being breached, checks for pending signals. If there are any, it resets the stack limit to what it was originally, then modifies the currently active continuation to a newly-allocated one that invokes a system procedure which executes all pending signals, then continues to the previous continuation; and returns. The normal stack limit needs to be set so that there will always, in the worst case, be enough space to allocate that extra continuation frame. If the system WAS at the edge of the stack when the signal(s) came in, it would then still be able to allocate the special continuation; execution of it would then almost instantly trigger a perfectly ordinary GC, and execution would continue as usual, executing the pending signal handler(s) then continuing with user code as before. The Minix source code is illustrative on this point. I think a program being near the stack limit when a signal arrives is the only time in that operating system that a process will be killed without the normal mechanims the kernel goes through--It just tosses the thing out. I've never looked at how this behaves on *BSD or Linux, but I imagine there is a similar condition (or as you outline above, a reserve available). So this comes up even in C, which at least on Minux is not a handleable condition. We effectively can't handle it if our GC makes a syscall--I imagine that we minimally call sbrk() (or whatever the kids call it these days) in the event of a full, post-GC heap. That may well be a terminal case in this rabbit hole, mirroring the terminal case in the C code. That would give you low latency, unless the GC really needed to happen, in which case... well... it needs to happen before the handler can run. It would run signal handlers in the context of the currently executing thread when they happened, so to all intents and purposes it would be normal Chicken code, and the current thread would just temporarily dart off into signal handlers when required; I'm not sure what dynamic environment (in the parameters/current-output-port) they should be in; neither do I know how they are implemented in Chicken! Perhaps they should encapsulate a copy of the dynamic environment in place when the signal handler was registered, as the most hygienic option... I pretty much rely on my registered signal handler being in the dynamic environment it was declared in. The EINTR test case uses this to get hold of a file descriptor created in the main thread. I'll add that we might of course get a signal while performing GC, a case that needs to be accounted for. And that we also *must* handle deferred signals before making another syscall, whether that syscall happened from user code or whether we're making a syscall in service to the need of the runtime. I think is a fantastic outline of what
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 06:56:03PM +0200, Jörg F. Wittenberger wrote: On Sep 29 2011, Alan Post wrote: The way Chicken is currently implemented, any signal that arrives during this time is discarded, which also makes me unhappy with this Wait, I'm confused. During which time signals are really discarded? As far as I read the source, the signal will be recorded, not discarded. If a signal is called when C_interrupts_enabled is false, the signal handler turns into a no-op. global_signal_handler calls C_raise_interrupt, but C_raise_interrupt does nothing if C_interrupts_enabled is false, the entire routine is contained in that if statement. My reading of that is that a signal being delivered when C_interrupts_enabled is false wil cause that signal to be discarded. Yes? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] replace signal with sigaction
On Thu, Sep 29, 2011 at 02:15:29PM -0400, John Cowan wrote: Alan Post scripsit: Does the ANSI C behavior specify that a signal must be re-registered after it is called? Is it more reliable for me to follow the ANSI C standard or the w32 documentation on this interface? If w32, where do I find that? The Woe32 documentation is silent about such fine points: the interface probably dates back to Windows 3 or even MS-DOS. For future reference, it's at http://msdn.microsoft.com/en-us/library/634ca0c2.aspx . Before the specified function is executed, the value of func is set to SIG_DFL. The next interrupt signal is treated as described for SIG_DFL, unless an intervening call to signal specifies otherwise. This feature lets you reset signals in the called function. That's good enough (well not really *good*, but *enough*) to know how to implement signal handling on missing-sigaction platforms. Thank you, -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 08:35:41PM +0200, Jörg F. Wittenberger wrote: On Sep 29 2011, Alan Post wrote: If a signal is called when C_interrupts_enabled is false, the signal handler turns into a no-op. global_signal_handler calls C_raise_interrupt, but C_raise_interrupt does nothing if C_interrupts_enabled is false, the entire routine is contained in that if statement. My reading of that is that a signal being delivered when C_interrupts_enabled is false wil cause that signal to be discarded. Yes? Yes. That's what I've been talking about in the next paragraph. With the changes I made (did I post them, did not I?) this problem is gone. Hence my question how to clean up the API. Default to possibly useless re-calling the handler (while it assumes possibly having missed a signal and hence re-check everything)? Provide a modified API which covers both cases? ... It may have been posted before I was really attending to this conversation. I can't find it in my archive. Would you mind sending it to me again? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] valgrind
On Thu, Sep 29, 2011 at 09:38:44PM +0200, Jörg F. Wittenberger wrote: I'm still asking myself why I can't run chicken program under valgrind. Since there's a lot going on at this time I'm about to forget. Hence here an update for those who care and the archive. I've traced the call coming from irregex.c down to valgrind complaining as soon as *all-chars* value is accessed. (I did not yet come around to prepare a test case where I'd only cons up a random list (or a list of char's - wild guess) and see if I can sync valgrind's output enough to verify that it will complain on code which is supposed to work at all counts.) (The back of my head now might be about to forget that a less expensive implementations of charset and their merges might be obvious; even in R5RS Scheme. Right now they are a pretty nice test case to see how much a few instructions shaved from the cons operation would speed up the program initialization over all.) Furthermore I'd know that chicken might to weird things to the stack. Maybe valgrind was just a bad choice. Wild guess again. But as far as I understand valgrind so far (which is close to nothing at all), it would instrument then executable code only. Given that I see access to uninitialized memory resulting from stack allocation - I wonder: maybe valgrind is right? Now, at this time it my memory consumption issue does not appear. Real work is pressing. I'll not find the time to dig deeper into these things any time soon. Except if I'm wrong about the does not appear. /Jerry Since it seems as good a day as any for wild-ass speculation, what about this scenario: We allocate an object, set the tag pointer, but don't fill out all of the memory yet. We're yet to need it. Oops! The gc gets called, and that object has to move. So we memcpy it to it's new home and tuck it into bed. Wouldn't valgrind complain that we just memcpy'd uninitialized memory, even though in this case it is a completely safe operation? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] remove enable/disable interrupt flag
On Thu, Sep 29, 2011 at 10:20:28PM +0200, Jörg F. Wittenberger wrote: On Sep 29 2011, Alan Post wrote: Hence my question how to clean up the API. Default to possibly useless re-calling the handler (while it assumes possibly having missed a signal and hence re-check everything)? Provide a modified API which covers both cases? ... It may have been posted before I was really attending to this conversation. I can't find it in my archive. Would you mind sending it to me again? Not at all. Given the doubt whether or not this conversation pertains to the before mentioned issue https://bugs.call-cc.org/ticket/668 I'm not sure: should we take this conversation private for a while or not. The situation is: right now I'm running from a modified chicken. Changes have been made to a) the signal handling b) the finalizer_list and list constructors as posted recently c) the scheduler and srfi-18 (ages ago) d) for historic reasons: the time representation (see below for an excuse) At least for (d) there is no reason for you to swallow that one. (c) might fix a bug - risky enough if your code relies on it -- or it may introduce one my code relies on. The note to take to the chicken community: it's a nice feature in a way, that chicken needs only on .h and on .c file plus your code. But this features now shows it's downside: it's hard to merge independent changes. It's hard to track the common ground. However (c) does have some overlap with (a) - which would be what you are interested in to begin with. We will not be able to reconcile without manual intervention. Worse: (a) and (d) do overlap in runtime.c and chicken.c (for what the excuse is worth)... Alan, what would be the best? Several postings on the list detailing the changes (good for documentation; needs manual integration always; thereby forcing code review)? A full diff from current git to my current state of affairs (watch out for excuses below!)? /Jörg Fun! I'd rather look at an isolated a), even if it doesn't compile, than try to digest the rest of this too. If you can just send me the parts of your tree that pertain to a), even if that patch does not result in code that compiles, that would help me the most. It's ok if, for instance, I get a patch that leads off into b, c, or d and you just fail to include that. Will you do this? I am curious to see your signal handling patch. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] replace signal with sigaction
On Thu, Sep 29, 2011 at 07:25:31AM -0600, Alan Post wrote:
This patch replaces signal with sigaction for registering signals.
sigaction is a newer API for signal processing that fixes some
deficiencies of the original signal API. One fix can be seen in
this patch: we don't have to reregister the signal handler after
a signal is sent.
That prevents a race condition whereby a signal is delivered, our
signal handler is reset, and before we can reregister our signal
handler, another signal is sent (which we then miss).
I'm not sure even signal() behaves this way these days.
It used to be one tested for sigaction in the same way you might
test for other features. I'm not sure if chicken runs on a
platform that doesn't have sigaction--do I need to add a feature
test for this and preserve the existing capability on platforms
without sigaction?
-Alan
I have ammended this patch to include a HAVE_SIGACTION define,
to preserve the existing functionality on w32 systems.
diff --git a/Makefile.bsd b/Makefile.bsd
index 5eab203..98e44fd 100644
--- a/Makefile.bsd
+++ b/Makefile.bsd
@@ -83,6 +83,7 @@ chicken-config.h: chicken-defaults.h
echo #define HAVE_LONG_LONG 1 $@
echo #define HAVE_MEMMOVE 1 $@
echo #define HAVE_MEMORY_H 1 $@
+ echo #define HAVE_SIGACTION 1 $@
echo #define HAVE_STDINT_H 1 $@
echo #define HAVE_STDLIB_H 1 $@
echo #define HAVE_STRERROR 1 $@
diff --git a/Makefile.cygwin b/Makefile.cygwin
index f56bc29..cee6e74 100644
--- a/Makefile.cygwin
+++ b/Makefile.cygwin
@@ -95,6 +95,7 @@ chicken-config.h: chicken-defaults.h
echo #define HAVE_LONG_LONG 1 $@
echo #define HAVE_MEMMOVE 1 $@
echo #define HAVE_MEMORY_H 1 $@
+ echo #define HAVE_SIGACTION 1 $@
echo #define HAVE_STDINT_H 1 $@
echo #define HAVE_STDLIB_H 1 $@
echo #define HAVE_STRERROR 1 $@
diff --git a/Makefile.haiku b/Makefile.haiku
index 1f86bc3..54634a2 100644
--- a/Makefile.haiku
+++ b/Makefile.haiku
@@ -71,6 +71,7 @@ chicken-config.h: chicken-defaults.h
echo #define HAVE_LONG_LONG 1 $@
echo #define HAVE_MEMMOVE 1 $@
echo #define HAVE_MEMORY_H 1 $@
+ echo #define HAVE_SIGACTION 1 $@
echo #define HAVE_STDINT_H 1 $@
echo #define HAVE_STDLIB_H 1 $@
echo #define HAVE_STRERROR 1 $@
diff --git a/Makefile.linux b/Makefile.linux
index c713b45..6e5116a 100644
--- a/Makefile.linux
+++ b/Makefile.linux
@@ -72,6 +72,7 @@ chicken-config.h: chicken-defaults.h
echo #define HAVE_LONG_LONG 1 $@
echo #define HAVE_MEMMOVE 1 $@
echo #define HAVE_MEMORY_H 1 $@
+ echo #define HAVE_SIGACTION 1 $@
echo #define HAVE_STDINT_H 1 $@
echo #define HAVE_STDLIB_H 1 $@
echo #define HAVE_STRERROR 1 $@
diff --git a/Makefile.macosx b/Makefile.macosx
index b4a44d9..da612a4 100644
--- a/Makefile.macosx
+++ b/Makefile.macosx
@@ -96,6 +96,7 @@ chicken-config.h: chicken-defaults.h
echo #define HAVE_LONG_LONG 1 $@
echo #define HAVE_MEMMOVE 1 $@
echo #define HAVE_MEMORY_H 1 $@
+ echo #define HAVE_SIGACTION 1 $@
echo #define HAVE_STDINT_H 1 $@
echo #define HAVE_STDLIB_H 1 $@
echo #define HAVE_STRERROR 1 $@
diff --git a/Makefile.solaris b/Makefile.solaris
index f2d4dee..84dc433 100644
--- a/Makefile.solaris
+++ b/Makefile.solaris
@@ -102,6 +102,7 @@ chicken-config.h: chicken-defaults.h
echo #define HAVE_LONG_LONG 1 $@
echo #define HAVE_MEMMOVE 1 $@
echo #define HAVE_MEMORY_H 1 $@
+ echo #define HAVE_SIGACTION 1 $@
echo #define HAVE_STDINT_H 1 $@
echo #define HAVE_STDLIB_H 1 $@
echo #define HAVE_STRERROR 1 $@
diff --git a/chicken.h b/chicken.h
index 1739fb9..a154fbe 100644
--- a/chicken.h
+++ b/chicken.h
@@ -859,7 +859,11 @@ DECL_C_PROC_p0 (128, 1,0,0,0,0,0,0,0)
# define C_isatty isatty
# define C_fileno fileno
# define C_select select
+# if defined(HAVE_SIGACTION)
+# define C_sigactionsigaction
+# else
# define C_signal signal
+# endif
# define C_getrusagegetrusage
# define C_tolower tolower
# define C_toupper toupper
diff --git a/runtime.c b/runtime.c
index 980f303..68e3c90 100644
--- a/runtime.c
+++ b/runtime.c
@@ -982,7 +982,9 @@ void initialize_symbol_table(void)
void global_signal_handler(int signum)
{
C_raise_interrupt(signal_mapping_table[ signum ]);
+#if !defined(HAVE_SIGACTION)
signal(signum, global_signal_handler);
+#endif
}
@@ -4259,11 +4261,28 @@ C_regparm void C_fcall C_raise_interrupt(int reason)
C_regparm C_word C_fcall C_establish_signal_handler(C_word signum, C_word
reason)
{
int sig = C_unfix(signum);
+#if defined(HAVE_SIGACTION)
+ struct sigaction new, old;
- if(reason == C_SCHEME_FALSE) C_signal(sig, SIG_IGN);
- else {
+ new.sa_flags = 0;
+ sigemptyset(new.sa_mask
Re: [Chicken-users] another proposal to modify runtime.c
On Wed, Sep 28, 2011 at 01:41:03PM +0200, Jörg F. Wittenberger wrote: I can't resist to propose another minor code improvement. For this one I even recall where I learned the trick: early in my CS studies, we been taken to analyse how we could do better than the straight forward implementation of double linked lists. (Which would be the implementation of e.g., the finalizer_list in runtime.c) The idea is: unlinking requires too many conditionals. The solution would be: you don't want to keep a pointer to the list elements (which in case of the empty list would be NULL) as root. Instead you use a static list node (thereby wasting the unused memory for the payload). As end-of-list marker you don't use NULL, but the address of that root node. You initialize the root nodes previous and next to the address of the root node. Now you can save all those conditionals. Unlinking is turned into two straight forward updates of the previous and next pointers handing on the corresponding fields of the node. Saves a few line, conditional and looks IMHO more clever. Though I'm biased by the abovementioned history. Find the diff attached. /Jörg I've heard this called a dummy head list. I didn't think people wrote linked list code any other way... You use one extra cons cell and remove all the beginning of list checks you'd otherwise require. I thought this part came standard. ;-) Good catch. It's a trick I've been able to use well outside of C programming. Heck, I think my egg, genturfahi, uses this one somewhere. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] EINTR with self-pipe signal trampoline
Below is a test case for a problem I'm seeing in some multi-process
code I'm writing. I'm getting the error:
Error: (file-read) cannot read from file - Interrupted system call
because a signal handler is going off while my main thread is in an
iowait state. In C, I have always handled this by manually
restarting a system call when EINTR is called. In my attached test
case, I'm trying to use SA_RESTART in sigaction(2) for the same
affect, and that isn't working for me. Does that actually work?
I'm trying to determine which direction to head in to fix this
problem, and I was surprised that SA_RESTART didn't work. Will one
of you with access to a linux machine try running this code? Both
in the version as seen here and also run uncommenting the two
foreign-code lines.
This code might have bugs that prevent it from running as
intended--I'm not able to test past my EINTR problem. I'm now
planning on patching file-read and file-write to restart on EINTR,
unless someone has a better idea! Can I catch this exception at
runtime?
-Alan
PS: this code is using this trick: http://cr.yp.to/docs/selfpipe.html
++ eintr.scm
;;;
;;; self-pipe signal trampoline.
;;;
;;; this test case should:
;;;
;;; * register SIGUSR1 and SIGCHLD as signal trampolines using the
;;; self-pipe trick.
;;; * spawn a child process which:
;;; - sends SIGUSR1 to the parent.
;;; - enters an iowait state forever. (to be killed by our
;;; parent)
;;; * simultaneously, in the parent:
;;; - we perform a blocking read on our self-pipe, and wait for
;;; one of two signals:
;;; SIGUSR1: send SIGTERM to our child process
;;; SIGCHLD: call wait and then exit ourselves.
;;;
;;; Instead, file-read is called and enters a blocking state. Our
;;; signal is raised, causing file-read to return EINTR. Normally,
;;; one would restart the syscall. I'm not sure how one does this
;;; in Chicken Scheme, or if you can.
;;;
;;; Even deferring to a C implementation of the signal trampoline
;;; which properly sets SA_RESTART does not seem to help.
;;;
(use posix)
; restart system calls on EINTR.
;
(foreign-declare #EOS
#include sys/types.h
#include unistd.h
#include signal.h
#include errno.h
void trampoline(int signum)
{
char b[1];
int saved_errno=errno;
b[0] = (char)(unsigned)signum;
/* hack: I know my output pipe fd in this test case. */
write(5, b[0], 1);
errno=saved_errno;
}
void register_trampoline(int signum)
{
struct sigaction new, old;
int r;
new.sa_handler = trampoline;
new.sa_flags = SA_RESTART;
sigemptyset(new.sa_mask);
/* hack: ignoring the return value */
r = sigaction(signum, new, old);
}
EOS
)
(call-with-values
create-pipe
(lambda (input-pipe output-pipe)
; signal handler. write the signal received to our self-pipe.
;
(define (trampoline signum)
(file-write output-pipe (string (integer-char signum
; helper routine to read a single (unbuffered) byte and convert
; it to an integer (here representing a signal number).
;
(define (read1 fd)
(char-integer (string-ref (car (file-read input-pipe 1)) 0)))
(define (child)
; close our parent's self-pipe
(file-close input-pipe)
(file-close output-pipe)
; and reset (not technically true, but another bug not
; relevant to this test case) our signal handlers.
;
(set-signal-handler! signal/usr1 #f)
(set-signal-handler! signal/chld #f)
; send our parent SIGUSR1, which should result in
; our parent sending us a SIGTERM.
;
(process-signal (parent-process-id) signal/usr1)
(call-with-values
create-pipe
(lambda (input-pipe output-pipe)
; pause (iowait) until we get our SIGTERM.
;
(read1 input-pipe)
; never actually executed.
;
(file-close input-pipe)
(file-close output-pipe)
(exit 0
(define (parent pid)
(case (read1 input-pipe)
((signal/usr1) (process-signal pid) (parent pid))
((signal/chld) (process-wait pid
; register our signal trampoline
;
(set-signal-handler! signal/usr1 trampoline)
(set-signal-handler! signal/chld trampoline)
; or, register our signal trampoline.
;
; uncomment these lines to test SA_RESTART
;
;(foreign-code register_trampoline(SIGUSR1);)
;(foreign-code register_trampoline(SIGCHLD);)
; fork our child and do event handling.
;
(let ((pid (process-fork)))
(case pid
((0) (child))
(else (parent pid))
--
--
.i ma'a lo bradi cu penmi gi'e du
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
Will you show me this data for the current implementation? -Alan On Thu, Sep 29, 2011 at 10:30:00AM +0900, Alex Shinn wrote: On Wed, Sep 28, 2011 at 4:29 AM, Alan Post alanp...@sunflowerriver.org wrote: I don't have enough data to say that it matters in this case, but in principle it surely does. In theory, theory and practice are the same. In practice, they're different. The problem here specifically is the lack of data. Why even bother with a change like this without benchmark results to prove it's worth it (preferably tested across all the variety of platforms Chicken compiles on, with wildly differing branch prediction features)? The proper way to optimize is: 1) DON'T! Just write an application. If it's too slow for your purposes, then move on to 2) Profile. Find out where all the time is being spent. There's no point in optimizing something if it's not a significant factor in you performance. 3) Of the code sections you've determined the most time is being spent in, choose the one with the best estimated speedup-to-effort ratio. You should have an intuition that the code in question can be improved, either algorithmically (potential huge speedup) or by tuning (smaller speedup, usually uglier code, but may be less effort). Making this choice is something of an art, but is completely impossible without 2. 4) Write benchmarks that isolate what you want to optimize. Measure how fast the current solution is, if possible compared to alternative implementations or equivalent tasks in other languages. 5) If you don't already have a test suite, write one now that verifies the code used in the benchmark. It's too easy to write an optimized version of something that performs better initially, but worse once you fix the bugs in it. 6) Try one or more optimizations, and measure them compared to the result in 4 once they've passed the tests in 5. Iterate as often as you have time/ideas. 7) Of the best results in 6, determine if the speedup they introduce is worth the complexity they introduce. Keep in mind the maintenance cost will persist long term, and be shared by other people who want to work on the code. 8) Document what you tried regardless so people don't waste the same effort again! Include a one-line comment in the code itself with a link to more info if needed, e.g. ;; The following is a little ugly, but performs best in ;; practice - see benchmarks/widget-hack.scm. 9) Send a patch to the list with the benchmarks and tests as proof that the optimization is worth it. If you've come this far, the maintainers will almost certainly accept it. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Thu, Sep 29, 2011 at 12:09:19PM +0900, Alex Shinn wrote: On Thu, Sep 29, 2011 at 11:40 AM, Alan Post alanp...@sunflowerriver.org wrote: Will you show me this data for the current implementation? The first implementation doesn't need to justify itself, just be working. *nods* How did irregex, which by account is slower, replace the existing regex code? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Thu, Sep 29, 2011 at 12:33:41PM +0900, Alex Shinn wrote: On Thu, Sep 29, 2011 at 12:25 PM, Alan Post alanp...@sunflowerriver.org wrote: How did irregex, which by account is slower, replace the existing regex code? I didn't make the call, but as I understand that was motivated by portability concerns, simplifying the Chicken distribution, and avoiding the frequently occurring memory bugs in PCRE. So speed wasn't a concern, but there is a class of regexps for which irregex is exponentially faster than PCRE. -- Alex Thank you Alex. I understand, between all of this, that the bar is raised on smaller changes (and it probably ought to be, it's easier to bike shed a smaller change) but that usefully disruptive changes can be larger and require a lower burden of proof for inclusion. For the dubious purpose of pedantic completeness, This conversation does not include any proof of your second paragraph: that these exponentially faster regexps come up in practice: there's no citation of data or test cases to back up such an assertion. I did, for the first time this week, use a feature of irregex that was more than straightforward translation of a regex into irregex syntax. It was a light-bulb moment for me, as I was previously using irregex as a drop-in replacement and not appreciating it, for what I suspect are all the reason you're motivated to participate in this conversation. . -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] difference between ##sys#error and posix-error?
Looking at posixunix.scm, I find that some error messages are produced with ##sys#error, and others with posix-error. What distinguishes these two routines? Why would I use one but not the other? -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] two minor tweaks to runtime.c
On Tue, Sep 27, 2011 at 09:21:15PM +0200, Jörg F. Wittenberger wrote: On Sep 27 2011, Peter Bex wrote: On Tue, Sep 27, 2011 at 03:22:06PM +0200, Jörg F. Wittenberger wrote: While I've been looking at the code I wondered if the C compiler will fur sure pull that one test out of the for-loop. Maybe it's better no have it there at the first place. IMHO the code is not more confusing to read this way and should run better in case the C compiler is not smart enough. I'm firmly opposed to any such change that makes the code much less readable for very little gain. Please excuse me objecting. IMHO the code is not less readable the rewritten way. In fact - and so far it's a matter of taste - I would find it less confusing. (Let alone that it's fewer instructions.) However I'm quite old school. If I can tell the compiler something and not rely on the compilers cleverness, I'll do so. (And NOT do so iff I want to create a test case for the compiler.) In the case at hand I applied something which would have been typical educational example in the late 70th: pull conditionals out of frequently executed code if you can. Is there anybody on the list who has a test case at hand, which would exercise cons/list operations or initialisation code? (Mine would be suspicious in this case.) Looking at alternativ compilers (besides gcc) would be very nice. The chance, which - depending on taste, would make the code either more comprehensible or less - could have an actual effect. That would be the final argument in my case. FWIW I agree with Jörg'sreasoning. I've spend a fair bit of my C programming time removing conditional code from loops. It has been a few years since I tested, but when I was actively writing C code, removing opportunities for the branch predictor to fail measurably sped up code. I don't have enough data to say that it matters in this case, but in principle it surely does. Jörg's code is obvious to me in the manner of ah, that's removing a conditional from inside the for loop. BTW, I've loved reading the comments and patches suddenly flying around the mailing list. I'm learning a lot about Chicken and am particularly interested to see which parts of the system apparently receive attention and which aren't being changed. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken vs Perl
On Tue, Sep 20, 2011 at 02:11:41PM +0200, Sascha Ziemann wrote: The Perl version takes for my test tree about two seconds: real 0m1.810s user 0m1.664s sys 0m0.140s [snip] And now hold on tight! It takes more than one minute for the same data: real 1m16.540s user 1m14.849s sys 0m0.664s And there is almost no significant performance boost by compiling it: real 0m1.810s user 0m1.664s sys 0m0.140s It looks like you have a copy-and-paste error here? It would appear that compiling the code makes it precisely as fast as perl. ;-) -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Fwd: Re: process-wait
On Sat, Sep 03, 2011 at 10:30:24AM -0400, John Cowan wrote: Jörg F. Wittenberger scripsit: But wait: Jules is right: somehow there needs to be some arrangement that there's a waitpid sure before the process exists on any other way to prevent zombies on the system. Does anyone have a suggestion how to assure that? If the parent process calls sigaction() on SIGCHLD and set the sa_handler to SIG_DFL and the sa_flags to SA_NOCLDWAIT, then its children will not become zombies, but will just vanish. See http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html I don't understand some of the details regarding the Chicken Scheduler as it is being talked about in this thread, so please excuse me if I demonstrate that ignorance here, but it is important to me to be able to wait for children I spawn and collect their exit status--this is a feature I use and need to retain. If the runtime is going to change the way that this works, I still need the ability to check the status of my child processes, and not to have that all automatically done. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] script to generate html from wiki-formatted text?
On Thu, Sep 01, 2011 at 12:04:58PM +0200, Christian Kellermann wrote: * felix winkelmann fe...@call-with-current-continuation.org [110901 11:58]: Maybe adding a simple clause like: (depends-on-external libexif source: http://libexif.sf.net;) to the .meta file (of libexif in this case) which can be queried by chicken-install. So the user has a chance to get a complete list of all dependencies in advance instead of having to trip on each one by one. Does this make sense? Yes, indeed. I'd suggest foreign-depends (but it doesn't matter). The property-value should be free-form, but have one element per dependency. Ok, I will start hacking on this. Thank you Christian, I would appreciate this feature too. -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] process-wait
On Thu, Sep 01, 2011 at 10:02:18AM -0700, chi...@bmedctr.com wrote: Hello, * Message sent: 01 Sep 2011 14:16:44 +0200 * For quite some time I've been wondering why my app runs only about twice as fast on chicken compared to rscheme (given the benchmark style performance of chicken code). strace was my friend to pin this down to process-wait. From the manual: Suspends the current process...Note that suspending the current process implies that all threads are suspended as well. Too bad, my app spent it's time waiting for irrelevant processes, not running useful threads as I'd like it to. This shouldn't be too hard to fix, I thought - and wrote the code I'll paste and comment. (With the intention that this might go into the posix unit eventually.) Once the issues I have are resolved, that is. However those are harder than I expected: (Side note: even with bad the code here my app feels much better, since the coughing is gone.) ... The idea is to convert (process-wait pid #f) into (process-wait pid #t) and block the current tread only when the first result is zero. Sounds indeed frustrating. I've run across similar problems while writing a multitasking web server. It uses process-fork to create child processes which handle the client requests. Under Linux, the parent may wait, or not, for the child to finish, If not, the child doesn't go away--it's a zombie--until the parent ends, unless the default signal handler flags are set to a NOWAIT value. If NOWAIT is not yes, you need to capture the SIGCHLD signal and call waitpid(2) (or a related function) to collect the exit status of a terminated child process. A zombie process is one which is terminated but is storing this information for the parent process. So, what you say is true. :-) -Alan -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (exit) not exiting ...
I cringed at your describing this code as working! I intended it to be a test; if |exit| or |_exit| were not terminating your program, I wondered if it was rare but possible condition of the kernel/C library not permitting exit (the kernel holding a frozen I/O resource for your process and your doing funny things with |atexit| being the two ways I'm aware of to keep |exit| from terminating a process. It looks like it is something Chicken is doing, however, as your process is able to be terminated. I wonder what it could be? -Alan On Tue, Jul 12, 2011 at 10:23:35PM -0700, Matt Welland wrote: Yep, that works! It looks right at home with the existing hacks and will do until I get to some refactoring Thanks for the solution! On Tue, Jul 12, 2011 at 6:01 PM, Alan Post [1]alanp...@sunflowerriver.org wrote: What happens if you call?: (use posix) (process-signal (current-process-id) signal/kill) -Alan On Tue, Jul 12, 2011 at 05:25:24PM -0700, Matt Welland wrote: I have some code that was evolved rather than designed and is admittedly a bit of a mess and I needed to add an (exit) deep in a block where running a sub process has failed. However the (exit) never exits. This is true both if I run compiled or interpreted. I have tried to make a small test case but I can't reproduce the issue. I even replaced the (exit) with a call to a function that prints a message and then does exit and it still doesn't exit. I also tried _exit with the same result. Any suggestions on what to look at or how to debug this? My attempt to reproduce (which works fine) is below: (define foo 8) (define (runbroke cmd) (handle-exceptions exn (begin (print FAILED! exn= exn) #f) (cmd))) (define bar 9) (let ((res (runbroke (lambda ()(process nadafoobar -l -blah) (if (not res) (begin (print Failed to run, exiting with code 7) (exit 7 (exit bar) BTW, the code is visible at [1][2]www.kiatoa.com/fossils/megatest, in cmd-run-proc-each-line in process.scm. References Visible links 1. [3]http://www.kiatoa.com/fossils/megatest ___ Chicken-users mailing list [4]Chicken-users@nongnu.org [5]https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du References Visible links 1. mailto:alanp...@sunflowerriver.org 2. http://www.kiatoa.com/fossils/megatest 3. http://www.kiatoa.com/fossils/megatest 4. mailto:Chicken-users@nongnu.org 5. https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] (exit) not exiting ...
What happens if you call?: (use posix) (process-signal (current-process-id) signal/kill) -Alan On Tue, Jul 12, 2011 at 05:25:24PM -0700, Matt Welland wrote: I have some code that was evolved rather than designed and is admittedly a bit of a mess and I needed to add an (exit) deep in a block where running a sub process has failed. However the (exit) never exits. This is true both if I run compiled or interpreted. I have tried to make a small test case but I can't reproduce the issue. I even replaced the (exit) with a call to a function that prints a message and then does exit and it still doesn't exit. I also tried _exit with the same result. Any suggestions on what to look at or how to debug this? My attempt to reproduce (which works fine) is below: (define foo 8) (define (runbroke cmd) (handle-exceptions exn (begin (print FAILED! exn= exn) #f) (cmd))) (define bar 9) (let ((res (runbroke (lambda ()(process nadafoobar -l -blah) (if (not res) (begin (print Failed to run, exiting with code 7) (exit 7 (exit bar) BTW, the code is visible at [1]www.kiatoa.com/fossils/megatest, in cmd-run-proc-each-line in process.scm. References Visible links 1. http://www.kiatoa.com/fossils/megatest ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi cu penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] EQV? and NaN
On Mon, Jul 11, 2011 at 11:04:09PM +0200, Felix wrote: From: John Cowan co...@mercury.ccil.org Subject: Re: [Chicken-users] EQV? and NaN Date: Mon, 11 Jul 2011 16:58:09 -0400 Felix scripsit: (eqv? +nan +nan) being #t would mean violation of R5RS. Technically, yes. But R5RS didn't anticipate the strange behavior of NaN. Furthermore, the discrepancy doesn't seem to bother the developers and users of Gauche, Gambit, Bigloo, Kawa, Scheme48, Chibi, or STklos, all of which are R5RS systems. Just for the record, and to spare you the typing: I generally don't care what all of those systems do. The only authorities that I find acceptable are R5RS, common sense, performance and convenience. It seems that R5RS is violating common sense, and not intentionally so, as John tried to articulate in his message. -Alan -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] test custom feeds url 404
On Fri, May 06, 2011 at 08:09:12AM -0400, Mario domenech Goulart wrote: Hi Alan, On Thu, 5 May 2011 21:07:47 -0600 Alan Post alanp...@sunflowerriver.org wrote: On the nightly tests page: http://tests.call-cc.org/ There is a link to the custom feeds: http://tests.call-cc.org/feeds/custom which is generating a 404 message for me. I used to have there the file: http://tests.call-cc.org/feeds/custom/alanpost.xml Which I used to monitor the nightly builds for my packages of interest. What happened to this? Did it move? Is it down? I really liked this feature, can I have it back? Since we have salmonella results for OpenBSD/x86 (thanks to Christian) we have changed the directory layout for feeds and results to accommodate multiple branches, hardware and software platforms. See http://lists.nongnu.org/archive/html/chicken-users/2011-03/msg00097.html for more details. The tests.call-cc.org index links were indeed broken. They are fixed now. Thank you for reporting the problem. Best wishes. Mario -- http://parenteses.org/mario Thatk you Mario, On the tests.call-cc.org page, the link for OpenBSD points to the Linux custom feeds. I think the last link on the page should be: http://tests.call-cc.org/feeds/experimental/openbsd/x86/custom/ -Alan -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] test custom feeds url 404
On the nightly tests page: http://tests.call-cc.org/ There is a link to the custom feeds: http://tests.call-cc.org/feeds/custom which is generating a 404 message for me. I used to have there the file: http://tests.call-cc.org/feeds/custom/alanpost.xml Which I used to monitor the nightly builds for my packages of interest. What happened to this? Did it move? Is it down? I really liked this feature, can I have it back? -Alan -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Large file support
On Tue, Mar 29, 2011 at 09:59:08AM -0400, Mario domenech Goulart wrote: Hi, Is compiling Chicken with _FILE_OFFSET_BITS=64 considered safe on 32bit platforms? I've quickly tried it on Linux/x86 and it seems to work fine. Is there anything I should be aware regarding to this setting? The only issue that comes to mind for me is if someone were not using an off_t when seeking on a file descriptor, which could cause integer overflow. But that would be a bug and you should find it and fix it. :-D -Alan -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Possibly of interest to some, I put a couple of my chicken based projects online ...
What are you using that test harness for? That program seems really neat, would you mind talking more about it? -Alan On Sun, Mar 13, 2011 at 09:51:51PM -0700, matt welland wrote: I've been waiting for some free time to clean it up before making some of my projects public but obviously that day will never come. So, for better or for worse I've put a few of my little projects at http://www.kiatoa.com/fossils/opensrc just in case they are of use to someone. Cheers, Matt -=- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Equivalent for Python's __name__?
(car (argv)) Is what I think you get. -Alan On Thu, Mar 03, 2011 at 11:38:53AM -0500, Andrew Pennebaker wrote: I'd like to find out my Chicken script name programmatically. Something like Python's __name__, or Perl/Ruby's $0 would be very helpful. Cheers, Andrew Pennebaker [1]www.yellosoft.us References Visible links 1. http://www.yellosoft.us/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Equivalent for Python's __name__?
On Thu, Mar 03, 2011 at 05:50:26PM +0100, Thomas Chust wrote: 2011/3/3 Andrew Pennebaker andrew.penneba...@gmail.com: I'd like to find out my Chicken script name programmatically. [...] Hello Andrew, program-name [1] is a built in parameter exported from the chicken library unit that returns the name of the currently executing program or script. Ciao, Thomas [1] http://wiki.call-cc.org/man/4/Parameters#program-name \o/ TIL. -Alan -- .i ma'a lo bradi ku penmi gi'e du ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Save the Gazette!
Ivan, I understood Alaric's message to be a request to take the commit log, c, regardless of the form they are in, and convert that directly into a form useable by the gazette: Summarized, formatted, and checked in to the repository. -Alan On Wed, Feb 16, 2011 at 07:04:28PM +0900, Ivan Raikov wrote: Hi Alaric, Thanks for volunteering to write editorial content. As for your requests, I believe that you can already do 2) by using the Trac RSS feed: http://bugs.call-cc.org/timeline?ticket=onchangeset=onmilestone=offwiki=offmax=50daysback=7format=rss Obviously you can set the 'daysback' parameter to whatever you wish. Reasonable RSS readers allow you to filter the feed by creator and other criteria. I don't remember the URL to the git browser, but perhaps there is an RSS option there as well. As for 4), one can probably replace the creator tag in the RSS XML with the user's real name, rather than messing with the wiki or HTML. -Ivan Alaric Snell-Pym ala...@snell-pym.org.uk writes: When a community agrees it'd be cool to do something on a regular basis, to begin with, there's a lot of enthusiasm and volunteering, so things go well. However, a crucial point comes at which producing that thing starts to become a chore, no matter how popular the product is. At this point, if measures are not put into place to make it continue, it dies out. The Gazette is reaching that point, and I want to save it. I am happy to write editorial content such as recipes and mailing-list summaries, as long as I have time (and it doesn't take me long, I'm notoriously verbose in even the simplest of emails ;-), but I can't (personally) stomach the tedious part: going through the svn and git commit logs to find out what's happened, and then mapping git/svn identities to real names and people's pages on the wiki. So, I propose that you lot should automate it for me. I want: 1) The users page on the wiki to, in parens or brackets or something, after each person's name, list their various identities used in IRC / svn usernames / etc. so they can be easily tallied together 2) A script that, when run in a local svn checkout, or maybe by talking direct to SVN, lists all the eggs that have seen commits in a specified time period (with the option of right up to now as the end of the time period); and then lists the commit messages and revision numbers (for deeper investigation, if required) for each. For extra points, make sure that tagging a version of an egg is clearly indicated somehow (eg, TAGGED 1.5). This should all be a relatively simple matter of parsing the svn logs. 3) A script that, when run in a local git checkout, or maybe by talking direct to the core git repo, lists all the commits in a specified time period, grouped by branch. 4) All scripts should map usernames found in svn/git to displayed names via a function that defaults to identity. Somebody else please write a function to replace this, that looks in the wiki page and parses it to map svn/git identities to Wiki markup for the user's user page with their full name as the anchor text, that can be inserted into the above scripts to make wonderful magic happen. For bonus points, the output of scripts (2) and (3) could be actual markup for putting straight into the gazette, say as a bulleted list, just requiring editing to remove useless commits and to add editorial insight. Super special bonus point: 5) Write a script that, given a date range, parses the mailing list archive into wiki markup for a list of links to the posts in the archive, along with links to the user's pages as per (4), grouped by thread. I think that the above are relatively bite-sized chunks that people who want to see the Gazette continue should be able to manage between them; if the above are done then, if needed, I'd be willing to pioneer alone with running them each week (or every other week at worst) and writing some content around them! So, volunteers please :-) ABS ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Implementing a macroexpand-all
If you figured it out that would be amazing. I'm not sure myself what the core binding forms are, but this is a very interesting problem, I'm enjoying reading about you digging it up. -Alan On Fri, Feb 11, 2011 at 03:10:03PM -0500, Patrick Li wrote: Great. Thanks for that tip! I think I will try and figure it out. As long as I can figure out what the core binding-introducing forms are, I think I can do it. -Patrick On Fri, Feb 11, 2011 at 2:56 PM, Peter Bex [1]peter@xs4all.nl wrote: On Fri, Feb 11, 2011 at 02:46:58PM -0500, Patrick Li wrote: The when should not be macroexpanded because it is a local binding introduced by the let form. In that context, it is actually *not* a macro. Does anyone know which forms introduce new bindings? How can I check this up? I'm afraid to really do this properly you'd need to implement your own macro-expander. You need to do all sorts of bookkeeping to get your syntactic environments straight. The macro-expander needs to know about core forms like LET and extend the environment accordingly when those are used. See expand.scm in Chicken core (hairy!), or alexpander in the Chicken 3 egg repo (cleaner, but still rather tricky) for an example of such things. Cheers, Peter -- [2]http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth References Visible links 1. mailto:peter@xs4all.nl 2. http://sjamaan.ath.cx/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Need help on sxpath/txpath
On Sat, Jan 29, 2011 at 09:32:10PM +0900, Daishi Kato wrote: At Fri, 28 Jan 2011 16:45:06 +0100, Peter Bex wrote: I suck at xpath so I have no idea. You could try the SSAX mailinglist... Before trying the ssax ML, I looked the code again. Because I didn't find big difference in ssax code, I assumed this is a chicken-specific bug. And, found it! Yes, Peter. In release/3/sxml-tools/extras/string-utils.scm, (define (substring? pattern str) (string-contains str pattern)) However, in release/4/sxpath/trunk/chicken/[st]xpath.scm, (define substring? string-contains) which is obviously incorrect. Could you fix this please? I might find another bug, but I'll wait your fix and double check it. Thanks for your help, even if you suck at xpath. Best, Daishi Well done Daishi. Congratulations. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] matchable egg usage question
On Sat, Jan 29, 2011 at 11:23:54AM +0900, Alex Shinn wrote:
So by deliberately limiting match we force people
to write faster code. At the same time, it's more
verbose code - if you really want a match as powerful
as prolog you could implement it and deal with the
fact that it can be very slow in some cases. And in
that case you will eventually need to add a way to
explicitly commit matches (i.e. cut in prolog) for
decent performance.
[I'm not completely consistent in this, though,
because the tree patterns I added do in fact
require more complex searching and backtracking.
But tree searches require this in general.]
Alex, will you explain what I'd doing wrong here using
tree searching patterns?
(pretty-print (map
(match-lambda
(('foo *** '(bar 1)) #t)
(_ #f))
'((foo (bar 1))
(foo (a (bar 1)))
(foo (a (b (bar 1
(foo (a (b (c (bar 1
Only the first form |(foo (bar 1))| is returning #t here.
The remaining forms return #f. I would expect all of them
to return true, based on my naive understanding of the ***
operator.
-Alan
--
.i ko djuno fi le do sevzi
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] matchable egg usage question
On Sun, Jan 30, 2011 at 12:28:00PM +0900, Alex Shinn wrote:
On Sun, Jan 30, 2011 at 12:09 PM, Alan Post alanp...@sunflowerriver.org
wrote:
Alex, will you explain what I'd doing wrong here using
tree searching patterns?
(pretty-print (map
(match-lambda
(('foo *** '(bar 1)) #t)
(_ #f))
'((foo (bar 1))
(foo (a (bar 1)))
(foo (a (b (bar 1
(foo (a (b (c (bar 1
Only the first form |(foo (bar 1))| is returning #t here.
The remaining forms return #f. I would expect all of them
to return true, based on my naive understanding of the ***
operator.
'foo has to match every step of the path. It sounds
like you want
('foo (_ *** '(bar 1)))
Wonderful! This is working for the test cases I sent, but it
doesn't seem to work when I have a list where the first element
is also a list:
(pretty-print (map
(match-lambda
(('foo (_ *** '(bar 1))) #t)
(_ #f))
'((foo (bar 1))
(foo (a (bar 1)))
(foo (a (b (bar 1
; these three fail
(foo ((a (b (bar 1)
(foo (a ((b (bar 1)
(foo (a (b ((bar 1
I don't understand why the last three examples fail to match the
pattern here. I would expect them all to match, or if that weren't
true I'd expect all but the last one to match.
-Alan
--
.i ko djuno fi le do sevzi
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: matchable egg usage question
On Thu, Jan 27, 2011 at 10:21:05PM -0700, Alan Post wrote: I'm trying to use the matchable egg to detect #!key parameters in functions I've constructed. I have functions that accept multiple #!key parameters, and I'm not sure how to make the matchable egg match |(func ... mykey: myvalue ...)|. That is, how to get the matchable egg to match two parameters anywhere in an input list. This is what I've got so far. I am interested in whether the #!key paramater 'a' is set to #t: (use matchable) (pretty-print (map (match-lambda ((_ 'a: #t . _) '(0 #t)) ((_ ... 'a: #t) '(1 #t)) (_ #f)) '((foo) (foo bar) (foo a: #f) (foo a: #f b: #t) (foo a: #f b: #t c: #t) (foo a: #f c: #t b: #t) (foo b: #t a: #f c: #t) (foo b: #t c: #t a: #f) (foo a: #t) (foo a: #t b: #t) (foo a: #t b: #t c: #t) (foo a: #t c: #t b: #t) (foo b: #t a: #t c: #t) (foo b: #t c: #t a: #t (exit) This works for every case except when the #!key I want to match appears in the middle of a list of arguments, as happens in the second-to-last case I'm trying to match. Is there a way to make match work in this case? What pattern should I add to match values anywhere in the list, not just the front and end? I've solved my problem by matching every sublist of my argument list until I find the pattern I'm looking for: (use matchable) (use srfi-1) (define (key-match? pat r) (or r (match pat (`(a: #t . ,_) #t) (_ #f (pretty-print (map (match-lambda ((_ . args) (pair-fold key-match? #f args)) (_ #f)) '((foo) (foo bar) (foo a: #f) (foo a: #f b: #t) (foo a: #f b: #t c: #t) (foo a: #f c: #t b: #t) (foo b: #t a: #f c: #t) (foo b: #t c: #t a: #f) (foo a: #t) (foo a: #t b: #t) (foo a: #t b: #t c: #t) (foo a: #t c: #t b: #t) (foo b: #t a: #t c: #t) (foo b: #t c: #t a: #t (exit) (The match-lambda here is wordier in my real example, I know it is pointless in this example.) -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: matchable egg ticket #487
On Sat, Jan 29, 2011 at 10:52:15AM +0900, Alex Shinn wrote: On Fri, Jan 28, 2011 at 12:15 AM, Alan Post alanp...@sunflowerriver.org wrote: I'm only going to get more demanding out of what I'd like match to do, I would like the latest version. I've updated matchable from the latest upstream, which includes the fix. Thank you Alex. I've updated my copy of the matchable egg, removed the workaround I was using to avoid triggering the bug, and after that change my regression tests all pass. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: matchable egg ticket #487
I'm only going to get more demanding out of what I'd like match to do, I would like the latest version. -Alan On Thu, Jan 27, 2011 at 10:17:19PM +0900, Alex Shinn wrote: Fixed upstream, including http://synthcode.com/scheme/match-cond-expand.scm, which is basically suitable for Chicken modulo the module syntax. Do we want the latest version for Chicken (with tree patterns and ..1), or should I just patch this one bug? -- Alex On Tue, Jan 25, 2011 at 8:32 AM, Alan Post alanp...@sunflowerriver.org wrote: On Tue, Jan 25, 2011 at 07:51:12AM +0900, Alex Shinn wrote: On Sun, Jan 23, 2011 at 3:01 PM, Alan Post alanp...@sunflowerriver.org wrote: I've just come across a bug in the matchable egg which I've documented in ticket #487: http://bugs.call-cc.org/ticket/487 A call is made to |length| even when the input isn't a list if a production contains |...|. Thanks, those tail-patterns are a relatively recent extension and this is indeed a bug. I'll fix it ASAP. I tried using |...| as something of a last resort trying to match a tail pattern, thinking I wonder if the ... in the documentation is literal, rather than elision. I couldn't figure out any other way to match a tail pattern. Given that they are new, I see now I may have used something that wasn't documented, which clears up a confusion of mine. I wrote such a lengthy test case just to prove to myself that ... was working like I expected it to. These tail-pattern matches are a time-saver for me. In one particular case I have a complex set of boolean variables that I use to generate code, and I use match later on in the routine in order to determine what happened, rather than reusing the boolean variables to see if I made a modification. Basically, I have: if A do x, y if B do y, z if C do x, z and I mant to make sure I do x, y, or z only once, even if there are multiple variables set that require it. Thank you Alex! -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] matchable egg usage question
I'm trying to use the matchable egg to detect #!key parameters in functions I've constructed. I have functions that accept multiple #!key parameters, and I'm not sure how to make the matchable egg match |(func ... mykey: myvalue ...)|. That is, how to get the matchable egg to match two parameters anywhere in an input list. This is what I've got so far. I am interested in whether the #!key paramater 'a' is set to #t: (use matchable) (pretty-print (map (match-lambda ((_ 'a: #t . _) '(0 #t)) ((_ ... 'a: #t) '(1 #t)) (_ #f)) '((foo) (foo bar) (foo a: #f) (foo a: #f b: #t) (foo a: #f b: #t c: #t) (foo a: #f c: #t b: #t) (foo b: #t a: #f c: #t) (foo b: #t c: #t a: #f) (foo a: #t) (foo a: #t b: #t) (foo a: #t b: #t c: #t) (foo a: #t c: #t b: #t) (foo b: #t a: #t c: #t) (foo b: #t c: #t a: #t (exit) This works for every case except when the #!key I want to match appears in the middle of a list of arguments, as happens in the second-to-last case I'm trying to match. Is there a way to make match work in this case? What pattern should I add to match values anywhere in the list, not just the front and end? -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: matchable egg ticket #487
On Tue, Jan 25, 2011 at 07:51:12AM +0900, Alex Shinn wrote: On Sun, Jan 23, 2011 at 3:01 PM, Alan Post alanp...@sunflowerriver.org wrote: I've just come across a bug in the matchable egg which I've documented in ticket #487: http://bugs.call-cc.org/ticket/487 A call is made to |length| even when the input isn't a list if a production contains |...|. Thanks, those tail-patterns are a relatively recent extension and this is indeed a bug. I'll fix it ASAP. I tried using |...| as something of a last resort trying to match a tail pattern, thinking I wonder if the ... in the documentation is literal, rather than elision. I couldn't figure out any other way to match a tail pattern. Given that they are new, I see now I may have used something that wasn't documented, which clears up a confusion of mine. I wrote such a lengthy test case just to prove to myself that ... was working like I expected it to. These tail-pattern matches are a time-saver for me. In one particular case I have a complex set of boolean variables that I use to generate code, and I use match later on in the routine in order to determine what happened, rather than reusing the boolean variables to see if I made a modification. Basically, I have: if A do x, y if B do y, z if C do x, z and I mant to make sure I do x, y, or z only once, even if there are multiple variables set that require it. Thank you Alex! -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] matchable egg ticket #487
Hello Alex, I've been using your matchable egg and am really happy with it. I've been using it to make the compiler for my parser, genturfa'i, more sophisticated so that I can make the runtime code much simpler. Having taken a quick look at the code, it doesn't seem like it derives from Andrew Wright's implementation, please correct me if I'm wrong. I've just come across a bug in the matchable egg which I've documented in ticket #487: http://bugs.call-cc.org/ticket/487 A call is made to |length| even when the input isn't a list if a production contains |...|. I've worked around this problem in my code by adding an extra production to guard against a symbol being checked by any later production containing |...|. Since I can work around the problem, it isn't urgent. It would be awesome all the same if you could look at the ticket and see if there is a more systematic problem in the code. Thank you! -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: obscure error message after refactoring
On Thu, Jan 20, 2011 at 01:59:34PM -0700, Alan Post wrote: On Thu, Jan 20, 2011 at 12:20:29PM -0700, Alan Post wrote: On Thu, Jan 20, 2011 at 08:46:16AM -0700, Alan Post wrote: On Thu, Jan 20, 2011 at 06:58:27AM -0700, Alan Post wrote: I've been refactoring the interface between 3 of the subsystems in my egg, genturfa'i. I've made a ton of changes to the code, and am at the point where I'm ready to compile everything and figure out what is broken. I run chicken-install -s, and as it tries to compile my library, gives me the following error: Error: (caddr) bad argument type: * Call history: syntax (##core#begin (define genturfahi-version-major 0) (define genturfahi-version-minor 0) (define gentur.. syntax (define genturfahi-version-major 0) syntax (##core#set! genturfahi-version-major 0) syntax (define genturfahi-version-minor 0) syntax (##core#set! genturfahi-version-minor 0) syntax (define genturfahi-version-patch 1) syntax (##core#set! genturfahi-version-patch 1) syntax (define genturfahi-version trunk) syntax (##core#set! genturfahi-version trunk) syntax (##core#undefined)-- Error: shell command terminated with non-zero exit status 17920: /opt/chicken-master/bin/chicken chicken-ext.scm -output-file genturfahi.c -dynamic -feature chicken-compile-shared -feature compiling-extension -setup-mode -debug-level 2 -emit-import-library genturfahi I don't have an explicit call to caddr anywhere in my code, and I believe the following line: syntax (##core#set! genturfahi-version trunk) Refers to the last line in the last file of my library. I've been looking over diffs trying to see if I've introduced a subtle scope or syntax error somewhere, but I'm not having much luck. What do I do with an error message like the one above? It isn't obvious to me where I need to look to fix the problem. I've narrowed this down to any of the four uses of |match| I now have in my code. I don't understand yet why it is giving me this error message, but debugging one pattern in four functions feels less burdensome that looking for a misplaced token somewhere in the library. I've attached a testing egg that demonstrates what is going on. I can't quite tell what I'm doing wrong: the code works in csi, but when I run chicken-install I get an error message. Am I using match incorrectly? With the help of C-Keen on IRC, we've narrowed down this problem to an interaction between -scrutinize and the match macro. I've filed a ticket: https://bugs.call-cc.org/ticket/484 I just pulled down and updated experimental, so this problem wasn't fixed by the recent changes to the scrutinizer. That was fast as a very fast thing. This works after you fix, Felix. Thank you! -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] obscure error message after refactoring
On Thu, Jan 20, 2011 at 09:09:25AM -0500, Felix wrote: From: Alan Post alanp...@sunflowerriver.org Subject: [Chicken-users] obscure error message after refactoring Date: Thu, 20 Jan 2011 06:58:27 -0700 I don't have an explicit call to caddr anywhere in my code, and I believe the following line: syntax (##core#set! genturfahi-version trunk) Refers to the last line in the last file of my library. I've been looking over diffs trying to see if I've introduced a subtle scope or syntax error somewhere, but I'm not having much luck. What do I do with an error message like the one above? It isn't obvious to me where I need to look to fix the problem. This is an expansion error in a macro, or it's an internal compiler error. The code runs correctly when interpreted? The code runs differently when interpreted! It isn't currently matching any of my .peg files, but it does run to completion. I keep in my tests/ directory both .peg and .scm versions of my parsers. Normally, I use the .scm versions of my parsers to pinpoint precise problems in the code, as a failure to compile a .peg file is really just there's a problem somewhere. I haven't tried yet running my tests from the interpreter to see exactly what is not working like I expect. I did, for this change, include the matchable egg. I took some extra time checking to make sure I was using it correctly, though the error could still be in how I'm using that API. I believe it is the only difference in macro-using code I've changed. It's a fair hint anyway. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] obscure error message after refactoring
On Thu, Jan 20, 2011 at 03:08:53PM +0100, Christian Kellermann wrote: * Alan Post alanp...@sunflowerriver.org [110120 14:59]: I've been looking over diffs trying to see if I've introduced a subtle scope or syntax error somewhere, but I'm not having much luck. What do I do with an error message like the one above? It isn't obvious to me where I need to look to fix the problem. First of all try to increase the call-chain size with -:aN where N is the number of entries. Then it also might be that the error occurs after your stuff has been expanded by syntax. So have a look at the continuation of all this code. It may give some hints. I hope you can identify the culprit soon. increasing the call chain size doesn't affect the output, it seems. Can you explain what you mean by look at the continuation of all this code? I don't understand yet. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: obscure error message after refactoring
On Thu, Jan 20, 2011 at 06:58:27AM -0700, Alan Post wrote: I've been refactoring the interface between 3 of the subsystems in my egg, genturfa'i. I've made a ton of changes to the code, and am at the point where I'm ready to compile everything and figure out what is broken. I run chicken-install -s, and as it tries to compile my library, gives me the following error: Error: (caddr) bad argument type: * Call history: syntax (##core#begin (define genturfahi-version-major 0) (define genturfahi-version-minor 0) (define gentur.. syntax (define genturfahi-version-major 0) syntax (##core#set! genturfahi-version-major 0) syntax (define genturfahi-version-minor 0) syntax (##core#set! genturfahi-version-minor 0) syntax (define genturfahi-version-patch 1) syntax (##core#set! genturfahi-version-patch 1) syntax (define genturfahi-version trunk) syntax (##core#set! genturfahi-version trunk) syntax (##core#undefined)-- Error: shell command terminated with non-zero exit status 17920: /opt/chicken-master/bin/chicken chicken-ext.scm -output-file genturfahi.c -dynamic -feature chicken-compile-shared -feature compiling-extension -setup-mode -debug-level 2 -emit-import-library genturfahi I don't have an explicit call to caddr anywhere in my code, and I believe the following line: syntax (##core#set! genturfahi-version trunk) Refers to the last line in the last file of my library. I've been looking over diffs trying to see if I've introduced a subtle scope or syntax error somewhere, but I'm not having much luck. What do I do with an error message like the one above? It isn't obvious to me where I need to look to fix the problem. I've narrowed this down to any of the four uses of |match| I now have in my code. I don't understand yet why it is giving me this error message, but debugging one pattern in four functions feels less burdensome that looking for a misplaced token somewhere in the library. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: obscure error message after refactoring
On Thu, Jan 20, 2011 at 12:20:29PM -0700, Alan Post wrote: On Thu, Jan 20, 2011 at 08:46:16AM -0700, Alan Post wrote: On Thu, Jan 20, 2011 at 06:58:27AM -0700, Alan Post wrote: I've been refactoring the interface between 3 of the subsystems in my egg, genturfa'i. I've made a ton of changes to the code, and am at the point where I'm ready to compile everything and figure out what is broken. I run chicken-install -s, and as it tries to compile my library, gives me the following error: Error: (caddr) bad argument type: * Call history: syntax (##core#begin (define genturfahi-version-major 0) (define genturfahi-version-minor 0) (define gentur.. syntax (define genturfahi-version-major 0) syntax (##core#set! genturfahi-version-major 0) syntax (define genturfahi-version-minor 0) syntax (##core#set! genturfahi-version-minor 0) syntax (define genturfahi-version-patch 1) syntax (##core#set! genturfahi-version-patch 1) syntax (define genturfahi-version trunk) syntax (##core#set! genturfahi-version trunk) syntax (##core#undefined)-- Error: shell command terminated with non-zero exit status 17920: /opt/chicken-master/bin/chicken chicken-ext.scm -output-file genturfahi.c -dynamic -feature chicken-compile-shared -feature compiling-extension -setup-mode -debug-level 2 -emit-import-library genturfahi I don't have an explicit call to caddr anywhere in my code, and I believe the following line: syntax (##core#set! genturfahi-version trunk) Refers to the last line in the last file of my library. I've been looking over diffs trying to see if I've introduced a subtle scope or syntax error somewhere, but I'm not having much luck. What do I do with an error message like the one above? It isn't obvious to me where I need to look to fix the problem. I've narrowed this down to any of the four uses of |match| I now have in my code. I don't understand yet why it is giving me this error message, but debugging one pattern in four functions feels less burdensome that looking for a misplaced token somewhere in the library. I've attached a testing egg that demonstrates what is going on. I can't quite tell what I'm doing wrong: the code works in csi, but when I run chicken-install I get an error message. Am I using match incorrectly? With the help of C-Keen on IRC, we've narrowed down this problem to an interaction between -scrutinize and the match macro. I've filed a ticket: https://bugs.call-cc.org/ticket/484 I just pulled down and updated experimental, so this problem wasn't fixed by the recent changes to the scrutinizer. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: utf8 open tickets
On Sun, Jan 16, 2011 at 06:41:34PM +0900, Alex Shinn wrote: Hi, sorry for the delay. On Sat, Jan 15, 2011 at 12:30 AM, .alyn.post. alyn.p...@lodockikumazvati.org wrote: I have two open tickets against the utf8 egg: https://bugs.call-cc.org/ticket/423 I haven't decided how to handle this yet, but it will probably result in splitting all of the utf8 modules into separate eggs. I saw the comment against this ticket, and you make a valid point. I consider this a low priority ticket, so I'm happy to wait for the slower, more correct solution. https://bugs.call-cc.org/ticket/480 Fixed and committed. Excellent! Thank you. The experimental branch is looking really good. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: sqlite3 egg still failing in experimental branch
On Sat, Jan 15, 2011 at 03:51:45PM +0100, Thomas Chust wrote: 2011/1/15 Alan Post alanp...@sunflowerriver.org: 2011/1/14 .alyn.post. alyn.p...@lodockikumazvati.org: [...] The sqlite3 is still failing to compile in the experimental branch: [...] [...] I believe the attached patch should do it. I withdraw the original miliseconds deprecation patch (but retain the noop/void patch) and replace it with this one. [...] Hello Alan, although there was no patch attached to the message, I have now checked in modifications to the trunk version of the SQLite3 egg that should largely be equivalent to your suggested changes. I even said: ok self, make sure you attach the patch to the e-mail. I notice that you removed code adding |current-milliseconds| (presumably now |current-seconds|) to the timeout. This was intentional? I also notice that several division and multiplication operations in thread-sleep! weren't modified for fixnum--I though they could be; you understand the code better than I do. All tests still run fine under CHICKEN 4.6.3, but I still haven't tested with the experimental branch of CHICKEN. I would be grateful if you could try it under CHICKEN 4.6.4 and tell me if everything is in order, then I would tag a new version of the SQLite3 egg. There is one test failure I'm seeing: -- testing statement management -- basic lifecycle .. [ERROR] Error: (finalize!) unable to close due to unfinalised statements: #sqlite3:data base (with-database (db :memory:) (let-values (((stmt tail) (prepare db SELECT 42; -- tail))) (dynamic-wind noop (lambda () (let* ((s0 (step! stmt)) (s1 (step! stmt))) (list tail s0 s1))) (lambda () (and-let* ((s stmt)) (set! stmt #f) (finalize! s)) I don't properly recall whether this was working earlier or not. It doesn't appear to be working currently, however. For my use of the sqlite3 egg, I don't believe I'm seeing a problem related to this test failure, it at least isn't a show stopper for me. I hope my sluggish reaction didn't cause you too much trouble :-) I am very excited that Christian set up a salmonella report for the experimental branch, it raised my own urgency on getting the sqlite3 egg working. Thank you so much for taking the time to make these fixes--it came just as I made some changes that cause my own test cases to fail, so I'm now causing myself too much trouble. ;-) -Alan PS: Thank you! Thank you! -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken Gazette issue #17
On Fri, Jan 14, 2011 at 10:56:26AM +0100, Christian Kellermann wrote: The change request for special handling of procedures in `equal?`/`equal=?` has been implemented. And it works for me! I can share ~30% of the subproductions I generate in jbogenturfahi now, which is a small savings in memory but a large one in instruction caching. Since these productions are referenced everywhere, they get used a lot, and I'm really happy I'm using the same code to run them whereever they appear. The names of toplevel-entry points for library units can now contain arbitrary characters. Since the naming conversion is not backwards compatible, bootstrapping may be a bit tricky. This means if you get errors mentioning /C_foo_2d1_toplevel/ build your chicken, make spotless and rebuild it again with the binary you got from the first step. When I first encountered this problem, I tried using git bisect. It was the first time I'd used git bisect. I had no luck doing so, because each time I performed the bisect I failed to compile chicken with itself. It was fun to learn how to do that, I'm sorry this change kept me from running the experimental branch for so long. Now I know what to do, at least. :-) Some useless warnings have been removed. I'm also really happy with this one. It makes my build output much cleaner, so I can spot legitimate warnings. It's good to see another Gazette! -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] embedding question / seg fault
On Fri, Jan 14, 2011 at 11:53:09PM +0100, Felix wrote: From: David Dreisigmeyer dwdreisigme...@gmail.com FYI, I'm trying to call Chicken commands from Python using Cython. Interesting idea. Keep us informed about your progress, please. +1. This is something I'd be able to use myself. I would like to work with another developer who writes in python. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: sqlite3 egg still failing in experimental branch
On Fri, Jan 14, 2011 at 05:21:06PM +0100, Thomas Chust wrote: 2011/1/14 .alyn.post. alyn.p...@lodockikumazvati.org: [...] The sqlite3 is still failing to compile in the experimental branch: [...] Will you apply the patches I sent you to the sqlite3 egg? [...] Hello, yes, I know. I will apply the patch eventually but I have to / want to disable the fixnum arithmetic declaration at the same time and insert calls to fixnum specific procedures where appropriate. Now, if I make these modifications I want to do it carefully, especially changing all the arithmetic calls. But I simply haven't gotten around to installing the experimental CHICKEN branch (usually I only update to snapshot releases and I very much dislike git ...) and to updating the SQLite3 egg. [...] I was able to modify genturfa'i to use those procedures rather than declaring fixnum. Would you like a new patch that uses this same approach in sqlite3? Disabling the fixnum declare but replacing you maths operations with fixnum versions? [...] If you took the time to do that, I would be glad to accept an improved patch :-) I believe the attached patch should do it. I withdraw the original miliseconds deprecation patch (but retain the noop/void patch) and replace it with this one. All arithmetic operations are fixnum except the delay call, which is done with floating point arithmetic. [...] What do you need to get the sqlite3 egg updated to compile against the experimental branch? [...] Hmm, maybe a reduction of Earth rotation speed to prolonge my spare time hours would be good? Or maybe some genetic modification to reduce the necessary amount of sleep? I'd like to pose a question to the list about this issue, because it results from the way development is done in Chicken Scheme and perhaps someone has insight into the issue. I'm suffering from priority inversion on this issue: jbogenturfa'i requires the experimental branch to run[1][2], while one of it's dependencies, sqlite3, won't run on the experimental branch.[3] The fix to sqlite3 is easy, and I've provided patches. There isn't any reason Thomas' priorities should be mine, however, and in this case they aren't. My options seem to be to convince Thomas that he should be running at a higher priorty or ask Mario for a sqlite3-experimental egg in the repository and fork sqlite3. I don't consider a fork a good idea, but if I had to fix this issue today, I can't think of a better one either. It is easier to accomplish that either of Thomas' above requests. :-) How has this situation been handled in the past? Can someone sugest a solution that doesn't require Thomas to raise his scheduling priority but allows me to have a sqlite3 that compiles in experimental? I'm fortunate to be in a position where this issue isn't urgent--I'm the only one running jbogenturfa'i and I can keep my patches in my local repository. I may not always be in such a fortunate position. Thoughts? -Alan 1: http://tests.call-cc.org/2011/01/14/salmonella-report/tests/jbogenturfahi.html 2: https://bugs.call-cc.org/ticket/441 4: http://pestilenz.org/~ckeen/salmonella-report/2011-01-14/sqlite3.html Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Salmonella report for experimental chicken 4.6.4 available
It looks like Thomas hasn't applied the patches I posted to him and this list regarding sqlite3. That causes jbogenturfa'i to fail to build. :-( genturfa'i compiles and runs all of it's tests. Hooray! -Alan On Thu, Jan 13, 2011 at 06:52:44PM +0100, Christian Kellermann wrote: Dear Chicken fans, I did a salmonella run of on a chicken 4.6.4 from experimental git of today. The results are available at http://pestilenz.org/~ckeen/salmonella-report/index.html A lot of symbols which have been marked deprecated have been removed over the last weeks. This salmonella run also shows eggs which still rely on the old deprecated symbols. It is a chance to check again before the experimental branch is merged into master. So I would like to invite you to check if your own eggs or eggs you rely on still work. Please also note that this has been run on a machine which misses most of the required libraries so there are false positives. Please check the build logs for details. If this service is useful to you I will try to keep it up as a cron job with as much external lib support as I can install on this machine. Thanks for your contributions! Christian ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
