unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* Problem with apply-frame trap in 1.6 and 1.7
@ 2004-11-03 18:32 Neil Jerram
  2004-11-04 15:57 ` Marius Vollmer
  0 siblings, 1 reply; 8+ messages in thread
From: Neil Jerram @ 2004-11-03 18:32 UTC (permalink / raw)
  Cc: Marius Vollmer

Working on breakpoints for 1.6.x, I just discovered that the  following 
ENTER_APPLY trap code in eval.c goes into a tight busy loop if 
(debug-enable 'trace) and (trap-set! apply-frame-handler non-#f).

  if (CHECK_APPLY && SCM_TRAPS_P)\
    if (SCM_APPLY_FRAME_P || (SCM_TRACE_P && PROCTRACEP (proc)))\

This is because PROCTRACEP uses scm_procedure_property, which itself 
uses apply if proc is not a closure.

I think the fix (which works for me in 1.6.5) is to redefine PROCTRACEP 
to use a more targeted function, like this:

#define PROCTRACEP(x) closure_traced_p (x)

SCM closure_traced_p (SCM p)
{
  if (!SCM_CLOSUREP (p))
    return 0;
  return SCM_NIMP (scm_sloppy_assq (scm_sym_trace, SCM_PROCPROPS (p)));
}

Thoughts?  Once the fix is agreed, I suggest that this should go into 
1.6.x as well as HEAD.

Regards,
           Neil




_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-11-03 18:32 Problem with apply-frame trap in 1.6 and 1.7 Neil Jerram
@ 2004-11-04 15:57 ` Marius Vollmer
  2004-11-04 20:58   ` Neil Jerram
  0 siblings, 1 reply; 8+ messages in thread
From: Marius Vollmer @ 2004-11-04 15:57 UTC (permalink / raw)
  Cc: bug-guile

Neil Jerram <neil@ossau.uklinux.net> writes:

> Working on breakpoints for 1.6.x, I just discovered that the
> following ENTER_APPLY trap code in eval.c goes into a tight busy loop
> if (debug-enable 'trace) and (trap-set! apply-frame-handler non-#f).
>
>   if (CHECK_APPLY && SCM_TRAPS_P)\
>     if (SCM_APPLY_FRAME_P || (SCM_TRACE_P && PROCTRACEP (proc)))\
>
> This is because PROCTRACEP uses scm_procedure_property, which itself
> uses apply if proc is not a closure.

Hmm, I can't find the place where scm_procedure_property calls apply.
Could you give me a hint?  Hopefully, there is some misunderstanding
on your part so that we can avoid making subrs untraceable.  (Which is
what your proposed change does, right?)


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-11-04 15:57 ` Marius Vollmer
@ 2004-11-04 20:58   ` Neil Jerram
  2004-12-15 17:06     ` Marius Vollmer
  0 siblings, 1 reply; 8+ messages in thread
From: Neil Jerram @ 2004-11-04 20:58 UTC (permalink / raw)
  Cc: bug-guile

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

Marius Vollmer wrote:

>Neil Jerram <neil@ossau.uklinux.net> writes:
>
>  
>
>>Working on breakpoints for 1.6.x, I just discovered that the
>>following ENTER_APPLY trap code in eval.c goes into a tight busy loop
>>if (debug-enable 'trace) and (trap-set! apply-frame-handler non-#f).
>>
>>  if (CHECK_APPLY && SCM_TRAPS_P)\
>>    if (SCM_APPLY_FRAME_P || (SCM_TRACE_P && PROCTRACEP (proc)))\
>>
>>This is because PROCTRACEP uses scm_procedure_property, which itself
>>uses apply if proc is not a closure.
>>    
>>
>
>Hmm, I can't find the place where scm_procedure_property calls apply.
>Could you give me a hint?
>
Sorry! Please see the attached stack trace. scm_procedure_property calls 
scm_stand_in_proc, which calls scm_assoc, which calls scm_equal_p, which 
decides to do a generic dispatch, which eventually comes round to eval 
and apply again.

It looks like the generic dispatch happens because subrs are not one of 
the special cases in scm_equal_p, and because GOOPS has been loaded (? 
so that g_scm_equal_p != 0 -- I'm not quite sure how this happens).

>Hopefully, there is some misunderstanding
>on your part so that we can avoid making subrs untraceable.  (Which is
>what your proposed change does, right?)
>
>  
>
Yes, it does, and I agree that it would be better not to. Another option 
would be for scm_stand_in_proc to use scm_assq instead of scm_assoc. 
This seems reasonable, and works for me (i.e. avoids the busy loop), but 
is there perhaps some reason why an assoc (rather than assq) is really 
needed here?

Regards,
Neil


[-- Attachment #2: stack.txt --]
[-- Type: text/plain, Size: 11469 bytes --]

scm_assoc(scm_unused_struct * 0x00641bf8, scm_unused_struct * 0x006a4ca0) line 195 + 15 bytes
scm_stand_in_scm_proc(scm_unused_struct * 0x00641bf8) line 163 + 15 bytes
scm_procedure_property(scm_unused_struct * 0x00641bf8, scm_unused_struct * 0x0031c6b0) line 217 + 40 bytes
scm_deval(scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c2ed48) line 2840 + 73 bytes
scm_deval(scm_unused_struct * 0x006f0478, scm_unused_struct * 0x00c2ed48) line 2113 + 254 bytes
scm_deval(scm_unused_struct * 0x006d2f60, scm_unused_struct * 0x00c2edd0) line 2969 + 70 bytes
scm_deval(scm_unused_struct * 0x006f0580, scm_unused_struct * 0x00c2edd0) line 2107 + 254 bytes
scm_deval(scm_unused_struct * 0x006f0610, scm_unused_struct * 0x00c2edd0) line 2118 + 23 bytes
scm_dapply(scm_unused_struct * 0x006f06c8, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c2fca0) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x00c2fd10, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00c2fd10) line 3311 + 19 bytes
scm_body_thunk(void * 0x00127668) line 349 + 12 bytes
scm_internal_catch(scm_unused_struct * 0x0066e600, scm_unused_struct * (void *)* 0x10002a90 _scm_body_thunk, void * 0x00127668, scm_unused_struct * (void *, scm_unused_struct *, scm_unused_struct *)* 0x10001929 _scm_handle_by_proc, void * 0x00127680) line 205 + 9 bytes
scm_catch(scm_unused_struct * 0x0066e600, scm_unused_struct * 0x00c2fd10, scm_unused_struct * 0x00c2fcf0) line 551 + 27 bytes
scm_deval(scm_unused_struct * 0x006db570, scm_unused_struct * 0x00c2fd20) line 3109 + 31 bytes
scm_deval(scm_unused_struct * 0x006f07c8, scm_unused_struct * 0x00c2fda8) line 2194 + 252 bytes
scm_deval(scm_unused_struct * 0x006f0848, scm_unused_struct * 0x00c2fdf0) line 2118 + 23 bytes
scm_deval(scm_unused_struct * 0x006f0b28, scm_unused_struct * 0x00c2fe08) line 2019 + 15 bytes
scm_deval(scm_unused_struct * 0x006e87f8, scm_unused_struct * 0x00c30cd8) line 2019 + 15 bytes
scm_deval(scm_unused_struct * 0x006e8a50, scm_unused_struct * 0x00c31be8) line 2194 + 252 bytes
scm_dapply(scm_unused_struct * 0x006daa28, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c36d30) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x006da9d8, scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x00c36d70) line 3455 + 17 bytes
scm_call_3(scm_unused_struct * 0x006da9d8, scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x00c29ad8, scm_unused_struct * 0x006ee380) line 3329 + 36 bytes
call_memoize_method(void * 0x00c29ac8) line 2030 + 64 bytes
scm_memoize_method(scm_unused_struct * 0x006ee380, scm_unused_struct * 0x00c29ad8) line 2044 + 26 bytes
scm_mcache_compute_cmethod(scm_unused_struct * 0x006ee380, scm_unused_struct * 0x00c29ad8) line 322 + 13 bytes
scm_apply_generic(scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x00c29ad8) line 329 + 19 bytes
scm_call_generic_2(scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x006e66d8, scm_unused_struct * 0x00654b20) line 351 + 26 bytes
scm_equal_p(scm_unused_struct * 0x006e66d8, scm_unused_struct * 0x00654b20) line 197 + 20 bytes
scm_assoc(scm_unused_struct * 0x00654b20, scm_unused_struct * 0x006a4ca0) line 195 + 15 bytes
scm_stand_in_scm_proc(scm_unused_struct * 0x00654b20) line 163 + 15 bytes
scm_procedure_property(scm_unused_struct * 0x00654b20, scm_unused_struct * 0x0031c6b0) line 217 + 40 bytes
scm_deval(scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c29b60) line 2990 + 73 bytes
scm_deval(scm_unused_struct * 0x006f0590, scm_unused_struct * 0x00c29b60) line 2118 + 23 bytes
scm_deval(scm_unused_struct * 0x006f0610, scm_unused_struct * 0x00c29d60) line 2118 + 23 bytes
scm_dapply(scm_unused_struct * 0x006f06c8, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c2a7a8) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x00c2a810, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00c2a810) line 3311 + 19 bytes
scm_body_thunk(void * 0x0012a478) line 349 + 12 bytes
scm_internal_catch(scm_unused_struct * 0x0066e600, scm_unused_struct * (void *)* 0x10002a90 _scm_body_thunk, void * 0x0012a478, scm_unused_struct * (void *, scm_unused_struct *, scm_unused_struct *)* 0x10001929 _scm_handle_by_proc, void * 0x0012a490) line 205 + 9 bytes
scm_catch(scm_unused_struct * 0x0066e600, scm_unused_struct * 0x00c2a810, scm_unused_struct * 0x00c2a7e8) line 551 + 27 bytes
scm_deval(scm_unused_struct * 0x006db570, scm_unused_struct * 0x00c2a820) line 3109 + 31 bytes
scm_deval(scm_unused_struct * 0x006f07c8, scm_unused_struct * 0x00c2a8a8) line 2194 + 252 bytes
scm_deval(scm_unused_struct * 0x006f0848, scm_unused_struct * 0x00c2a8f0) line 2118 + 23 bytes
scm_deval(scm_unused_struct * 0x006f0b28, scm_unused_struct * 0x00c2d168) line 2019 + 15 bytes
scm_deval(scm_unused_struct * 0x006e87f8, scm_unused_struct * 0x00c2d7c8) line 2019 + 15 bytes
scm_deval(scm_unused_struct * 0x006e8a50, scm_unused_struct * 0x00c24030) line 2194 + 252 bytes
scm_dapply(scm_unused_struct * 0x006daa28, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c25100) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x006da9d8, scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x00c25130) line 3455 + 17 bytes
scm_call_3(scm_unused_struct * 0x006da9d8, scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x00c270c0, scm_unused_struct * 0x006ee380) line 3329 + 36 bytes
call_memoize_method(void * 0x00c270b0) line 2030 + 64 bytes
scm_memoize_method(scm_unused_struct * 0x006ee380, scm_unused_struct * 0x00c270c0) line 2044 + 26 bytes
scm_mcache_compute_cmethod(scm_unused_struct * 0x006ee380, scm_unused_struct * 0x00c270c0) line 322 + 13 bytes
scm_apply_generic(scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x00c270c0) line 329 + 19 bytes
scm_call_generic_2(scm_unused_struct * 0x0066e1d0, scm_unused_struct * 0x006e66d8, scm_unused_struct * 0x00644088) line 351 + 26 bytes
scm_equal_p(scm_unused_struct * 0x006e66d8, scm_unused_struct * 0x00644088) line 197 + 20 bytes
scm_assoc(scm_unused_struct * 0x00644088, scm_unused_struct * 0x006a4ca0) line 195 + 15 bytes
scm_stand_in_scm_proc(scm_unused_struct * 0x00644088) line 163 + 15 bytes
scm_procedure_property(scm_unused_struct * 0x00644088, scm_unused_struct * 0x0031c6b0) line 217 + 40 bytes
scm_deval(scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c270f0) line 2840 + 73 bytes
scm_deval(scm_unused_struct * 0x00681070, scm_unused_struct * 0x00c270f0) line 2019 + 15 bytes
scm_dapply(scm_unused_struct * 0x00d0ff60, scm_unused_struct * 0x00683dd8, scm_unused_struct * 0x00c271b0) line 3653 + 15 bytes
scm_apply(scm_unused_struct * 0x00c27250, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00c27250) line 3311 + 19 bytes
with_traps_inner(void * 0x00c27250) line 122 + 9 bytes
scm_internal_dynamic_wind(void (void *)* 0x1000a1d0 with_traps_before(void *), scm_unused_struct * (void *)* 0x1000a260 with_traps_inner(void *), void (void *)* 0x1000a220 with_traps_after(void *), void * 0x00c27250, void * 0x0012ce14) line 168 + 9 bytes
scm_with_traps(scm_unused_struct * 0x00c27250) line 136 + 28 bytes
scm_deval(scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c27258) line 2848 + 12 bytes
scm_dapply(scm_unused_struct * 0x00d10050, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c27258) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x00c272d0, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00c272d0) line 3311 + 19 bytes
scm_dynamic_wind(scm_unused_struct * 0x00c272e8, scm_unused_struct * 0x00c272d0, scm_unused_struct * 0x00c272b0) line 128 + 9 bytes
scm_deval(scm_unused_struct * 0x00683d30, scm_unused_struct * 0x00c272f0) line 3109 + 31 bytes
scm_dapply(scm_unused_struct * 0x00d10128, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c272f0) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x00c27348, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00c27348) line 3311 + 19 bytes
scm_body_thunk(void * 0x0012dba8) line 349 + 12 bytes
scm_internal_lazy_catch(scm_unused_struct * 0x00002374, scm_unused_struct * (void *)* 0x10002a90 _scm_body_thunk, void * 0x0012dba8, scm_unused_struct * (void *, scm_unused_struct *, scm_unused_struct *)* 0x10001929 _scm_handle_by_proc, void * 0x0012dbc0) line 281 + 9 bytes
scm_lazy_catch(scm_unused_struct * 0x00002374, scm_unused_struct * 0x00c27348, scm_unused_struct * 0x006a0f80) line 580 + 27 bytes
scm_deval(scm_unused_struct * 0x00683d18, scm_unused_struct * 0x00c27358) line 3109 + 31 bytes
scm_dapply(scm_unused_struct * 0x00d101f8, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00c27358) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x00c273b8, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00c273b8) line 3311 + 19 bytes
scm_body_thunk(void * 0x0012e32c) line 349 + 12 bytes
scm_internal_catch(scm_unused_struct * 0x00002374, scm_unused_struct * (void *)* 0x10002a90 _scm_body_thunk, void * 0x0012e32c, scm_unused_struct * (void *, scm_unused_struct *, scm_unused_struct *)* 0x10001929 _scm_handle_by_proc, void * 0x0012e344) line 205 + 9 bytes
scm_catch(scm_unused_struct * 0x00002374, scm_unused_struct * 0x00c273b8, scm_unused_struct * 0x00c27398) line 551 + 27 bytes
scm_deval(scm_unused_struct * 0x00683690, scm_unused_struct * 0x00c273c8) line 3109 + 31 bytes
scm_deval(scm_unused_struct * 0x00d10228, scm_unused_struct * 0x00c273c8) line 2194 + 252 bytes
scm_deval(scm_unused_struct * 0x00d105a0, scm_unused_struct * 0x00d108b0) line 2194 + 252 bytes
scm_deval(scm_unused_struct * 0x00d109c0, scm_unused_struct * 0x00d10a10) line 2194 + 252 bytes
scm_dapply(scm_unused_struct * 0x00d10bb8, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00d10a10) line 3657 + 224 bytes
scm_apply(scm_unused_struct * 0x00d10ba0, scm_unused_struct * 0x00002974, scm_unused_struct * 0x00002974) line 3455 + 17 bytes
scm_call_0(scm_unused_struct * 0x00d10ba0) line 3311 + 19 bytes
scm_dynamic_wind(scm_unused_struct * 0x00d10bd8, scm_unused_struct * 0x00d10ba0, scm_unused_struct * 0x00d10b68) line 128 + 9 bytes
scm_ceval(scm_unused_struct * 0x0069dcb0, scm_unused_struct * 0x00d10c18) line 3171 + 298 bytes
scm_i_eval_x(scm_unused_struct * 0x00696050, scm_unused_struct * 0x00696030) line 4064 + 79 bytes
scm_primitive_eval_x(scm_unused_struct * 0x00696050) line 4082 + 13 bytes
inner_eval_x(void * 0x00696050) line 4129 + 9 bytes
scm_internal_dynamic_wind(void (void *)* 0x1001fa90 change_environment(void *), scm_unused_struct * (void *)* 0x1001fb70 inner_eval_x(void *), void (void *)* 0x1001fb00 restore_environment(void *), void * 0x00696050, void * 0x00696048) line 168 + 9 bytes
scm_eval_x(scm_unused_struct * 0x00696050, scm_unused_struct * 0x0066b050) line 4141 + 42 bytes
scm_shell(int 1, char * * 0x00540ea0) line 677 + 28 bytes
inner_main(void * 0x00000000, int 1, char * * 0x00540ea0) line 80 + 13 bytes
invoke_main_func(void * 0x0012ff08) line 636 + 28 bytes
scm_boot_guile_1(long * 0x0012ff18, main_func_closure * 0x0012ff08) line 616 + 9 bytes
scm_boot_guile(int 1, char * * 0x00540ea0, void (void)* 0x00401070 inner_main(void *, int, char * *), void * 0x00000000) line 440 + 13 bytes
main(int 1, char * * 0x00540ea0) line 95 + 20 bytes

