Re: problem becouse scm_tc7_contin is not defined

Re: problem becouse scm_tc7_contin is not defined

[P Pareit]

On Tuesday 10 September 2002 12:32 pm, Marius Vollmer wrote:
>
> P Pareit <pieter.pareit@planetinternet.be> writes:
> > By doing a grep on scm_tc7_contin in the source tree of guile I
> > found out that scm_tc7_contin is no longer supported and I have to
> > use SMOB continuation for rootcont instead.
>
> Scwm is digging into the innards of Guile, and we don't really support
> code like scm_internal_cwdr_no_unwind.  Scm_internal_cwdr_no_unwind is
> essentially a copy of Guile's scm_internal_cwdr with some bits
> removed.  There is a reason why it is called scm_*internal*_cwdr. ;-)
>
> However, scwm has probably a real need for
> scm_internal_cwdr_no_unwind, and we do want to support something like
> it officially in the future so that scwm does not need to provide its
> own hack.
>
> You might consider fixing scwm's hack like this
>
>   SCM
>   scm_internal_cwdr_no_unwind (scm_catch_body_t body, void *body_data,
>                                scm_catch_handler_t handler, void
> *handler_data, SCM_STACKITEM *stack_start)
>   {
>     SCM answer, old_winds;
>     old_winds = scm_dynwinds;
>     scm_dynwinds = SCM_EOL;
>
>     answer = scm_internal_cwdr (body, body_data, handler, handler_data,
>                                 stack_start); /* changed to stack_start */
>
>     scm_dynwinds = old_winds;
>     return answer;
>   }

Tried and failed, it does compile but I get a segment fault at startup and 
scm_internal_cwdr_no_unwind shows up in the backtrace. So I think this is the 
problem.

>
> This will _only_ work when HANDLER does not do a non-local exit (via
> longjmp, or similar).  If you want to support that (which I
> recommend), you need to defer running HANDLER (with the same trick
> that scm_internal_cwdr uses) until scm_dynwinds has been restored.
>
> The above code should be more resilient against changes to the
> internals of Guile, but it is still a hack.  We have a proposal to fix
> this for real.  See workbook/extension/dynamic-roots.text in CVS.
>
> You might also try to just scm_internal_cwdr instead of
> scm_internal_cwdr_no_unwind.  That should work as well, but at a
> slight performance loss.
>
> Could you bring this up with the scwm developers so that we might find
> a solution that makes everyone happy?

Yes, will do. I'm afraid that for the moment guile-1.4.* will still be used 
and development is not very active for the moment. I hope that with the way 
guile is going at the moment, scwm will soon follow.

pieter;



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: problem becouse scm_tc7_contin is not defined

[Marius Vollmer]

P Pareit <pieter.pareit@planetinternet.be> writes:

> Tried and failed, it does compile but I get a segment fault at
> startup and scm_internal_cwdr_no_unwind shows up in the
> backtrace. So I think this is the problem.

Hmm.  I tried my version of scm_internal_cwdr_no_unwind with guile-gtk
and it did work without problems.  Are you sure that you don't run
into this:

> > This will _only_ work when HANDLER does not do a non-local exit (via
> > longjmp, or similar).  If you want to support that (which I
> > recommend), you need to defer running HANDLER (with the same trick
> > that scm_internal_cwdr uses) until scm_dynwinds has been restored.

Could you try this version: (yeah, I could download Scwm and do this
myself, but... ;)

SCM
scm_internal_cwdr_no_unwind (scm_catch_body_t body, void *body_data,
			     scm_catch_handler_t handler, void *handler_data,
			     SCM_STACKITEM *stack_start)
{
  return scm_internal_cwdr (body, body_data, handler, handler_data,
	                    stack_start);
}

That version is not very interesting but it will ket us see whether
the bug is with scm_internal_cwdr_no_unwind or with some other part of
Scwm or Guile.

> > Could you bring this up with the scwm developers so that we might find
> > a solution that makes everyone happy?
> 
> Yes, will do. I'm afraid that for the moment guile-1.4.* will still be used 
> and development is not very active for the moment. I hope that with the way 
> guile is going at the moment, scwm will soon follow.

I've contacted the Scwm developers as well, but I would be happy if
you could continue to handle this.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: problem becouse scm_tc7_contin is not defined

[P Pareit]

