problems with upgrade to 0.99.19 (was Re: More patches)

["G. Milde" <milde@xxxxxxxxxxxxxxxxxxxxx>]

Dear jed-users,

please excuse if many parts of this thread are specific to issues for Jed
on Debian. As the underlying problem of the switch from Jed's own
require() function to the one of slsh with 0.99.19 may affect other Jed
users as well, it is continued here.

On 26.05.08, J�rg Sommer wrote:
> "G. Milde" <milde@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > On 25.05.08, J�rg Sommer wrote:
> >> "G. Milde" <milde@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >> > On 20.05.08, J�rg Sommer wrote:

> The bug is at your site. 

Actually, I do not own a site...

> You should really not use these ugly variables $1, $2, ….

+ It's common practice in standard Jed scripts as it is meant to be most
  ressource friendly, but

- care must be taken that no interference with other code using these
  variables occures.

> With this patch

   $1 = "/usr/share/jed/jed-extra/";
   $2 = path_concat($1, "libdir.slc");

> +() = fprintf(stderr, "$1\n"$);
>  () = evalfile($2);
> +() = fprintf(stderr, "$1\n"$);

> I get:

> % xjed -f 'exit(0)'
> /usr/share/jed/jed-extra/
> /usr/share/slsh/help/require.hlp

I see: "provide" is autoloaded from slsh/require.sl in Jed 0.99.19 which
contains::

  $1 = path_concat (path_dirname (__FILE__), "help/require.hlp");
  if (NULL != stat_file ($1))
    add_doc_file ($1);

Conclusion: even if you know an evaluated file does not use any $n
variables, evalfile() should be considered a "unsafe" operation regarding
the reliability of $n variables.

I'll fix the code in jed-extra's SVN trunk.

..........................................................................

> >> I've added this patch and now the test exits with the return value 20.
> > Which means that there are still 20 errors in the test. Could you mail me
> > the generated testreport.txt?

> 2008-05-25 16:46 Jed 0.99.19-138 (utf8), S-Lang 2.1.3, Emulation 'emacs'
> test_files in '/usr/share/jed/jed-extra/tests' matching '^[^.].*\.sl$': testing 20 files|dirs 
>  ch_table-test.sl: 
>   E: 'Open failed' Unable to load /usr/share/jed/jed-extra/unittest.slc in require() /usr/share/slsh/require.sl
>  csvutils-test.sl: 
...
> and so on.


It looks like since 0.99.19 the construct 

  -l extra/unittest.sl

corresponding to 

  () = evalfile("extra/unittest.sl");
  
does no longer work with the load path

  /usr/share/jed/lib,/usr/share/jed/jed-extra/
  
and "unittest.sl" in   

  /usr/share/jed/jed-extra/extra/unittest.sl

while until now, e.g.

  () = evalfile("colors/black2.sl");
  
loads
  
  /usr/share/jed/lib/colors/black2.sl

.


> With this patch, 
...
> -LANG=en_US; jed -n -l extra/unittest.sl -f $TESTFUN
> +LANG=en_US; jed -batch -n -l extra/unittest.sl -f $TESTFUN

> I get the following output:

> % sh do-unittests.sh
> loading /usr/share/jed/lib/site.slc
...
> loading /etc/jed.d/50local.sl

what is in your 50local.sl?

> loading /usr/share/jed/jed-extra/extra/unittest.sl

Do you have any idea why it loads from jed-extra/extra/ now?
How could the setting of -batch influence this?

> Unable to typecast Null_Type to String_Type
> Traceback: Sprintf
...

I could localize this one in 

  /usr/share/jed/jed-extra/extra/unittest.sl:465

and fix it using %S instead of %s to report the _Jed_Emulation.


Back to the loading of unittest.sl:

> Patch:
> --- /tmp/ch_table-test.sl       2008-05-26 12:56:13.557827573 +0200
> +++ /usr/share/jed/jed-extra/tests/ch_table-test.sl     2008-05-26 12:57:47.000000000 +0200
> @@ -11,7 +11,7 @@
> -require("unittest");
> +require("unittest", "Global");

Unfortunately, this patch is not compatible with 
  require (String_Type feature [,String_Type file]
in Jed 0.99.18.

Mystery: Why can one such change solve the loading problem for all
20 occurences of require("unittest"); in tests/*.sl?

Could it be that a provided feature is only registerd if a script is
loaded using the new require()?

unittest.sl announces itself with ``provide("unittest");`` so the feature
is known to Jed after ``-l extra/unittest.sl`` on the command line in jed
0.99.18.


> New output:
> loading /usr/share/jed/jed-extra/utils/bufutils.slc
>    E: 'Duplicate Definition' close_buffer already has static or private linkage in this unit in <top-level>() /

>   1 error
>   csvutils-test.sl: 
> loading /usr/share/jed/jed-extra/tests/csvutils-test.sl

So it seems like the default namespace for loading with require() has
changed as well :-(

Thanks
Guenter


--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.