Octave 2.9.13, Windows: path information stored by savepath cannot be loaded on subsequent octave start

[Peter G.]

Configuration:

Windows XP, Version from Octave-Forge, JHandle graphics, Java 1.6u2,
General CPU libraries.

Description:
Path information stored


Steps to reproduce:

1) Open octave
2) Type "savepath();"
3) Close octave
4) Open it again.

One should be able to observe that path information stored in
.octaverc file cannot be loaded, here is only a part of octave screen
output:

warning: unrecognized escape sequence `\2' -- converting to `2'
warning: unrecognized escape sequence `\m' -- converting to `m'
warning: unrecognized escape sequence `\P' -- converting to `P'
warning: unrecognized escape sequence `\O' -- converting to `O'
warning: unrecognized escape sequence `\s' -- converting to `s'
warning: unrecognized escape sequence `\o' -- converting to `o'
warning: addpath: C:Program FilesOctaveshareoctavepackagesjhandles-0.2.0: No suc
h file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackageswindows-1.0.1i686-pc-m
sdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackageswindows-1.0.1: No such
 file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackages      ime-1.0.1: No su
ch file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagessymbolic-1.0.2i686-pc-
msdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagessymbolic-1.0.2: No suc
h file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesstruct-1.0.1: No such
file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesstrings-1.0.1i686-pc-m
sdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesstrings-1.0.1: No such
 file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesstatistics-1.0.2: No s
uch file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagessplines-1.0.1: No such
 file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesspecial-matrix-1.0.1:
No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesspecfun-1.0.2i686-pc-m
sdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesspecfun-1.0.2: No such
 file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagessockets-1.0.1i686-pc-m
sdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagessockets-1.0.1: No such
 file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagespolynomial-1.0.1: No s
uch file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesplot-1.0.1: No such fi
le or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesphysicalconstants-0.1.
1: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesoutliers-0.13.3: No su
ch file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesoptim-1.0.0i686-pc-msd
osmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesoptim-1.0.0: No such f
ile or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesodepkg-0.3.1i686-pc-ms
dosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesodepkg-0.3.1: No such
file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesodebvp-1.0.0: No such
file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesoctcdf-1.0.5i686-pc-ms
dosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesoctcdf-1.0.5: No such
file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesmiscellaneous-1.0.2i68
6-pc-msdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesmiscellaneous-1.0.2: N
o such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackageslinear-algebra-1.0.1i6
86-pc-msdosmsvc-api-v25: No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackageslinear-algebra-1.0.1:
No such file or directory
warning: addpath: C:Program FilesOctaveshareoctavepackagesjava-1.2.0i686-pc-msdo
smsvc-api-v25: No such file or directory

5) After deleting ~/.octaverc file everything works just fine as
octave reads path information from some other place.

Peter

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On  7-Aug-2007, Gagarinov Peter wrote:

| Configuration:
|
| Windows XP, Version from Octave-Forge, JHandle graphics, Java 1.6u2,
| General CPU libraries.
|
| Description:
| Path information stored
|
|
| Steps to reproduce:
|
| 1) Open octave
| 2) Type "savepath();"
| 3) Close octave
| 4) Open it again.
|
| One should be able to observe that path information stored in
| .octaverc file cannot be loaded, here is only a part of octave screen
| output:
|
| warning: unrecognized escape sequence `\2' -- converting to `2'

Please try the following patch.

Thanks,

jwe



scripts/ChangeLog:

2007-08-07  John W. Eaton  <jwe@...>

        * path/savepath.m: Use single quotes for argument to PATH command
        that is inserted in file.


Index: scripts/path/savepath.m
===================================================================
RCS file: /cvs/octave/scripts/path/savepath.m,v
retrieving revision 1.8
diff -u -u -r1.8 savepath.m
--- scripts/path/savepath.m 23 Mar 2007 15:13:19 -0000 1.8
+++ scripts/path/savepath.m 7 Aug 2007 13:55:20 -0000
@@ -108,7 +108,9 @@
     fprintf (fid, "%s\n", pre{i})
   endfor
 