On Tuesday 10 September 2002 09:04 pm, you wrote:
> P Pareit <pieter.pareit@planetinternet.be> writes:
> > Tried and failed, it does compile but I get a segment fault at
> > startup and scm_internal_cwdr_no_unwind shows up in the
> > backtrace. So I think this is the problem.
>
> Hmm.  I tried my version of scm_internal_cwdr_no_unwind with guile-gtk
> and it did work without problems.  Are you sure that you don't run
>
> into this:
> > > This will _only_ work when HANDLER does not do a non-local exit (via
> > > longjmp, or similar).  If you want to support that (which I
> > > recommend), you need to defer running HANDLER (with the same trick
> > > that scm_internal_cwdr uses) until scm_dynwinds has been restored.
>
> Could you try this version: (yeah, I could download Scwm and do this
> myself, but... ;)
>
> SCM
> scm_internal_cwdr_no_unwind (scm_catch_body_t body, void *body_data,
> 			     scm_catch_handler_t handler, void *handler_data,
> 			     SCM_STACKITEM *stack_start)
> {
>   return scm_internal_cwdr (body, body_data, handler, handler_data,
> 	                    stack_start);
> }
>
> That version is not very interesting but it will ket us see whether
> the bug is with scm_internal_cwdr_no_unwind or with some other part of
> Scwm or Guile.
>

Well, it gave me absolutly the same bactrace as before:

(gdb) backtrace
#0  0x4007bd5c in scm_hook_empty_p (hook=0x0) at hooks.c:227
#1  0x0806069e in scwm_handle_error (data=0x809023a, tag=0x80a8f50,
    throw_args=0x404825a8) at callbacks.c:501
#2  0x400a0811 in scm_internal_catch (tag=0x2374, body=0x400a0a30 <cwss_body>,
    body_data=0xbffff240, handler=0x8060650 <scwm_handle_error>, 
    handler_data=0x809023a) at throw.c:200
#3  0x400a0aae in scm_internal_stack_catch (tag=0x40497c38, body=0,
    body_data=0x0, handler=0x8060650 <scwm_handle_error>, 
    handler_data=0x809023a) at throw.c:330
#4  0x08060550 in scwm_body_eval_str (body_data=0x8092120) at callbacks.c:451
#5  0x400a0839 in scm_internal_catch (tag=0x2374,
    body=0x80604e0 <scwm_body_eval_str>, body_data=0x8092120,
    handler=0x40094160 <cwdr_handler>, handler_data=0xbffff3e0) at throw.c:205
#6  0x400942a4 in scm_internal_cwdr (body=0x80604e0 <scwm_body_eval_str>,
    body_data=0x8092120, handler=0x805686c <scm_handle_by_message_noexit>, 
    handler_data=0x809023a, stack_start=0x0) at root.c:283
#7  0x0806ef4f in scm_internal_cwdr_no_unwind (
    body=0x80604e0 <scwm_body_eval_str>, body_data=0x8092120,
    handler=0x805686c <scm_handle_by_message_noexit>, handler_data=0x809023a,
    stack_start=0xbffff464) at guile-compat.c:64
#8  0x08060782 in scwm_safe_eval_str (
    string=0x8092120 "\n\n\n\n\n\n\n\n(use-modules (app scwm 
optargs))\n\n(define-public guile-version (+ (string->number (major-version)) 
\n\t\t\t\t(/ (string->number (minor-version)) 10)))\n\n\n\n(if (> 
guile-version 1.3)\n    (setvbuf (cur"...) at callbacks.c:532
#9  0x0807f55d in scwm_main (argc=134932312, argv=0x5b) at scwm.c:1220
#10 0x40072ebe in gh_launch_pad (closure=0x807ed20, argc=1, argv=0xbffff944)
    at gh_init.c:60
#11 0x4007c987 in invoke_main_func (body_data=0x0) at init.c:636
#12 0x4007c942 in scm_boot_guile_1 (base=0xbffff88c, closure=0xbffff890)
    at init.c:616
#13 0x4007c63b in scm_boot_guile (argc=0, argv=0x0, main_func=0, closure=0x0)
    at init.c:440
#14 0x40072ef9 in gh_enter (argc=1, argv=0xbffff944,
    c_main_prog=0x807ed20 <scwm_main>) at gh_init.c:70
#15 0x0807ed0b in main (argc=1, argv=0xbffff944) at scwm.c:607
#16 0x4030c082 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) 

The problem seems to start at #8, I wonder what happens if something goes 
wrong in the evaluation of "(use-modules (...))".

>
> I've contacted the Scwm developers as well, but I would be happy if
> you could continue to handle this.

Yes, I will. One of the things that I might best do, is to write an a small as 
possible program that uses guile in the same way as scwm now. 

pieter;


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: problem becouse scm_tc7_contin is not defined

[Marius Vollmer]

P Pareit <pieter.pareit@planetinternet.be> writes:

> > SCM
> > scm_internal_cwdr_no_unwind (scm_catch_body_t body, void *body_data,
> > 			     scm_catch_handler_t handler, void *handler_data,
> > 			     SCM_STACKITEM *stack_start)
> > {
> >   return scm_internal_cwdr (body, body_data, handler, handler_data,
> > 	                    stack_start);
> > }
> >
> > That version is not very interesting but it will ket us see whether
> > the bug is with scm_internal_cwdr_no_unwind or with some other part of
> > Scwm or Guile.
> >
> 
> Well, it gave me absolutly the same bactrace as before:

Aha!  So it is not the fault of scm_internal_cwdr_no_unwind.  Since
you already have the bug in the debugger, please try to figure out
what is happenening exactly.

> (gdb) backtrace
> #0  0x4007bd5c in scm_hook_empty_p (hook=0x0) at hooks.c:227

This looks wrong.  scm_hook_empty_p should probably not be called with
a NULL argument.

> #6  0x400942a4 in scm_internal_cwdr (body=0x80604e0 <scwm_body_eval_str>,
>     body_data=0x8092120, handler=0x805686c <scm_handle_by_message_noexit>, 
>     handler_data=0x809023a, stack_start=0x0) at root.c:283

Note that stack_start is NULL...

> #7  0x0806ef4f in scm_internal_cwdr_no_unwind (
>     body=0x80604e0 <scwm_body_eval_str>, body_data=0x8092120,
>     handler=0x805686c <scm_handle_by_message_noexit>, handler_data=0x809023a,
>     stack_start=0xbffff464) at guile-compat.c:64

