Hi.
Tue, 28 May 2013 23:25:35 +0200, Peter.Bex wrote:
For now I'd say this is a problem with your particular gcc version.
If you or someone else can reproduce this and come up with a patch
that would be great.
I know this problem for a year or so (gcc 4.7.N, gcc 4.8.N; C optimization -O2
or
From: Thomas Chust ch...@web.de
Subject: [Chicken-users] Protocol Buffers for CHICKEN
Date: Wed, 29 May 2013 00:15:20 +0200
Hello,
during the CHICKEN spring thing in Cologne I started to work on a new
egg [1] implementing the protocol buffer [2] serialization format, which
is now in a
closure serialization definitely works, I have tried round tripping
compiled and interpreted procedures with and without surrounding context
through serialize and deserialize and they are still functional after
reading them back in.
Excellent.
Continuations should work, too, but it is
On May 27 2013, Michele La Monaca wrote:
R5RS doesn't specify this kind of syntax (nor Chicken supports it):
(let* loop ((a init) (b a))
body)
To me it seems a missing piece of syntax. Am I wrong?
I've missed it occasionally as well, but I'm not sure it's *that* useful.
Of course
Hi,
during the CHICKEN spring thing in Cologne I started to work on a new
egg [1] implementing the protocol buffer [2] serialization format, which
is now in a usable and tested state.
Wow! This looks super cool!
I'm so sad to have missed the Spring Thing.
I wonder if you might entertain
If I understand the OP correctly, he wants let* to imitate this macro.
(define-syntax named-let*
(syntax-rules ()
((named-let* name ((var val) ...)
body ...)
(let* ((var val) ...)
(let name ((var var) ...)
body ...)
-Patrick
On Wed, May 29, 2013 at 5:47
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/29/2013 01:02 PM, Moritz Heidkamp wrote:
Hello!
Christian Kellermann ck...@pestilenz.org writes:
I am sad to say that the CHICKEN Spring Thing 2013 is over. I hope
everyone had a safe journey back home and enjoyed the weekend with
all the
On Wed, May 29, 2013 at 5:02 AM, Moritz Heidkamp
mor...@twoticketsplease.de wrote:
Hello!
Christian Kellermann ck...@pestilenz.org writes:
I am sad to say that the CHICKEN Spring Thing 2013 is over. I hope
everyone had a safe journey back home and enjoyed the weekend with
all the other
Chicken CA Toronto? :)
On Wed, May 29, 2013 at 12:06 PM, Dan Leslie d...@ironoxide.ca wrote:
Chicken CA Vancouver?
;)
-Dan
Thomas Hintz t...@thintz.com wrote:
On Wed, May 29, 2013 at 5:02 AM, Moritz Heidkamp
mor...@twoticketsplease.de wrote:
Hello!
Christian Kellermann
On Wed, May 29, 2013 at 9:02 AM, Thomas Hintz t...@thintz.com wrote:
CHICKEN U.S. San Francisco? :-)
Seriously though I would be glad to organize a San Fransisco CHICKEN
if a few people are interested.
___
Chicken-users mailing list
On Wed, May 29, 2013 at 08:34:57AM +0200, Sven Hartrumpf wrote:
Tue, 28 May 2013 23:25:35 +0200, Peter.Bex wrote:
For now I'd say this is a problem with your particular gcc version.
If you or someone else can reproduce this and come up with a patch
that would be great.
I know this
On Wed, May 29, 2013 at 2:47 PM, Jörg F. Wittenberger
joerg.wittenber...@softeyes.net wrote:
On May 27 2013, Michele La Monaca wrote:
R5RS doesn't specify this kind of syntax (nor Chicken supports it):
(let* loop ((a init) (b a))
body)
To me it seems a missing piece of syntax. Am I
On Wed, May 29, 2013 at 3:53 PM, Patrick Li patrickli.2...@gmail.com wrote:
If I understand the OP correctly, he wants let* to imitate this macro.
(define-syntax named-let*
(syntax-rules ()
((named-let* name ((var val) ...)
body ...)
(let* ((var val) ...)
(let
Hi Michele,
I realized after posting my version of named-let*, that you actually
*cannot* use it to accomplish all of what you want. For that you do need
loop to be a syntactic extension, as mentioned by Jorg.
For instance, my named-let* macro would not simplify the example you posted
earlier:
Hi Peter.
Wed, 29 May 2013 19:06:26 +0200, Peter.Bex wrote:
This patch should fix it, but it does in a roundabout way: converting
the number to a string causes it to lose precision because of the default
value of (flonum-print-precision). It's more explicit to check whether
the two values
I am curious why this happens though. The only thing I could think of was the
number is being constant folded in one case or being computed in one case via a
hardware intrinsic instead of libm in the other, but the generated C code looks
identical in both cases. Perhaps some previous register
On Wed, May 29, 2013 at 03:41:30PM -0500, Jim Ursetto wrote:
I am curious why this happens though. The only thing I could think of was
the number is being constant folded in one case or being computed in one case
via a hardware intrinsic instead of libm in the other, but the generated C
On Wed, May 29, 2013 at 10:53:32PM +0200, Peter Bex wrote:
It must be due to gcc spotting the call to sin() with a constant, then
replacing it with a precalculated constant in the generated machine code.
Urgh, this is exactly what you said. Sorry for the noise.
Cheers,
Peter
--
On Wed, May 29, 2013 at 10:20 PM, Patrick Li patrickli.2...@gmail.com wrote:
Hi Michele,
I realized after posting my version of named-let*, that you actually
*cannot* use it to accomplish all of what you want. For that you do need
loop to be a syntactic extension, as mentioned by Jorg.
For
On Wed, May 29, 2013 at 11:10 PM, Michele La Monaca
mikele.chic...@lamonaca.net wrote:
On Wed, May 29, 2013 at 10:20 PM, Patrick Li patrickli.2...@gmail.com wrote:
Hi Michele,
I realized after posting my version of named-let*, that you actually
*cannot* use it to accomplish all of what you
On May 29, 2013, at 3:53 PM, Peter Bex peter@xs4all.nl wrote:
The fpsin expands to a C inline call to sin(), whereas the sin() call
expands to a call to C_a_i_flonum_sin, which is not inlineable so it has
to issue a proper function call. This then goes through libm, which is
potentially
21 matches
Mail list logo