-  fprintf (fid, "%s\n  path (\"%s\");\n%s\n",
+  ## Use single quotes for PATH argument to avoid string escape
+  ## processing.
+  fprintf (fid, "%s\n  path ('%s');\n%s\n",
    beginstring, path (), endstring);
 
   for i = 1:length (post)

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Peter G.]

Thanks, it resolved the problem but seems to cause another one:

Description:
Octave crashes during execution of "exit" command.
Steps to reproduce:
1) open octave
2) type 'savepath()';
3) exit octave
4) open octave
5) set log file by typing "diary('octave.log');
6) type 'exit'

Now octave.log contains the following:

octave-2.9.13.exe:5> exit
error: unable to start Java VM in C:\Program Files\Java\jre1.6.0_02\bin\client\jvm.dll
error: evaluating assignment expression near line 20, column 7
error: called from `__get_object__' in file `C:\Program Files\Octave\share\octave\packages\jhandles-0.2.0\__get_object__.m'
error: evaluating assignment expression near line 24, column 12
error: called from `__jhandles_get' in file `C:\Program Files\Octave\share\octave\packages\jhandles-0.2.0\__jhandles_get.m'
error: evaluating assignment expression near line 72, column 25
error: evaluating argument list element number 1
error: evaluating prefix operator `!' near line 72, column 10
error: while: error evaluating conditional expression
error: called from `close:close_all_figures' in file `C:\Program Files\Octave\share\octave\2.9.13\m\plot\close.m'
error: evaluating if command near line 44, column 5
error: evaluating if command near line 36, column 3
error: called from `close' in file `C:\Program Files\Octave\share\octave\2.9.13\m\plot\close.m'
error: called from `__jhandles_exit' in file `C:\Program Files\Octave\share\octave\packages\jhandles-0.2.0\__jhandles_exit.m'
error: unable to start Java VM in C:\Program Files\Java\jre1.6.0_02\bin\client\jvm.dll
error: evaluating assignment expression near line 20, column 7
error: called from `__get_object__' in file `C:\Program Files\Octave\share\octave\packages\jhandles-0.2.0\__get_object__.m'
error: evaluating assignment expression near line 24, column 12
error: called from `__jhandles_get' in file `C:\Program Files\Octave\share\octave\packages\jhandles-0.2.0\__jhandles_get.m'
error: evaluating assignment expression near line 72, column 25
error: evaluating argument list element number 1
error: evaluating prefix operator `!' near line 72, column 10
error: while: error evaluating conditional expression
error: called from `close:close_all_figures' in file `C:\Program Files\Octave\share\octave\2.9.13\m\plot\close.m'
error: evaluating if command near line 44, column 5
error: evaluating if command near line 36, column 3
error: called from `close' in file `C:\Program Files\Octave\share\octave\2.9.13\m\plot\close.m'
error: called from `__jhandles_exit' in file `C:\Program Files\Octave\share\octave\packages\jhandles-0.2.0\__jhandles_exit.m'

John W. Eaton wrote:

On  7-Aug-2007, Gagarinov Peter wrote:

| Configuration:
|
| Windows XP, Version from Octave-Forge, JHandle graphics, Java 1.6u2,
| General CPU libraries.
|
| Description:
| Path information stored
|
|
| Steps to reproduce:
|
| 1) Open octave
| 2) Type "savepath();"
| 3) Close octave
| 4) Open it again.
|
| One should be able to observe that path information stored in
| .octaverc file cannot be loaded, here is only a part of octave screen
| output:
|
| warning: unrecognized escape sequence `\2' -- converting to `2'

Please try the following patch.

Thanks,

jwe



scripts/ChangeLog:

2007-08-07  John W. Eaton  <[e-mail]>

        * path/savepath.m: Use single quotes for argument to PATH command
        that is inserted in file.


Index: scripts/path/savepath.m
===================================================================
RCS file: /cvs/octave/scripts/path/savepath.m,v
retrieving revision 1.8
diff -u -u -r1.8 savepath.m
--- scripts/path/savepath.m 23 Mar 2007 15:13:19 -0000 1.8
+++ scripts/path/savepath.m 7 Aug 2007 13:55:20 -0000
@@ -108,7 +108,9 @@
     fprintf (fid, "%s\n", pre{i})
   endfor
 