while it isn't here.  Maybe GDB doesn't see the whole truth.  Try
compiling without "-O2".

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: problem becouse scm_tc7_contin is not defined

[Steve Tell]

On 10 Sep 2002, Marius Vollmer wrote:

> I've contacted the Scwm developers as well, but I would be happy if
> you could continue to handle this.

_Are_ there any scwm developers any more?

I thought the original authors had gone on to other things.  The latest
"news" on scwm.sourceforge.net is from March 2000 about version 0.99.6
which requires guile 1.3.4.

Or am I looking in the wrong place?  I was thinking of abandoning scwm
myself, perhaps I don't have to if work is continuing and there is a 
new version that at least works with guile-1.4?


I originaly borrowed a lot of code from scwm for use in gwave and
guilfred, (including doc/init snarfing and code using scm_internal_cwdr)
which needed minor revision for 1.4 and substantial overhaul for 1.5.x
(1.6).

On foo.doc/foo.x snarfing, I concluded that it was hard to support both
guile-1.4 and guile-1.6 while using guile's provided guile-snarf and
supplied macros, so I seperated the application from that, borrowing from
both versions and providing renamed macros and snarfing script along with
the applications.  Perhaps this was overkill.  

Steve

--
Steve Tell  tell@telltronics.org 



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: problem becouse scm_tc7_contin is not defined

[Rob Browning]

Steve Tell <tell@telltronics.org> writes:

> _Are_ there any scwm developers any more?

I believe Pieter is working on working on the update scwm to 1.6.0.

> Or am I looking in the wrong place?  I was thinking of abandoning scwm
> myself, perhaps I don't have to if work is continuing and there is a 
> new version that at least works with guile-1.4?

If he keeps up, sounds like 1.6.0 will be the next supported version.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: problem becouse scm_tc7_contin is not defined

[Marius Vollmer]

Steve Tell <tell@telltronics.org> writes:

> On foo.doc/foo.x snarfing, I concluded that it was hard to support both
> guile-1.4 and guile-1.6 while using guile's provided guile-snarf and
> supplied macros,

Hmm, is that still the case with the guile-snarf that is in Guile
1.6.0?  Some of the pretests had versions of guile-snarf that were
significantly incompatible with that from 1.4.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

1.4 vs. 1.5.x vs 1.6 snarfingdefined

[Steve Tell]

On 16 Sep 2002, Marius Vollmer wrote:

> Steve Tell <tell@telltronics.org> writes:
> 
> > On foo.doc/foo.x snarfing, I concluded that it was hard to support both
> > guile-1.4 and guile-1.6 while using guile's provided guile-snarf and
> > supplied macros,
> 
> Hmm, is that still the case with the guile-snarf that is in Guile
> 1.6.0?  Some of the pretests had versions of guile-snarf that were
> significantly incompatible with that from 1.4.

Guilty as charged - I ran into this problem with 1.5.4-1.5.6, and
(mistakenly) assumed that anything that had changed from 1.4 in those
would stay changed in 1.6.  I've not actually tried 1.6 yet, but the
snarfing does look much closer to 1.4.

Steve

--
Steve Tell  tell@telltronics.org 




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user