[-- Attachment #3: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-11-04 20:58   ` Neil Jerram
@ 2004-12-15 17:06     ` Marius Vollmer
  2004-12-15 17:12       ` Marius Vollmer
  0 siblings, 1 reply; 8+ messages in thread
From: Marius Vollmer @ 2004-12-15 17:06 UTC (permalink / raw)
  Cc: bug-guile

Neil Jerram <neil@ossau.uklinux.net> writes:

>>Hmm, I can't find the place where scm_procedure_property calls apply.
>>Could you give me a hint?
>>
> Sorry! Please see the attached stack trace. scm_procedure_property
> calls scm_stand_in_proc, which calls scm_assoc, which calls
> scm_equal_p, which decides to do a generic dispatch, which eventually
> comes round to eval and apply again.

Ahh, OK!  Thanks.

>>Hopefully, there is some misunderstanding
>>on your part so that we can avoid making subrs untraceable.  (Which is
>>what your proposed change does, right?)
>>
> Yes, it does, and I agree that it would be better not to. Another
> option would be for scm_stand_in_proc to use scm_assq instead of
> scm_assoc. This seems reasonable, and works for me (i.e. avoids the
> busy loop), but is there perhaps some reason why an assoc (rather than
> assq) is really needed here?

I think scm_assq is good enough.  I will make that change.


(And sorry for the delay.)


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-12-15 17:06     ` Marius Vollmer
@ 2004-12-15 17:12       ` Marius Vollmer
  2004-12-15 17:29         ` Neil Jerram
  0 siblings, 1 reply; 8+ messages in thread
From: Marius Vollmer @ 2004-12-15 17:12 UTC (permalink / raw)
  Cc: bug-guile

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> I think scm_assq is good enough.  I will make that change.

Waitaminute!  We no longer use alists in 1.6:

2004-08-11  Marius Vollmer  <mvo@zagadka.de>

	* gc.c, procprop.c (scm_init_storage, scm_stand_in_procs,
	scm_stand_in_proc): Use a hastable for scm_stand_in_procs instead
	of an alist.  Thanks to Matthias Koeppe!

Neil, do you have that change?


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-12-15 17:12       ` Marius Vollmer
@ 2004-12-15 17:29         ` Neil Jerram
  2004-12-17  0:07           ` Neil Jerram
  0 siblings, 1 reply; 8+ messages in thread
From: Neil Jerram @ 2004-12-15 17:29 UTC (permalink / raw)
  Cc: bug-guile

Marius Vollmer wrote:
> 
> Waitaminute!  We no longer use alists in 1.6:
> 
> 2004-08-11  Marius Vollmer  <mvo@zagadka.de>
> 
> 	* gc.c, procprop.c (scm_init_storage, scm_stand_in_procs,
> 	scm_stand_in_proc): Use a hastable for scm_stand_in_procs instead
> 	of an alist.  Thanks to Matthias Koeppe!
> 
> Neil, do you have that change?

Yes, in CVS 1.6.x I do have that change.  I'm sorry - when I reported 
this I was working with a 1.6.4 release, I think (possibly 1.6.5).

So I guess that should fix the problem, because the hashtable here is 
using hashq - I'll check and let you know.

Regards,
	Neil


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-12-15 17:29         ` Neil Jerram
@ 2004-12-17  0:07           ` Neil Jerram
  2004-12-17 11:20             ` Marius Vollmer
  0 siblings, 1 reply; 8+ messages in thread
From: Neil Jerram @ 2004-12-17  0:07 UTC (permalink / raw)
  Cc: bug-guile

Neil Jerram wrote:
> 
> Yes, in CVS 1.6.x I do have that change.  I'm sorry - when I reported 
> this I was working with a 1.6.4 release, I think (possibly 1.6.5).
> 
> So I guess that should fix the problem, because the hashtable here is 
> using hashq - I'll check and let you know.

Yes, the use of hashq fixes the problem that I reported, so no further 
change is needed - good news.

(And for the record, that change was made on 2004-08-11, which means it 
was included in 1.6.5 (2004-09-19) but not in 1.6.4 (2003-04-21).)

When you get a moment, could you also look at my patch for stacks.c, 
which makes (call-with-current-continuation make-stack) work?

Thanks,
	Neil


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Problem with apply-frame trap in 1.6 and 1.7
  2004-12-17  0:07           ` Neil Jerram
@ 2004-12-17 11:20             ` Marius Vollmer
  0 siblings, 0 replies; 8+ messages in thread
From: Marius Vollmer @ 2004-12-17 11:20 UTC (permalink / raw)
  Cc: bug-guile

Neil Jerram <neil@ossau.uklinux.net> writes:

> Yes, the use of hashq fixes the problem that I reported, so no further
> change is needed - good news.

Ok!

> When you get a moment, could you also look at my patch for stacks.c,
> which makes (call-with-current-continuation make-stack) work?

Yes, it is 'on the list'...


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-12-17 11:20 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-03 18:32 Problem with apply-frame trap in 1.6 and 1.7 Neil Jerram
2004-11-04 15:57 ` Marius Vollmer
2004-11-04 20:58   ` Neil Jerram
2004-12-15 17:06     ` Marius Vollmer
2004-12-15 17:12       ` Marius Vollmer
2004-12-15 17:29         ` Neil Jerram
2004-12-17  0:07           ` Neil Jerram
2004-12-17 11:20             ` Marius Vollmer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).