-  fprintf (fid, "%s\n  path (\"%s\");\n%s\n",
+  ## Use single quotes for PATH argument to avoid string escape
+  ## processing.
+  fprintf (fid, "%s\n  path ('%s');\n%s\n",
    beginstring, path (), endstring);
 
   for i = 1:length (post)

_______________________________________________
Bug-octave mailing list
[e-mail]
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On  7-Aug-2007, Peter G. wrote:

|
| Thanks, it resolved the problem but seems to cause another one:
|
| Description:
| Octave crashes during execution of "exit" command.
| Steps to reproduce:
| 1) open octave
| 2) type 'savepath()';
| 3) exit octave
| 4) open octave
| 5) set log file by typing "diary('octave.log');
| 6) type 'exit'

I can't reproduce this crash on my system (Debian) so I suspect it is
specific to the Windows build, perhaps related to the Java extension
since you are seeing errors with that.  Someone else will have to
debug it.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/7/07, John W. Eaton <jwe@...> wrote:

> On  7-Aug-2007, Peter G. wrote:
>
> |
> | Thanks, it resolved the problem but seems to cause another one:
> |
> | Description:
> | Octave crashes during execution of "exit" command.
> | Steps to reproduce:
> | 1) open octave
> | 2) type 'savepath()';
> | 3) exit octave
> | 4) open octave
> | 5) set log file by typing "diary('octave.log');
> | 6) type 'exit'
>
> I can't reproduce this crash on my system (Debian) so I suspect it is
> specific to the Windows build, perhaps related to the Java extension
> since you are seeing errors with that.  Someone else will have to
> debug it.

The problem is that using savepath changes the order of the registered
exit hooks. Normally, the java package is loaded before the jhandles
package; hence the java exit hook is executed after the jhandles exit
hook (which simply close all windows).
When using savepath, the order of execution of exit hooks is reversed,
such that the JVM is already terminated (due to the java exit hook)
when the jhandles exit hook execute. My code should be able to handle
that (by restarting the JVM), however it appears that it's not possible to
start the JVM a second time within the same process. This is the error
that you see.

Unfortunately, I'm not sure how to tackle this...

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On  9-Aug-2007, Michael Goffioul wrote:

| The problem is that using savepath changes the order of the registered
| exit hooks.

Which "exit hooks" do you mean, and how is the order changed?

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/9/07, John W. Eaton <jwe@...> wrote:
> On  9-Aug-2007, Michael Goffioul wrote:
>
> | The problem is that using savepath changes the order of the registered
> | exit hooks.
>
> Which "exit hooks" do you mean, and how is the order changed?

Those registered by "atexit". The java package registers "java_exit" (which
terminates the JVM) and the jhandles package registers "__jhandles_exit"
(which closes all figures; this is required otherwise the JVM will
hang at exit).

When package loading is done through the package manager, the java package
is loaded before jhandles. As paths are prepended by default, jhandles path
appears before java path in the octave load path. As exit hooks are executed in
a LIFO way, the jhandles exit hook will execute before the java exit hook.

Now when you use savepath, the load path is restored in the correct way.
However, the PKG_ADD scripts are sourced in the order of path appearance
(PKG_ADD are usually responsible for registering the exit hooks). As jhandles
path appear first (see above), its exit hook is registered first, hence executed
last. So, compared to the situation where the pkg manager loads the packages,
the exit hooks are reversed. And in the case of java/jhandles, this is
a problem,
because:
1) either you have some figure open and the java exit hook hangs
2) or you don't have any figure and the java exit hook terminates the JVM;
afterwards the jhandles exit hook tries to restart the JVM, but apparently this
is not possible within the same process.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Michael Goffioul wrote:

> On 8/9/07, John W. Eaton <jwe@...> wrote:
>  
>> On  9-Aug-2007, Michael Goffioul wrote:
>>
>> | The problem is that using savepath changes the order of the registered
>> | exit hooks.
>>
>> Which "exit hooks" do you mean, and how is the order changed?
>>    
>
> Those registered by "atexit". The java package registers "java_exit" (which
> terminates the JVM) and the jhandles package registers "__jhandles_exit"
> (which closes all figures; this is required otherwise the JVM will
> hang at exit).
>
> When package loading is done through the package manager, the java package
> is loaded before jhandles. As paths are prepended by default, jhandles path
> appears before java path in the octave load path. As exit hooks are executed in
> a LIFO way, the jhandles exit hook will execute before the java exit hook.
>
> Now when you use savepath, the load path is restored in the correct way.
> However, the PKG_ADD scripts are sourced in the order of path appearance
> (PKG_ADD are usually responsible for registering the exit hooks). As jhandles
> path appear first (see above), its exit hook is registered first, hence executed
> last. So, compared to the situation where the pkg manager loads the packages,
> the exit hooks are reversed. And in the case of java/jhandles, this is
> a problem,
> because:
> 1) either you have some figure open and the java exit hook hangs
> 2) or you don't have any figure and the java exit hook terminates the JVM;
> afterwards the jhandles exit hook tries to restart the JVM, but apparently this
> is not possible within the same process.
>
> Michael.
>  

I see no sensible way of fixing this within Octave itself, as its a
combination of path order, PKG_ADD files and the LIFO manner of calling
the atexit commands... Changing atexit to be FIFO wouldn't help at all..
We might modify the savepath command so that it ignores adding packages
installed by "pkg", and lets "pkg" do that itself, though that isn't
attractive as its not what Matlab does. Apart from that I see nothing
that can be done..

Any solution to this issue must ensure that

* Packages loaded by pkg are installed before the default Octave files,
otherwise packages like NaN that overload existing Octave functions
won't work

* The PKG_ADD files of the java package is run before the jhandles package

* The java package is installed before the jhandles package

The possible solutions that meet these conditions are

1) Have the PKG_ADD/PKG_DEL code in Octave scan the path in reverse
order, with the assumption that most PKG_ADD files aren't interdependent
like java/jhandles ones are, and those that are, are handled by pkg.

2) In pkg allow a mechanism to state whether a package should be after
certain packages in the path, and use this feature with jhandles to
force its position in the path to be after the java package but before
Octave's inbuilt plot functions.

3) Modify the PKG_ADD files of java/jhandles to take into account this
mess..

Which solution is the most attractive?

D.




What I might suggest is that the octave-forge java package is modified

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/20/07, David Bateman <David.Bateman@...> wrote:

> The possible solutions that meet these conditions are
>
> 1) Have the PKG_ADD/PKG_DEL code in Octave scan the path in reverse
> order, with the assumption that most PKG_ADD files aren't interdependent
> like java/jhandles ones are, and those that are, are handled by pkg.
>
> 2) In pkg allow a mechanism to state whether a package should be after
> certain packages in the path, and use this feature with jhandles to
> force its position in the path to be after the java package but before
> Octave's inbuilt plot functions.
>
> 3) Modify the PKG_ADD files of java/jhandles to take into account this
> mess..
>
> Which solution is the most attractive?

I can see 2 other solutions:

1) merge the java and jhandles package: I don't think this is a good one;
moreover any other package that relies on java might suffer the same problem

2) handle the jhandles exit hook in the java exit hook directly; this makes sure
that the jhandles exit hook is executed before the JVM terminates. This could
be done through a "java_atexit" function allowing to register exit hooks for
java-dependent packages, like jhandles.

What do you think?

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Michael Goffioul wrote:

> On 8/20/07, David Bateman <David.Bateman@...> wrote:
>  
>> The possible solutions that meet these conditions are
>>
>> 1) Have the PKG_ADD/PKG_DEL code in Octave scan the path in reverse
>> order, with the assumption that most PKG_ADD files aren't interdependent
>> like java/jhandles ones are, and those that are, are handled by pkg.
>>
>> 2) In pkg allow a mechanism to state whether a package should be after
>> certain packages in the path, and use this feature with jhandles to
>> force its position in the path to be after the java package but before
>> Octave's inbuilt plot functions.
>>
>> 3) Modify the PKG_ADD files of java/jhandles to take into account this
>> mess..
>>
>> Which solution is the most attractive?
>>    
>
> I can see 2 other solutions:
>
> 1) merge the java and jhandles package: I don't think this is a good one;
> moreover any other package that relies on java might suffer the same problem
>  

Yuck...

