Hi all,
this goes to both chicken-users and chicken-hackers.
I feel it's more appropriate to chicken-hackers,
but recently I bothered the users with help requests on the
issue - maybe it's useful to learn where this ends up.
The problem I ran into:
Much depending on optimisation being done or
.)
On Oct 20 2011, Jörg F. Wittenberger wrote:
Towards the end of the log there is almost only C_mutate
growing it's mutation stack more and more.
I wonder if something like this has ever been observed before.
Is there any know pitfall how one could create such a condition?
So far I've been
On Oct 21 2011, Jörg F. Wittenberger wrote:
For the C_mutate, whoever has any wild guess how this
behaviour could come up, please help me with that one.
I wonder: C_mutate is (in runtime.c) sometimes used like this
if(C_in_stackp(x)) C_mutate(y,x); else y=x;
and sometimes the C_in_stackp
On Oct 21 2011, Felix wrote:
For the C_mutate, whoever has any wild guess how this
behaviour could come up, please help me with that one.
Do you use C_mutate in C code?
Nowhere.
The mutation stack will
grow until a garbage collection takes place, so if you
invoke C_mutate in a C loop
On Oct 21 2011, Jörg F. Wittenberger wrote:
The mutation stack will
grow until a garbage collection takes place, so if you
invoke C_mutate in a C loop without giving GC a chance,
the mutations will just add up.
Reading C_reclaim still without fully understanding how
exactly is will interact
.
Reasonable?
/Jörg
On Oct 21 2011, Jörg F. Wittenberger wrote:
The mutation stack will
grow until a garbage collection takes place, so if you
invoke C_mutate in a C loop without giving GC a chance,
the mutations will just add up.
Reading C_reclaim still without fully understanding how
exactly
On Oct 22 2011, Felix wrote:
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
Now I wonder: as far as I understand C_mutate it will remember
all assignments where the assigned value in within the nursery.
It will remember all assignments, later GC will make the (important
On Oct 24 2011, Felix wrote:
Running on that code it looks as if the optimization is not
that small.
So is performance the point of this patch? Because it is not
completely clear what this patch addresses. The mutation stack
only overflows if you avoid GC (which can be easily traced),
are you
On Oct 24 2011, Felix wrote:
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
Subject: Re: [Chicken-hackers] Need help to understand C_mutate better.
Date: 21 Oct 2011 15:58:17 +0200
On Oct 21 2011, Jörg F. Wittenberger wrote:
The mutation stack will
grow until a garbage
On Oct 25 2011, Felix wrote:
Couldn't either the signal handler return to gc, or - my preferred
alternative - the minor gc run prior to the signal handler?
Would make chicken robust to the case at hand.
This sounds possible, but it will trigger a collection even in cases
where it is not
I just updated to current master.
First notice: with the modified allocation scheme for the m-stack
I observe a larger memory footprint.
The attached diff does roughly half the time the chicken executable
needs compiling it's own source.
IMHO it would be an interesting idea to convert C_mutate
On Oct 27 2011, Felix wrote:
This patch adds some cleanups and enhancements to the interrupt and
signal-handling facilities, as posted recently.
I found the patch would rename never_mind_edsgar into i_like_spaghetti.
Thus the reference in this message would need a change now.
On Oct 27 2011, Felix wrote:
I found the patch would rename never_mind_edsgar into
i_like_spaghetti.
Yeah, it's a great idea, isn't it? I'm particularly proud
of this one.
Sure it is! My Congratulations.
BTW: recently I started to wonder: it's a nice feature that chicken
comes with only
I'm surprised:
yesterday I posted this trivial diff
http://lists.nongnu.org/archive/html/chicken-hackers/2011-10/msg00119.html
after I found that this would double the speed of the chicken compiler.
(the chicken compiler run itself, not the whole build process
with gcc et al (since not
Hi all,
I never thought about that one, but it could be a real issue.
Julian Wälde and Alexander Klink reporting:
http://www.nruns.com/_downloads/advisory28122011.pdf
I have not figured whether or not chicken would be vulnerable.
Anybody able to do so?
Best regards
/Jörg
On Dec 31 2011, John Cowan wrote:
Thomas Bushnell, BSG scripsit:
Huh? The point is that well-chosen hash collisions can force the
algorithm into its worst case behavior, and if that's linear, it's a
problem. Choosing a linear algorithm to begin with is hardly a win!
Let me second that one.
On Jan 2 2012, Ivan Raikov wrote:
I also do not understand why using different data structures is not
under consideration.
This might be a matter of taste wrt. maintaining software.
I prefer to choose data structures for their merits.
When it turns out that the _implementation_ is (kind
On Jan 7 2012, Peter Bex wrote:
The thought just popped into my head that my hash table patch breaks
SRFI-69 compatibility. When the user passes a custom hash procedure,
That would be bad bad. In the end.
For fixing the extra argument problem, here are some options I
considered:
1) Pass
On Jan 30 2012, Peter Bex wrote:
On Mon, Jan 30, 2012 at 11:49:15AM +0100, Jörg F. Wittenberger wrote:
I'm asking this because I'm trying for several weeks to track
down a certain segfault. As it happens I can observe that
one only on ARM, never on AMD64. It occurs randomly and rare
enough
On Jan 30 2012, Felix wrote:
If they're not tracked, could this cause the scrutinizer to make
invalid type inferences and code replacements?
May I expand: Felix, assuming you have at least seen the results
of some mistaken type tag, what would be the resulting effect
to the running chicken
I'm afraid I ran into a pathological case for irregex.
For me this hangs in a tight loop:
$ csi
CHICKEN
(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 2012-01-12 on ajax (Linux)
#;1 (use
On Feb 13 2012, Peter Bex wrote:
On Mon, Feb 13, 2012 at 03:11:05PM -0700, Alan Post wrote:
I do think that choice is fine, yes. Does the hash table resize
itself when it gets too many entries in it?
No, unfortunately these hash tables are pretty basic and too low-level
to do such things.
On Feb 14 2012, Moritz Heidkamp wrote:
Hello Chickeneers,
find attached a suggested addition to miscmacros: the thrush operator
family. Apparently it stems from Raymond Smullyan's book on
combinatorial logic To Mock a Mockingbird, which I haven't read
(yet). I've first learned about it through
On Feb 15 2012, Moritz Heidkamp wrote:
Hi Jörg,
Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:
I rather loved to think instead of inserting the (*single*)
value of the expression into the next expression of something
along the lines of physical wires:
connect (pass) all
Hi Chickeners,
to those of you who will be at CeBit the next days:
join us at our both at the security plaza hall 12!
We'll show you a pure chicken network! ( askemos.org )
Look out for the logo from softeyes.net .
Looking forward to see you there!
/Jörg
On Mar 12 2012, John Cowan wrote:
Felix scripsit:
I used pure only half-heartedly. Strictly speaking a pure function
should not even throw an error, the pure meaning: this procedure will
not have any effect whatsoever, regardless of arguments (so it can be
removed if the result is unused).
#723: looks weird, but looking into that will need time
Hm. I'm sitting on 4.7.5 and can not confirm the crash
an 64bit linux compiled with -O3.
Note however, that I'm running from some runtime modifications
as I posted about here:
On Apr 16 2012, Christian Kellermann wrote:
* Jörg F. Wittenberger joerg.wittenber...@softeyes.net [120416 16:51]:
#723: looks weird, but looking into that will need time
Hm. I'm sitting on 4.7.5 and can not confirm the crash
an 64bit linux compiled with -O3.
Does it work with -O2 also
On May 14 2012, Moritz Heidkamp wrote:
Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:
Anybody interested to pull this into the official chicken core?
That's definitely interesting. I wonder if it would be possible to
provide hooks in the core so that the scheduler can
To summarize: at least the select interface should be kept
around. Either as cond-expand compile time choice or
via modules to load.
Also I wonder how broadly applicable the claims of performance
gains actually are and how much is just folklore. Assuming
that often enough the implementation of
timeout: (respond-timeout-interval)
))
On May 14 2012, John Cowan wrote:
Jörg F. Wittenberger scripsit:
[1]: I'm using e.g. !apply, !map and !mapfold where
!apply would create and immediately join (possibly with
timeout) a thread to apply the function to it's arguments.
!map does what
this should help:
===
--- tcp.scm
+++ tcp.scm
@@ -612,10 +612,11 @@
##sys#current-thread
(+ (current-milliseconds) tmc) ) )
(##sys#thread-block-for-i/o!
Please could somebody enlighten me, what those forwarded
objects are? A short note on purpose and encoding should
be enough.
The real question would be: how can it happen, that I
can create an invalid forwarded object - or for that matter -
how would I avoid it?
A different though related
Thanks Felix,
On May 28 2012, Felix wrote:
Should I doubt the trace?
Was this code compiled with C optimization options? If yes, any
assumption about the correctness of the trace is moot.
It was compiled with -O3 .
Case closed.
(Actually I'm not a big user of debuggers: does this no
On Jun 19 2012, Felix wrote:
The attached patch adds exception handling around the invocation of
finalizers, which are shown as warnings (unless warnings are disabled)
but do not otherwise trigger errors (similar to the way errors in
separate threads are handled). I still experienced random
On Jun 19 2012, Peter Bex wrote:
What I don't quite understand is all this talk about threads. The test
program doesn't even create any extra threads, so how could there be any
race conditions? There shouldn't *be* any concurrency in this case,
should there?
Isn't this more of a
On Jun 19 2012, Felix wrote:
each object. The latter takes up more memory when you don't have a lot
of finalizers (and finalizers are slow, so it's best not to generate too
many of them).
Exactly. Finalizers are junk. Finalizers are the last resort. Creating
excessively many of them is a
On Jun 19 2012, Peter Bex wrote:
Right now it looks to me like there's an optimization that's messing
things up. Try compiling this file with -O0 and then with -O1:
(let lp ((x (list 1 2 3)))
(set-finalizer! x (lambda _ #f))
(lp (list 1 2 3)))
With -O1 or higher this will raise a
On Oct 15 2012, Felix wrote:
Hi!
Since these two CRs don't seem to be overly controversial,
we can probably vote on it right now:
http://bugs.call-cc.org/ticket/931
Dislike (requires me to double check that I stick to standard;
while I really like it when I see additional dependencies
On Oct 28 2012, Felix wrote:
From: Felix fe...@call-with-current-continuation.org Subject: [PATCH]
process-fork: option to kill all but the current thread in the child
process Date: Sun, 28 Oct 2012 09:10:41 -0400 (EDT)
This patch allows process-fork to kill all existing threads but the
Sorry, fat fingers at the phone.
Wanted to mail the next line in my addressbook.
On Dec 28 2012, Jörg F. Wittenberger wrote:
I'd love to get this done by sunday.
There*s been a job offer at the mailing list of the chicken compiler.
I intent to apply. By Monday.
Sending only the reference
# Askemos – What is it?
I keep receiving positive comments to Askemos/BALL-related code posted
to Chicken lists. (Some examples below.) However people seem almost
scared to use it for their own good.
This code base became what I'd call a swiss-army knife to **simplify**
tasks like backup,
On Feb 21 2013, Jörg F. Wittenberger wrote:
Somehow I can't verify that my type declarations are actually
effective.
I've been able to verify that my .types files are not ever consulted.
Using strace I found that the foo.types file is searched for in
stat(/usr/lib/chicken/6/foo.types
it appears that the mutex-lock! declaration in types.db is not
currect.
The second optional argument according to my reading of may be
either a thread (struct) or #f ; however types.db only expects
a thread.
best
/Jörg
...
___
Hi all,
maybe that's not a wishlist entry, but just me missing somthing?
When adding type declarations to some source, which has grown
for over a decade, I ran into this situation:
There's are widespread use cases of some types, which are actually
implemented as vectors, pairs or lists with a
At 21 Oct 2011 I proposed some changes, which apparently have made it
half-way into the chicken core so far. See
http://lists.nongnu.org/archive/html/chicken-hackers/2011-10/msg00084.html
At 19 Jun 2012 in
http://lists.nongnu.org/archive/html/chicken-hackers/2012-06/msg00051.html
I mentioned
how it came in.
Thanks anyway.
/Jörg
On Mar 4 2013, Mario Domenech Goulart wrote:
Hi Jörg,
On 04 Mar 2013 13:55:01 +0100 Jörg F. Wittenberger
joerg.wittenber...@softeyes.net wrote:
At 21 Oct 2011 I proposed some changes, which apparently have made it
half-way into the chicken core so far
On Mar 4 2013, Peter Bex wrote:
On Mon, Mar 04, 2013 at 03:32:52PM +0100, Moritz Heidkamp wrote:
Hi Jörg,
Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:
I found that ##sys#double-number is gone from library.scm .
Still it's there in chicken.h . Mistake or intended?
At least
On Mar 4 2013, Christian Kellermann wrote:
* Jörg F. Wittenberger joerg.wittenber...@softeyes.net [130304 14:57]:
I found that ##sys#double-number is gone from library.scm .
Still it's there in chicken.h . Mistake or intended?
Are you mixing up files? Or using a chicken.h from a previous
Thanks a lot, this one seems to do the job.
On Mar 4 2013, Christian Kellermann wrote:
* Jörg F. Wittenberger joerg.wittenber...@softeyes.net [130304 14:57]:
I found that ##sys#double-number is gone from library.scm .
Still it's there in chicken.h . Mistake or intended?
At least I'd
it.)
On Mar 4 2013, Jörg F. Wittenberger wrote:
Thanks Mario for your remark.
However, the bug will not effect me.
Let's say I don't remember whom I eventually sent my initial
implementation as offered here
http://lists.nongnu.org/archive/html/chicken-hackers/2012-05/msg8.html
The code I'm
Solved again. Please tell me what to do with the fix.
On Mar 4 2013, Jörg F. Wittenberger wrote:
At 21 Oct 2011 I proposed some changes, which apparently have made it
half-way into the chicken core so far. See
http://lists.nongnu.org/archive/html/chicken-hackers/2011-10/msg00084.html
At 19
.)
-Dan
On 3/5/2013 11:46 AM, Jörg F. Wittenberger wrote:
so far I replaced two out of five hosts running the chicken
version of askemos/ball with the one compiled using chicken
4.8.2. (No changes to the prog itself.) According to the
statistics so far, performance is about half of 4.7.5
In my prog I have a structure
(define-record-type uri
...
(path uri-path)
...)
--: Which happened to work for years so far. Unchanged :--
Now, after upgrading from 4.7.5 to 4.8.2 I found this in the log:
bad argument type - not a structure of the required type
(bad argument type - not a
On Mar 7 2013, Peter Bex wrote:
On Thu, Mar 07, 2013 at 12:44:28PM +0100, Jörg F. Wittenberger wrote:
So how would I interpret this message. As far as I can see, this
tells me that somehow a typecheck failed on a (struct uri)
testing it to be a (struct uri) -- which would have been supposed
Kellermann wrote:
* Jörg F. Wittenberger joerg.wittenber...@softeyes.net [130308 23:00]:
(define (make-uri scheme authority path query fragment)
(%make-uri (if (string? scheme) (string-symbol scheme) scheme)
authority path query fragment))
Also: the code is pulled into the module via
just fine.
But that's not of any help to testing the new chicken, is it?
/Jörg
On Mar 10 2013, Peter Bex wrote:
On Sat, Mar 09, 2013 at 01:33:50PM +0100, Christian Kellermann wrote:
* Jörg F. Wittenberger joerg.wittenber...@softeyes.net [130309 12:26]:
I'm afraid I have no idea how I could boil
On Mar 17 2013, Florian Zumbiehl wrote:
Somehow, this feels to me like you are applying test driven development
techniques to concurrency correctness. Are you sure that your reasoning is
correct and reliable and future-proof? Are the assumptions you make about
the compiler true now for sure and
On Mar 18 2013, Felix wrote:
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] [PATCH 3/4] Remove ##sys#expand-home-path.
Date: Mon, 18 Mar 2013 21:22:12 +0100
On Mon, Mar 18, 2013 at 02:03:41PM -0400, Mario Domenech Goulart wrote:
Maybe I'm too paranoid? Or missing
Hi all,
I'm not yet convinced that this patch will fix everything screwed
up by use of the tcp implementation.
The past days I wrote a replacement for my use. (A bit incomplete
wrt. API compatibility to the tcp unit and thrown into a module
I'm using to drive the SSL/TLS implementation I'm
Let's explain the idea by example.
There are many standard (or srfi) procedures, which take either
a distinguished type or (often) a boolean value (typically #f).
For instance mutex-lock: the 1st optional argument is either
a timeout or #f the second is either a thread or #f.
Written as type
On Mar 24 2013, John Cowan wrote:
Jörg F. Wittenberger scripsit:
Note: in local procedure `doloop9',
in toplevel procedure `foo#bar':
(strcttps.scm:10) in procedure call to `null?', the predicate is
called with an argument of type
`null' and will always return true
That strikes me
On Mar 25 2013, Moritz Heidkamp wrote:
Jörg F. Wittenberger joerg.wittenber...@softeyes.net writes:
Though in a way the explanation is correct. -strict-types assumes
'() to be null from the initialization. Short of a way to declare
the type of foobar as (list-of whatever) this fails when
On Mar 30 2013, Felix wrote:
Though in a way the explanation is correct. -strict-types assumes
'() to be null from the initialization. Short of a way to declare
the type of foobar as (list-of whatever) this fails when it's used
as the initial and correct value of type (list-of whatever) with
On Mar 31 2013, Felix wrote:
From: Peter Bex peter@xs4all.nl
Subject: Re: [Chicken-hackers] testcase -strict-types
Date: Sat, 30 Mar 2013 23:44:01 +0100
On Sat, Mar 30, 2013 at 11:33:37PM +0100, Felix wrote:
that refinement generalizes the type of a variable to cover all uses
of it, and
I'm trying to figure out howto use -block optimization.
Whenever I use it with any module no matter how simple it is,
the resulting binary will segfault immediately.
Which restrictions should I watch?
Thanks a lot
/Jörg
___
On Apr 4 2013, John Cowan wrote:
We can ignore environment immutability in practice.
OTOH I'd *love* to have it; e.g., for sandboxing.
..
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
On Apr 5 2013, Felix wrote:
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
Subject: [Chicken-hackers] how to -block?
Date: 31 Mar 2013 20:51:19 +0200
I'm trying to figure out howto use -block optimization.
Whenever I use it with any module no matter how simple
Hi,
I just noticed, that I can't mix -block with -strict-types.
That is, when I -emit-type-file, the resulting file contains
the type definitions ONLY if -block is NOT given. With -block
it's empty (except for comments),
Thus I can either get warnings for call sites violating the
required
Sorry, I'd had sent this to chicken-users - but I'm kinda sure those
who could answer don't read that list ;-)
find attache two trivial module files foo.scm and bar.scm
to be compiled with csc -c foo.scm bar.scm .
Both declare (block) optimization.
Plus several foobarX.scm for X in 1-6
On Apr 11 2013, Felix wrote:
From: Jörg F. Wittenberger joerg.wittenber...@softeyes.net
Subject: [Chicken-hackers] -block not properly mixing with -strict-types
Date: 10 Apr 2013 19:40:32 +0200
Hi,
I just noticed, that I can't mix -block with -strict-types.
That is, when I -emit-type-file
On Apr 28 2013, Felix wrote:
From: Thomas Hintz t...@thintz.com
Subject: [Chicken-hackers] Issue installing sxpath
Date: Sun, 28 Apr 2013 09:57:55 -0700
...
reading chunks ...[panic] out of memory - heap full while resizing -
execution terminated
This looks like a corrupt heap. The egg is
r7rs section 4.2.6 (Dynamic bindings) mentions threads and the intro
to section 4 documents a connection between ``parameter``s and ``delay``.
Section 4.2.5 (Delayed evaluation) does not mention threads…
Thus I'm not sure if the case described here would be better clarified
in r7rs or fixed
Peter Bex has pointed out that my example in
http://lists.nongnu.org/archive/html/chicken-hackers/2013-05/msg00031.html
was not very clear about the problem at hand; let my clarify.
I wanted to show that we can proof the body of `(delay expr)` being
evaluated any random number of times.
On May 13 2013, Jörg F. Wittenberger wrote:
Peter Bex has pointed out that my example in
http://lists.nongnu.org/archive/html/chicken-hackers/2013-05/msg00031.html
was not very clear about the problem at hand; let my clarify.
...
NB: Things would be even stranger, if we would cause
On May 13 2013, Peter Bex wrote:
On Mon, May 13, 2013 at 10:44:53AM +0200, Felix wrote:
Hello!
Hi!
I know this is going to be controversial, but I'd like to un-deprecate
the use of plain procedures as syntax-transformers. The way it is
currently implemented, using a procedure can be seen
On May 13 2013, John Cowan wrote:
Felix scripsit:
So wwhat would be the right default, if I may ask?
When there is no clear preferred alternative, the right default is no
default: prefer explicit over implicit in this case.
May I 2nd that.
Felix, I don't want to upset you with the
On May 18 2013, Jörg F. Wittenberger wrote:
Eventually I learned that the technique I've been looking for is
known singe 2001 by the name Petrofsky Extraction.
As I'm gaining experience with the Petrofsky extraction, I wonder
how useful it might by to have a version of SRFI-8 `receive`,
which
Hi,
so far I lived in the believe that returning multiple values would be rather
slow under Chicken. This goes back to a remark from Felix, which is several
years old.
(However I personally love using multiple values mostly for clarity of the
code; but also because I know that some Scheme
On May 20 2013, Arthur Maciel wrote:
Dear Joerg, certainly I'm not the best person to delve into details about
whether this should be done or not. But recalling some requests I've made
to this list in order to change chicken's core for the sake of
'optimizations' I realized that it is better to
Citing the manual
procedure(expand X)/procedure
If {{X}} is a macro-form, expand the macro (and repeat expansion
until expression is a non-macro form). Returns the resulting expression.
Let's try:
(expand '(let ((foo 1))
(let-syntax
((foo (syntax-rules () ((_) 2
(list 'bar
Try to compile this code, csc will complain about a known
procedure called with the wrong number of arguments:
(let ((x (lambda (y) (+ y 1 (x 2 3))
Now try this equivalent code, csc will happily accept it.
(Thus converting the compile-time error into a run-time error.)
((lambda (x) (x 2
On May 24 2013, John Cowan wrote:
I've always thought that case-lambda should be built into the core,
so that simple tail recursions, like this:
(define foo (case-lambda
((bar baz) ...)
((baz) (foo #f baz
can be rewritten as a varargs function with appropriate internal jumps,
without
On Jun 18 2013, Peter Bex wrote:
On Tue, Jun 18, 2013 at 02:04:32PM +0200, Jörg F. Wittenberger wrote:
On Jun 18 2013, Jim Ursetto wrote:
On Jun 17, 2013, at 2:06 AM, Felix
fe...@call-with-current-continuation.org wrote:
This is quite a serious bug, and I recommend putting the patch
On Jun 18 2013, Peter Bex wrote:
On Tue, Jun 18, 2013 at 02:50:21PM +0200, Jörg F. Wittenberger wrote:
At least I tried not recently, certainly not since the sig*jmp stuff
came in.
OK, makes sense.
Also running my code under valgrind doesn't *really* work. It did
catch some uninitalized
On Jun 21 2013, Peter Bex wrote:
On Wed, Jun 19, 2013 at 02:32:01PM +0200, Jörg F. Wittenberger wrote:
On Jun 18 2013, Peter Bex wrote:
On Tue, Jun 18, 2013 at 02:50:21PM +0200, Jörg F. Wittenberger wrote:
Also running my code under valgrind doesn't *really* work. It did
catch some
Am 02.11.2013 06:21, schrieb John Cowan:
Jörg F. Wittenberger scripsit:
Rather uncontroversial: r7rs says the result of a delayed
expression returning multiple values is unspecified. Hence it's OK
to actually return multiple values (as I'd prefer r7rs should have
explicitely required
Am 02.11.2013 23:49, schrieb Evan Hanson:
On 2013-11-02 21:10, Jörg F. Wittenberger wrote:
deconstructing the zero-value case as a special case but handling the
one-valued case using the generic multiple value procedure C_values,
which is according to my understanding less efficient - hence
Am 04.11.2013 06:17, schrieb John Cowan:
Jörg F. Wittenberger scripsit:
Sure it's easy to convert multiple value returns into a single value
(e.g. a list) and back. Scheme _could_ be done without multiple
values at all (the way you describe). Just: multiple values are
useful as an alternative
Hi,
despite the fact that salmonella currently seems to be happy with the
situation, let me add my €0,02.
Sometimes the solution is not more code but less.
Chicken's interrupt handling was broken for quite a long time. There is
by now still a problem lurking and waiting to be triggered:
I used to compile with clang to avoid the endless list of
warning: array subscript is above array bounds [-Warray-bounds]
from gcc (4.6.1)
Now it's replaced with an endless list of
warning: function declared 'noreturn' should not return [-Winvalid-noreturn]
from clang. (Besides that I often
Am 06.11.2013 11:14, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 11:10:39AM +0100, Jörg F. Wittenberger wrote:
Also this commit is obviously applied and the code is in chicken.h
What version of clang are you using?
Looks like version 2.9.
I wrote this code testing with clang 3.3, so maybe
Am 06.11.2013 14:47, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 02:35:20PM +0100, Jörg F. Wittenberger wrote:
Appears that 3.0 does already honor the noreturn declaration.
But now it complains about the array subscriptions as gcc did before...
Can you provide a minimum set of steps which one
Am 06.11.2013 15:29, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 03:21:18PM +0100, Jörg F. Wittenberger wrote:
My solution at that time was to coalesce signals by type and handle all
reasons of a particular signal in a single signal handler (anyway) since
- as you're pointing out - this must
Am 06.11.2013 19:11, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 06:00:34PM +0100, Jörg F. Wittenberger wrote:
Now I cam confused.
True, there are 256 possible signal handlers in ##sys#signal-vector
How could those be addressed/used at all?
The timer interrupt signal has value 255. I'm sure
Am 06.11.2013 19:33, schrieb Mario Domenech Goulart:
Hi Jörg,
On Wed, 06 Nov 2013 19:20:41 +0100 Jörg F. Wittenberger
joerg.wittenber...@softeyes.net wrote:
It's somehow related to code, which uses Petrofsky extraction
(replacing some hon-hygienic macros I've been using before). This
used
Am 06.11.2013 19:35, schrieb Jörg F. Wittenberger:
Am 06.11.2013 19:33, schrieb Mario Domenech Goulart:
I'd bet it is a consequence of the introduction of `letrec*'. The
behavior of `letrec' has been fixed with the introduction of `letrec*'
(see
http://lists.nongnu.org/archive/html/chicken
Am 06.11.2013 19:35, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 07:20:41PM +0100, Jörg F. Wittenberger wrote:
Now I ran a full recompile. To the effect that some macro expansion has
been changed to the worse.
It's somehow related to code, which uses Petrofsky extraction (replacing
some hon
Am 06.11.2013 19:39, schrieb Jörg F. Wittenberger:
Am 06.11.2013 19:35, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 07:20:41PM +0100, Jörg F. Wittenberger wrote:
Now I ran a full recompile. To the effect that some macro expansion
has
been changed to the worse.
It's somehow related to code
Am 06.11.2013 20:27, schrieb Peter Bex:
On Wed, Nov 06, 2013 at 08:18:20PM +0100, Jörg F. Wittenberger wrote:
Things seem to be much worse than expected.
Without going into all the nasty details, this is roughly where the
problem is:
The parameter named 'static-variables' here turned out
1 - 100 of 286 matches
Mail list logo
