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 #x10FFFF))) `(/ ,(integer->char 0) ,(integer->char #xD7FF) ,(integer->char #xE000) ,(integer->char #x10FFFF))) (current-error-port)) (newline (current-error-port)) (display (equal? *all-chars* `(/ ,(integer->char 0) ,(integer->char #xD7FF) ,(integer->char #xE000) ,(integer->char #x10FFFF))) (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 #x10FFFF))) > (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