Re: [Chicken-users] Help building latest sources

[Christian Kellermann]

Hi Vitaly!

* Vitaly Magerya  [111008 00:06]:
> Hi, folks. I'm trying to build the latest git sources (I've got 4.7.0
> installed); the build proceeds for a while and then fails like this:

Did you build a boot chicken for bootstrapping? Note that you will need a 
chicken installed for this.

$ gmake PLATFORM=bsd boot-chicken
$ gmake PLATFORM=bsd CHICKEN=./chicken-boot
$ gmake PLATFORM=bsd install

I have put up a little tutorial on the wiki for this here
http://wiki.call-cc.org/chickenista-guide#building-a-development-snapshot-or-from-git

HTH,

Christian

-- 
Who can (make) the muddy water (clear)? Let it be still, and it will
gradually become clear. Who can secure the condition of rest? Let
movement go on, and the condition of rest will gradually arise.
 -- Lao Tse. 

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Help building latest sources

[Vitaly Magerya]

Hi, folks. I'm trying to build the latest git sources (I've got 4.7.0
installed); the build proceeds for a while and then fails like this:

$ gmake PLATFORM=bsd
...
chicken setup-api.scm [...] -output-file setup-api.c

Syntax error (import): cannot import from undefined module

scheme

Expansion history:

  (##core#begin (module setup-api ..
  (module setup-api ((run execute) ..
  (##core#module setup-api ((run execute) ..
  (import scheme chicken foreign irregex ..   <--

The system is a FreeBSD 8.2 amd64 box. The full log is at [1].

So, any ideas as to what am I doing wrong?

For the record, building 4.7.0 sources in the same way (after gmake
spotless to remove pregenerated sources) works flawlessly.

[1] http://tx97.net/~magv/chicken-2011-10-08-gmake.log

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] more: news from the valgrind front - another test case

[Alan Post]

On Fri, Oct 07, 2011 at 10:49:42PM +0200, Jörg F. Wittenberger wrote:
> On Oct 7 2011, Alan Post wrote:
> 
> >Given the odd behavior you're experiencing, I would suggest
> >expanding your test case:
> 
> Good point.  Here the results:
> 
> Now watch the interesting value (should be all 4 true a/a,i/i,a/i,i/a):
> #t#t#f#f
> 
> That is:
> (equal? *all-chars* *all-chars*)
> => #t
> (equal? `(/ ,(integer->char 0)
>,(integer->char #xD7FF)
>,(integer->char #xE000)
>,(integer->char #x10))
>`(/ ,(integer->char 0)
>,(integer->char #xD7FF)
>,(integer->char #xE000)
>,(integer->char #x10)))
> => #t
> (equal? *all-chars*
>`(/ ,(integer->char 0)
>,(integer->char #xD7FF)
>,(integer->char #xE000)
>,(integer->char #x10)))
> => #f
> (equal? `(/ ,(integer->char 0) ,(integer->char #xD7FF)
>  ,(integer->char #xE000) ,(integer->char #x10))
> *all-chars* )
> => #f
> 
> Or: comparison of just initialised value fails to be equal?
> to the literal value.
> 
> Can you/anyone reproduce this result?
> 

It would assume, looking at this output, that *all-chars* is not the
value of the string you're comparing it too:

 * it compares #t to itself.
 * the list compare #t to itself.
 * they don't ocmpare #t to each other.

This suggests that *all-chars* has some value other than what you'r
comparing it to.

-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

Re: [Chicken-users] more: news from the valgrind front - another test case

[Jörg F . Wittenberger]

On Oct 7 2011, Alan Post wrote:


Given the odd behavior you're experiencing, I would suggest
expanding your test case:


Good point.  Here the results:

Now watch the interesting value (should be all 4 true a/a,i/i,a/i,i/a):
#t#t#f#f

That is:
(equal? *all-chars* *all-chars*)
=> #t
(equal? `(/ ,(integer->char 0)
 ,(integer->char #xD7FF)
 ,(integer->char #xE000)
 ,(integer->char #x10))
 `(/ ,(integer->char 0)
 ,(integer->char #xD7FF)
 ,(integer->char #xE000)
 ,(integer->char #x10)))
=> #t
(equal? *all-chars*
 `(/ ,(integer->char 0)
 ,(integer->char #xD7FF)
 ,(integer->char #xE000)
 ,(integer->char #x10)))
=> #f
(equal? `(/ ,(integer->char 0) ,(integer->char #xD7FF)
 ,(integer->char #xE000) ,(integer->char #x10))
*all-chars* )
=> #f

Or: comparison of just initialised value fails to be equal?
to the literal value.

Can you/anyone reproduce this result?

(So far valgrind not envolved, just this debug code in irregex-core.scm!)


/Jörg





___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] strange error messages when compiling with -O3 switch

[Alan Post]

On Fri, Oct 07, 2011 at 04:53:29PM +0200, j...@jugilo.de wrote:
> 
> Hello all,
> 
> after having rewritten my tuples egg and tried to install it with
> chicken-install, I got a lot of warnings of type
> 
> warning: at toplevel: in procedure call in 'g..',
> expectet x arguments, but was given 0
> 
> I can't understand the reason for that, because according to the tests
> the egg works. Moreover, compiling with -O2 instead of -O3 no warnings
> appear. Can anyone help me?
> 
> Thanks in advance
> 
> Juergen
> 

My initial thought, reading this, was to wonder if you compiled your
chicken with too old a chicken compiler, not performing a bootstrap.
And as such you've got an inconsistent compiling generating this error
message.

Do other eggs/codes work?  Can you reproduce this outside of the
tuples egg?

-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

Re: [Chicken-users] more: news from the valgrind front - another test case

[Alan Post]

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

[Chicken-users] more: news from the valgrind front - another test case

[Jörg F . Wittenberger]

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 #x10))) 
(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

[Chicken-users] strange error messages when compiling with -O3 switch

[ju]

Hello all,

after having rewritten my tuples egg and tried to install it with
chicken-install, I got a lot of warnings of type

warning: at toplevel: in procedure call in 'g..',
expectet x arguments, but was given 0

I can't understand the reason for that, because according to the tests
the egg works. Moreover, compiling with -O2 instead of -O3 no warnings
appear. Can anyone help me?

Thanks in advance

Juergen

---
Dr. Juergen Lorenz
Flensburger Str. 12
D-10557 Berlin

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] news from the valgrind front

[Jörg F . Wittenberger]

I ran into another valgrind message.

This one comes up *only* if -:g is given (that is 
gc_report_flag == 1), and only if we come to


 never_mind_edsgar:

by "goto".

In that case the variable "cont" might be not initialized,
and valgrind complains as it should.

So far it looks as if setting "count" to (whatever actually,
it's going to be effective under gc_report_flag only anyway)
value makes the warning go away.

I choose to copy the statement from major gc.  But that's a wild
guess at the end of the day.

Since I have no idea whether or not the value is correct,
I'm not attaching a buggy diff here.

The relevant lines from runtime.c/C_reclaim

   if(gc_mode == GC_REALLOC) {
 C_rereclaim2(percentage(heap_size, C_heap_growth), 0);
 gc_mode = GC_MAJOR;
 count = (C_uword)tospace_top - (C_uword)tospace_start;
 goto never_mind_edsgar;
   }

The line

 count = (C_uword)tospace_top - (C_uword)tospace_start;

would be new.  But if my guess was wrong, then the value given
to count would be wrong.

The important part: assign somthing to count.

In that case for valgrinds sake.  (Which so far looks quite good
as a memory debugger.)

Best regards

/Jörg




___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users