slsh's require breaks jed-extra

[Jörg Sommer]

Hi John,

John E. Davis schrieb am Thu 07. Jun, 12:20 (-0400):
> On Thu, 7 Jun 2007 16:54:44 +0200, Jörg Sommer <joerg at alea.gnuu.de> said:
> >Even if we can fix this, there is another problem: require from slsh
> >doesn't care about jed_load_path. While jed-extra uses jed_load_path
> >everywhere=E2=80=94it breaks a second time.
> 
>   Jed uses an evalfile hook that slang calls when files are loaded.
> It is here where jed's load path is used.  So, require does know about
> this path, and if not, there is something wrong.  Do you have an
> example where this fails?

The problem is, that the additional paths for jed-extra are registered
with set_jed_library_path(). Than a require for such a file failed,
because it only searched the slang_load_path.

For the first moment I've changed every jed_library_path into
slang_load_path, but than evalfile failed, because it searches files in
jed_library_path.

> >But I think we should make an advantage out of this situation and should
> >remove jed_library_path. IIRC, this is a long standing task. Right, John?
> 
> It is on the TODO list-- perhaps I can work it into the next svn
> checkin.

This would be great! Or if you can, at least, look over the changes in
the C files.

> But that should not affect require.

Yes, but this is not a big problem. I found only one piece of code that
causes trouble

require("file", "/path/to/file")

But that's a Debian specific file.

The problem is the path. We must keep the slang_load_path and the
jed_library_path in sync, everywhere, because require need
slang_load_path and evalfile need jed_library_path.

> >BTW: John, there's a bug in SLpath_get_load_path. If SLpath_set_load_path
> >was not called before the path is NULL and SLang_create_slstring is
> >called with NULL.
> 
> I don't regard that as a bug.  SLpath_get_load_path returns the value
> of the load path, and if it has not been set, the value is NULL.

But I've got a segmentation fault. … But wait, I've passed this value to
??_concat_??. There was the segmentation fault. Okay, everything's fine.
Sorry for the worry.

Bye, Jörg.
-- 
Wir leben zwar unter dem gleichen Himmel,
müssen aber nicht zwangsläufig den gleichen Horizont haben.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20070607/f34c8770/attachment.pgp