Re: [Chicken-hackers] [PATCH 1/2] write: escape DEL character in strings
Hi guys, Peter Bex writes: > On Tue, Mar 05, 2013 at 06:48:44PM +0100, Florian Zumbiehl wrote: > Thanks for this (and the other) patch! Here's a signed-off version, > which other team members may push. I also nominate this patch for > inclusion in the stability branch. thanks a lot, signed off and pushed! Moritz ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] inliner bug
Hi, The chicken inliner runs for a long time before failing with exit code 11 on the following code: (declare (inline test)) (define (go a) (a 1)) (define (test x) (go (lambda (x) (x) (test x Compile with: csc -inline a.scm -emit-inline-file a.inline This is a simplified version of a bug that occurs in the AD egg. Andrei ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] strange error message, please help with interpretation
On Sat, Mar 09, 2013 at 01:33:50PM +0100, Christian Kellermann wrote: > * Jörg F. Wittenberger [130309 12:26]: > > I'm afraid I have no idea how I could boil this down to a reproducible > > case. > > > > I've seen it once so far in a logfile of a process, which xreates > > approximately 200 threads a day when communicating over WAN > > with about ten peers plus all those public web access (approx. > > since chicken does not have unique thread numbers, but rscheme > > does; when I run the rscheme version instead I see thos 2^6 threads; > > though the chicken version has a different runtime behavior and does > > not share 100% of the code, hence it could use a different amount of > > threads.) > > I am confused. I thought you were wondering about a compilation > message you get during the flow analysis of the scrutinizer. As I understood it, it's an exception's message upon an error at runtime. I think this may be an off-by-one error somewhere resulting in data corruption. I've seen similar mystifying error messages when the stack wasn't quite right; alomst everything is fine except it tells you something is wrong. You're right; if this can't be easily reproduced, we're unlikely to find a root cause. A core dump and access to the machine might help, but I'm unsure it crashes this hard. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] inliner bug
From: Andrei Barbu Subject: [Chicken-hackers] inliner bug Date: Sun, 10 Mar 2013 15:09:34 -0400 > Hi, Hello! > > The chicken inliner runs for a long time before failing with exit code > 11 on the following code: > > (declare (inline test)) > > (define (go a) (a 1)) > (define (test x) (go (lambda (x) (x) (test x > > Compile with: > > csc -inline a.scm -emit-inline-file a.inline > Normally procedures are inlined if their size is below a certain limit (a count of "nodes" in the internal representation of the compiler), which defaults to 20, I believe. By adding the "inline" declaration, you are effectively disabling this size test, telling the compiler: "Inline this! Always! Now go and do what I command!" What we can do about this is one of the following: - keep the current behaviour, since it is what the user wants (depending on the point of view, of course) - disable the declaration after the current optimization pass, once a procedure has been inlined at all call-sites in the program (this may miss some call-sites in nested calls, but is better than what happens now, with the compiler running out of memory and all that...) - define a "cut off" point, a maximal size that a procedure may have after which inlining will be prohibited (this is difficult to determine correctly and depends on too many factors, but is easy to implement) cheers, felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] inliner bug
Felix scripsit: > By adding the "inline" declaration, you are effectively disabling > this size test, telling the compiler: "Inline this! Always! Now > go and do what I command!" That's ... just wrong. An inline declaration should be a SHOULD, not a MUST. In particular, the compiler should at a minimum detect that it is recursively inlining and stop. A notinline declaration, on the other hand, must be a MUST. This is what Common Lisp says: the compiler can always ignore an inline declaration, but a notinline declaration is the only one (apart from a special-variable declaration, which affects semantics) that MUST NOT be ignored. > - disable the declaration after the current optimization pass, once > a procedure has been inlined at all call-sites in the program (this > may miss some call-sites in nested calls, but is better than what > happens now, with the compiler running out of memory and all that...) That sounds reasonable. -- Almost all theorems are true, John Cowan but almost all proofs have bugs.http://www.ccil.org/~cowan --Paul Pedersen ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
