octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Forge] IO still gives error


From: PhilipNienhuis
Subject: Re: [Forge] IO still gives error
Date: Tue, 7 Jan 2014 08:44:17 -0800 (PST)

Juan Pablo Carbajal-2 wrote
> On Tue, Jan 7, 2014 at 3:27 PM, PhilipNienhuis <

> pr.nienhuis@

> > wrote:
>> Juan, could you please try to increase the delay in PKG_ADD and see if
>> the
>> problem disappears?
> 
> No, it doesn't. At least with delays of 25 seconds each. According to
> Carnë's explanation, the timing wont solve the problem. Is there
> anyway of installing the package without calling one of its functions
> and then in post_install call the rest of it?

The easiest short-term fix would be to throw out PKG_ADD entirely.

Some explanation:

PKG_ADD invokes chk_spreadsheet_support so that Java class libs are added to
the javaclasspath only when they are needed, that is: at io package load
time.
If the relevant chk_spreadsheet_support statements were included in e.g.,
.octaverc, the class libs would always be loaded when Octave starts. I don't
think that is a Good Thing.

It is a bit unfortunate that PKG_ADD can be called before an OF package is
fully loaded, or more precise (after Carnë): before the path to the scripts
has been added to Octave's search path.
Apparently PKG_ADD was designed with "external" dependencies in mind rather
than "internal"; that is, I can imagine that external "dependencies" (like
having libs or executables in the search paths) have to be set up before
some OF package can be loaded, or used. But in case of io it is more like an
"internal" dependency (i.e., its own script subdir).

The best fix is to move PKG_ADD from
lib/octave/packages/io-<VERSION>/<ARCH>/ to the io subdir in
share/octave/packages/io-<VERSION>/packinfo. (I had that setup a while ago
(by manually moving PKG_ADD) and that has been working OK.)  For packages
with only scripts (no compiled functions) PKG_ADD lives in the
share/.../packinfo subdir.
Moving PKG_ADD can undoubtedly be done at install time but it requires a bit
of sorting out using various octave_config_info fields and implementing it
again in post_install.m. It should also be made robust so that install
errors (missing write permissions etc.) are catched and users are politely
informed.

Being there, it would be neat to add another fix, namely to have a PKG_DEL
mirroring PKG_ADD's actions (i.e., removing the Java class libs from the
javaclasspath). That part of the equation was never there as the required
Java package call (javarmpath) was only implemented long after Nitzan
created the post_install.m
Such a PKG_DEL isn't so easy however - for a start it would require almost
half of the code of chk_spreadsheet_support.m, maybe in a dedicated script,
and be careful to not touch other Java class libs. Complications are that
some spreadsheet support class libs may be required for other Java
applications (e.g., XML parsers or so) so there's some minefield looming...
Can PKG_DEL call functions in private/ subdirs?
But OK this PKG_DEL part probably has a low priority.

Anyway, I can only look into it (install & load issues) tomorrow night at
the earliest - perhaps someone beats me to it.

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Forge-IO-still-gives-error-tp4660735p4660750.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]