> 2) handle the jhandles exit hook in the java exit hook directly; this makes sure
> that the jhandles exit hook is executed before the JVM terminates. This could
> be done through a "java_atexit" function allowing to register exit hooks for
> java-dependent packages, like jhandles.
>  
This comes down to saying that interdependencies between PKG_ADD/PKG_DEL
files are explicitly not supported (this should be documented
somewhere). I like the idea of adding the possible of a java specific
atexit command and this meets the criteria of no interdependencies
between PKG_ADD files..

However, i still see one problem. If jhandles is first in the path that
is saved with "savepath", the java package won't be loaded at the time
the jhandles PKG_ADD file is run. This might not be a problem in this
case, but I can see that there might be some cases where it would be..

I'd proposed to go this way to avoid the issue..

Regards
David



> What do you think?
>
> Michael.
>
>  


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/20/07, David Bateman <David.Bateman@...> wrote:
> > 2) handle the jhandles exit hook in the java exit hook directly; this makes sure
> > that the jhandles exit hook is executed before the JVM terminates. This could
> > be done through a "java_atexit" function allowing to register exit hooks for
> > java-dependent packages, like jhandles.
> >
> This comes down to saying that interdependencies between PKG_ADD/PKG_DEL
> files are explicitly not supported (this should be documented

Indeed.

> somewhere). I like the idea of adding the possible of a java specific
> atexit command and this meets the criteria of no interdependencies
> between PKG_ADD files..
>
> However, i still see one problem. If jhandles is first in the path that
> is saved with "savepath", the java package won't be loaded at the time
> the jhandles PKG_ADD file is run. This might not be a problem in this
> case, but I can see that there might be some cases where it would be..

It *is* the case. "addpath" prepend paths by default, so jhandles path is
before java path; hence after "savepath", the PKG_ADD of jhandles is
executed first. But apprently, this doesn't lead to any problem... I'll
investigate.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/20/07, Michael Goffioul <michael.goffioul@...> wrote:
> > However, i still see one problem. If jhandles is first in the path that
> > is saved with "savepath", the java package won't be loaded at the time
> > the jhandles PKG_ADD file is run. This might not be a problem in this
> > case, but I can see that there might be some cases where it would be..
>
> It *is* the case. "addpath" prepend paths by default, so jhandles path is
> before java path; hence after "savepath", the PKG_ADD of jhandles is
> executed first. But apprently, this doesn't lead to any problem... I'll
> investigate.

I traced the PKG_ADD execution at startuop, after a savepath (where java
and jhandles packages were loaded through the pkg manager). Here's some
order of execution:

pkg/PKG_ADD
java/PKG_ADD
startup/octaverc
jhandles/PKG_ADD
java/PKG_ADD
pkg/PKG_ADD

The first pkg/PKG_ADD is probably triggered by octave itself (I don't know
exactly). The first java/PKG_ADD is triggered by the package manager, because
the java package is marked autoloaded. This is why the next jhandles/PKG_ADD
does not fail, even though jhandles path is before java path.
The next 3 PKG_ADD are triggered by savepath: PKG_ADD are sourced in the
order of path appearance.

This reveals a few facts:
1) there is some interference between the package manager and savepath
2) PKG_ADD's must be immune to several execution: autoloaded packages will
have their PKG_ADD executed twice.

I'm not sure anymore what's a good solution. Even though I implement
the solution
proposed earlier (with java-specific atexit), java/PKG_ADD must still
be executed
before jhandles/PKG_ADD. It happened to be the case for me, because of the
pkg manager and the fact that the java package is marked as autoloaded.
Turning off the autoload flag of the java package leads to an error at startup.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Michael Goffioul wrote:

> On 8/20/07, Michael Goffioul <michael.goffioul@...> wrote:
>  
>>> However, i still see one problem. If jhandles is first in the path that
>>> is saved with "savepath", the java package won't be loaded at the time
>>> the jhandles PKG_ADD file is run. This might not be a problem in this
>>> case, but I can see that there might be some cases where it would be..
>>>      
>> It *is* the case. "addpath" prepend paths by default, so jhandles path is
>> before java path; hence after "savepath", the PKG_ADD of jhandles is
>> executed first. But apprently, this doesn't lead to any problem... I'll
>> investigate.
>>    
>
> I traced the PKG_ADD execution at startuop, after a savepath (where java
> and jhandles packages were loaded through the pkg manager). Here's some
> order of execution:
>
> pkg/PKG_ADD
> java/PKG_ADD
> startup/octaverc
> jhandles/PKG_ADD
> java/PKG_ADD
> pkg/PKG_ADD
>
> The first pkg/PKG_ADD is probably triggered by octave itself (I don't know
> exactly). The first java/PKG_ADD is triggered by the package manager, because
> the java package is marked autoloaded. This is why the next jhandles/PKG_ADD
> does not fail, even though jhandles path is before java path.
> The next 3 PKG_ADD are triggered by savepath: PKG_ADD are sourced in the
> order of path appearance.
>
> This reveals a few facts:
> 1) there is some interference between the package manager and savepath
> 2) PKG_ADD's must be immune to several execution: autoloaded packages will
> have their PKG_ADD executed twice.
>
> I'm not sure anymore what's a good solution. Even though I implement
> the solution
> proposed earlier (with java-specific atexit), java/PKG_ADD must still
> be executed
> before jhandles/PKG_ADD. It happened to be the case for me, because of the
> pkg manager and the fact that the java package is marked as autoloaded.
> Turning off the autoload flag of the java package leads to an error at startup.
>
> Michael.
>
>  

Ouch.. Ok the issue here is that pkg adds the package to the path again
even with the savepath. The pkg command should be modified to check if
the package is already on the path and if it is no the reload it a
second time.. I'll see about a patch to address the double loading issue..

D.

--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[David Bateman]

Michael Goffioul wrote:

> On 8/20/07, David Bateman <David.Bateman@...> wrote:
>  
>>> 2) handle the jhandles exit hook in the java exit hook directly; this makes sure
>>> that the jhandles exit hook is executed before the JVM terminates. This could
>>> be done through a "java_atexit" function allowing to register exit hooks for
>>> java-dependent packages, like jhandles.
>>>
>>>      
>> This comes down to saying that interdependencies between PKG_ADD/PKG_DEL
>> files are explicitly not supported (this should be documented
>>    
>
> Indeed.
>
>  
>> somewhere). I like the idea of adding the possible of a java specific
>> atexit command and this meets the criteria of no interdependencies
>> between PKG_ADD files..
>>
>> However, i still see one problem. If jhandles is first in the path that
>> is saved with "savepath", the java package won't be loaded at the time
>> the jhandles PKG_ADD file is run. This might not be a problem in this
>> case, but I can see that there might be some cases where it would be..
>>    
>
> It *is* the case. "addpath" prepend paths by default, so jhandles path is
> before java path; hence after "savepath", the PKG_ADD of jhandles is
> executed first. But apprently, this doesn't lead to any problem... I'll
> investigate.
>  

Yes it doesn't lead to problems, which is what I meant. The reason is
that the only commands executed in the java PKG_ADD is the atexit and
autoload commands which have no immediate impact on execution. As long
as the jhandles PKG_ADD file doesn't need the autoloaded functions, then
there is no issue, and apparently it doesn't..

D.


> Michael.
>
>  


--
David Bateman                                David.Bateman@...
Motorola Labs - Paris                        [phone] (Ph)
Parc Les Algorithmes, Commune de St Aubin    [phone] (Mob)
91193 Gif-Sur-Yvette FRANCE                  [phone] (Fax)

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/20/07, David Bateman <David.Bateman@...> wrote:

> > It *is* the case. "addpath" prepend paths by default, so jhandles path is
> > before java path; hence after "savepath", the PKG_ADD of jhandles is
> > executed first. But apprently, this doesn't lead to any problem... I'll
> > investigate.
> >
> Yes it doesn't lead to problems, which is what I meant. The reason is
> that the only commands executed in the java PKG_ADD is the atexit and
> autoload commands which have no immediate impact on execution. As long
> as the jhandles PKG_ADD file doesn't need the autoloaded functions, then
> there is no issue, and apparently it doesn't..

Guess what? In the things I'm working on now, it does.... :-(
Nevertheless, the PKG_ADD of jhandles uses javaaddpath, which is part of
the java package and needs its autoloaded functions.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 20-Aug-2007, Michael Goffioul wrote:

| On 8/20/07, Michael Goffioul <michael.goffioul@...> wrote:
| > > However, i still see one problem. If jhandles is first in the path that
| > > is saved with "savepath", the java package won't be loaded at the time
| > > the jhandles PKG_ADD file is run. This might not be a problem in this
| > > case, but I can see that there might be some cases where it would be..
| >
| > It *is* the case. "addpath" prepend paths by default, so jhandles path is
| > before java path; hence after "savepath", the PKG_ADD of jhandles is
| > executed first. But apprently, this doesn't lead to any problem... I'll
| > investigate.
|
| I traced the PKG_ADD execution at startuop, after a savepath (where java
| and jhandles packages were loaded through the pkg manager). Here's some
| order of execution:
|
| pkg/PKG_ADD
| java/PKG_ADD
| startup/octaverc
| jhandles/PKG_ADD
| java/PKG_ADD
| pkg/PKG_ADD
|
| The first pkg/PKG_ADD is probably triggered by octave itself (I don't know
| exactly).

It happens when the load path is first initialized.

| The first java/PKG_ADD is triggered by the package manager, because
| the java package is marked autoloaded. This is why the next jhandles/PKG_ADD
| does not fail, even though jhandles path is before java path.
| The next 3 PKG_ADD are triggered by savepath: PKG_ADD are sourced in the
| order of path appearance.

I don't see how savepath changes or sets the path, so I don't see how
it would cause a PKG_ADD file to run.

| This reveals a few facts:
| 1) there is some interference between the package manager and savepath
| 2) PKG_ADD's must be immune to several execution: autoloaded packages will
| have their PKG_ADD executed twice.
|
| I'm not sure anymore what's a good solution. Even though I implement
| the solution
| proposed earlier (with java-specific atexit), java/PKG_ADD must still
| be executed
| before jhandles/PKG_ADD. It happened to be the case for me, because of the
| pkg manager and the fact that the java package is marked as autoloaded.
| Turning off the autoload flag of the java package leads to an error at startup.

Are there any changes to Octave that would help solve this problem?
The only thing I can think of is that packages with dependencies like
this must be able to check to see whether prerequisites are installed,
and if they are not, then the dependent patckages must somehow defer
execution of their startup scripts.  I'm not sure how best to do that.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On 8/23/07, John W. Eaton <jwe@...> wrote:
> | The first java/PKG_ADD is triggered by the package manager, because
> | the java package is marked autoloaded. This is why the next jhandles/PKG_ADD
> | does not fail, even though jhandles path is before java path.
> | The next 3 PKG_ADD are triggered by savepath: PKG_ADD are sourced in the
> | order of path appearance.
>
> I don't see how savepath changes or sets the path, so I don't see how
> it would cause a PKG_ADD file to run.

"savepath" puts a "path" call into .octaverc with the complete set of paths.
On the next startup, load_path is first initialized (hence the first call to
pkg/PKG_ADD), then .octaverc is sourced, leading to a call to load_path::set.
This function disable the add_hook (which executes PKG_ADD), then add all
paths, and finally execute the add_hook for all added paths in their order of
appearance. This leads to the last 3 PKG_ADD calls I mentioned in my
previous mail.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[John W. Eaton]

On 24-Aug-2007, Michael Goffioul wrote:

| On 8/23/07, John W. Eaton <jwe@...> wrote:
| > | The first java/PKG_ADD is triggered by the package manager, because
| > | the java package is marked autoloaded. This is why the next jhandles/PKG_ADD
| > | does not fail, even though jhandles path is before java path.
| > | The next 3 PKG_ADD are triggered by savepath: PKG_ADD are sourced in the
| > | order of path appearance.
| >
| > I don't see how savepath changes or sets the path, so I don't see how
| > it would cause a PKG_ADD file to run.
|
| "savepath" puts a "path" call into .octaverc with the complete set of paths.
| On the next startup, load_path is first initialized (hence the first call to
| pkg/PKG_ADD), then .octaverc is sourced, leading to a call to load_path::set.
| This function disable the add_hook (which executes PKG_ADD), then add all
| paths, and finally execute the add_hook for all added paths in their order of
| appearance. This leads to the last 3 PKG_ADD calls I mentioned in my
| previous mail.

OK, I don't see an easy way to avoid this.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave