Re: [Chicken-users] obsolete code
On Sep 27 2011, Alex Shinn wrote: On Tue, Sep 27, 2011 at 3:39 AM, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: I found theses definitions in the irregex code mirroring srfi-1 simplified cases. (define (filter pred ls) (let lp ((ls ls) (res '())) (if (null? ls) (reverse res) (lp (cdr ls) (if (pred (car ls)) (cons (car ls) res) res) (define (remove pred ls) (let lp ((ls ls) (res '())) (if (null? ls) (reverse res) (lp (cdr ls) (if (pred (car ls)) res (cons (car ls) res)) The irregex code itself appears not to use them anywhere. Irregex is designed so that (load irregex.scm) will work in any vaguely Scheme-like system. In the near future I plan on switching to the R7RS module system, but in the meantime I have no interest in breaking that simplicity. I do understand and really appreciate that goal. But not including those two definitions should IMHO not do any harm. I simply can not see where those would be used within irregex.scm. /Jörg ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] obsolete code
On Tue, Sep 27, 2011 at 5:30 PM, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: But not including those two definitions should IMHO not do any harm. I simply can not see where those would be used within irregex.scm. Sorry, I thought you were suggesting importing srfi-1 instead of using those definitions. The references to them do seem to have been removed recently. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] two minor tweaks to runtime.c
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.
The two spots are in runtime.c C_a_i_list and C_h_list.
In this case a diff seems worse to me than a citation;
The current code is:
C_word C_a_i_list(C_word **a, int c, ...)
{
va_list v;
C_word x, last, current,
first = C_SCHEME_END_OF_LIST;
va_start(v, c);
for(last = C_SCHEME_UNDEFINED; c--; last = current) {
x = va_arg(v, C_word);
current = C_a_pair(a, x, C_SCHEME_END_OF_LIST);
if(last != C_SCHEME_UNDEFINED)
C_set_block_item(last, 1, current);
else first = current;
}
va_end(v);
return first;
}
Here my current (tested) replacement:
C_word C_a_i_list(C_word **a, int c, ...)
{
va_list v;
C_word x, last, current, first;
va_start(v, c);
if(c--) {
x = va_arg(v, C_word);
first = last = C_a_pair(a, x, C_SCHEME_END_OF_LIST);
for(; c--; last = current) {
x = va_arg(v, C_word);
current = C_a_pair(a, x, C_SCHEME_END_OF_LIST);
C_set_block_item(last, 1, current);
}
} else {
first = C_SCHEME_END_OF_LIST;
}
va_end(v);
return first;
}
C_word C_h_list(int c, ...)
{
/* Similar to C_a_i_list(), but put slots with nursery data into mutation
stack: */
va_list v;
C_word x, last, current, first;
va_start(v, c);
if(c--) {
x = va_arg(v, C_word);
first = last = C_a_pair(C_heaptop, x, C_SCHEME_END_OF_LIST);
for(; c--; last = current) {
x = va_arg(v, C_word);
current = C_a_pair(C_heaptop, x, C_SCHEME_END_OF_LIST);
if(C_in_stackp(x))
C_mutate(C_u_i_car(current), x);
C_set_block_item(last, 1, current);
}
} else {
first = C_SCHEME_END_OF_LIST;
}
va_end(v);
return first;
}
Note that I'm tempted to move the va_start/va_end into the if.
I'm just unsure whether or not that's allowed by C standards.
(But I can't see how it could harm.)
/Jörg
___
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 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. Cheers, Peter -- 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 ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] define-for-syntax modules
It appears that modules either leak define-for-syntax bindings, or aren't meant to contain them. If the latter is the case, please ignore. However, this seems unintuitive. (module test () (import scheme chicken) (define-for-syntax + string-append)) $ csi -nq #;1 (use test) ; loading ./test.import.scm ... ; loading /usr/lib/chicken/6/scheme.import.so ... ; loading /usr/lib/chicken/6/chicken.import.so ... ; loading ./test.so ... #;2 (+ a b c) abc #;3 I found a note on import-for-syntax in the manual which looks like it might refer to the same issue, but I'm not certain. In any case, I thought I'd bring it up in case this is a bug, or if there's something I'm missing. Evan ___ 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 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. ___ 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
