Re: scm_num_eq

2004-01-22 Thread Marius Vollmer
Roland Orre <[EMAIL PROTECTED]> writes: > Hi, > This code gives the expected result: > if (SCM_EQ_P(SCM_CDR(handle),SCM_MAKINUM(0))) > > but this code doesn't: > if (scm_num_eq_p(SCM_CDR(handle),SCM_MAKINUM(0))) > > as this latter code always gives false back. Hmm, it should always be true: sc

scm_num_eq

2004-01-22 Thread Roland Orre
Hi, This code gives the expected result: if (SCM_EQ_P(SCM_CDR(handle),SCM_MAKINUM(0))) but this code doesn't: if (scm_num_eq_p(SCM_CDR(handle),SCM_MAKINUM(0))) as this latter code always gives false back. I guess it wouldn't matter how the background is, but this is the case. The key cell is

Re: more garbled documentation in uniform arrays

2004-01-22 Thread Kevin Ryde
"Rouben Rostamian" <[EMAIL PROTECTED]> writes: > > The subject of this section is "Conventional Arrays". Mixing in > the documentation of uniform-arrays/uniform-vectors is not ideal. The whole division between the two isn't terribly clear. Partly because there isn't really a division :), there's

Re: core dump.

2004-01-22 Thread Marius Vollmer
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > It seems to be working. There was a stray variable in eval.c, though. > I fixed that. Yep, thanks. > BTW, how is GUILE 1.8 progressing? The two big things that need to be done are: GH replacement (including docs of course) and finishing the thread

Re: core dump.

2004-01-22 Thread Han-Wen Nienhuys
[EMAIL PROTECTED] writes: > Please try again, I think I have fixed it: Thanks for your quick reply. It seems to be working. There was a stray variable in eval.c, though. I fixed that. BTW, how is GUILE 1.8 progressing? Have you considered switching to a time-based release schedule, like GNO

Re: core dump.

2004-01-22 Thread Marius Vollmer
Bill Schottstaedt <[EMAIL PROTECTED]> writes: > > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > > (gdb) bt > > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > > I've hit this so many times I've stopped using the CVS Guile -- there's > definite

Re: bugreport, concise version

2004-01-22 Thread Marius Vollmer
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > I consider this a very severe bug. Can you fix this please? Done! Dirk, could you double-check the diff below? I think it is obviously the right thing to do. Without the change, bodies with internal definitions would get expanded on every executi

segfault on incorrect code

2004-01-22 Thread Alexandre Duret-Lutz
Seeing a thread named "core dump" remembered me an old bug I stumbled upon years ago (in guile 1.3), but never reported. It seems to be still present in recent versions. % guile guile> (version) "1.6.4" guile> (define (foo a b c) (< b c)) guile> (sort '(3 2 1) foo) zsh: segmentation fault guile

Re: core dump.

2004-01-22 Thread Dirk Herrmann
Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: [Switching to Thread 1074493760 (LWP 27557)] 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 (gdb) bt #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 #1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, e

Re: core dump.

2004-01-22 Thread Han-Wen Nienhuys
[EMAIL PROTECTED] writes: > > [Switching to Thread 1074493760 (LWP 27557)] > > 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > > (gdb) bt > > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > > #1 0x4002f654 in scm_unmemocopy (x=0x404da7e8, env=0x405

core dump.

2004-01-22 Thread Bill Schottstaedt
> 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 > (gdb) bt > #0 0x4002f524 in unmemocar (form=0x4050d7b8, env=0x167f) at eval.c:2246 I've hit this so many times I've stopped using the CVS Guile -- there's definitely a bug tickled by backtrace, but I haven't had time to try t

Today's Daily Double Stock (OTCBB:SPSC)

2004-01-22 Thread Daily Double Stocks
Title: The Daily Double Stock Reporter   Stock Profile Company Name    Spectrum Sci & Software Hldgs