On Mar 2, 2010, at 05:23, Ludovic Courtès wrote:
>>> We don't actually reference yyget_leng elsewhere explicitly; can we just
>>> get rid of the declaration?
>>
>> This patch has been working fine for me on my Mac; we may be able to delete
>> more of the declarations, depending what other lex im
On Thu 04 Mar 2010 09:25, Ken Raeburn writes:
> (gdb) bt
> #0 0x7fff81777fe6 in kill ()
> #1 0x0001000cfb5f in scm_error_pair_access (non_pair=0x10195e230) at
> ../../libguile/pairs.c:64
> #2 0x000100022275 in scm_i_dowinds (to=0x101e125e0, delta=1,
> turn_func=0, data=0x0) at ../../
Hi,
Ken Raeburn writes:
> On Mar 2, 2010, at 05:23, Ludovic Courtès wrote:
We don't actually reference yyget_leng elsewhere explicitly; can we just
get rid of the declaration?
>>>
>>> This patch has been working fine for me on my Mac; we may be able to delete
>>> more of the declara
On Mar 4, 2010, at 05:52, Ludovic Courtès wrote:
> I have this:
>
> --8<---cut here---start->8---
> $ grep yyget_leng libguile/c-tokenize.c
> int yyget_leng (void);
> int yyget_leng (void );
> int yyget_leng (void)
Interesting... looks like Apple's not usi
Hey,
Ken Raeburn writes:
> Hard-coding uses of $(abs_srcdir) nails down a build tree to a
> specific location in the file system.
That’s often the case anyway so I wouldn’t worry.
Thanks,
Ludo’.
Hey folks,
One of the last missing features / regressions on my list for 2.0 is to
fix make-stack and start-stack to work with the VM.
In case you haven't noticed yet, if you get an error at the REPL and ask
for a backtrace from the debugger, you get not only the frames that
pertain to your own c
