Initialization of load_path at startup

[John Swensen]

I am having a strange problem with the load_path while working on  
OctaveDE.  Below I have listed the results of the path() command just  
after startup.  I have been searching for how the load_path is  
initialized at startup and cannot figure out how in the world that  
extra line is getting injected when I start up octave_main from  
OctaveDE, and it is not happening when simply running octave.


First 3 lines of output of path() command in Octave when executed from  
Octave.app
.
/Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
/Applications/Octave.app/Contents/Resources/libexec/octave/3.0.1/oct/
i386-apple-darwin8.9.1


First 3 lines of output of path() command in Octave when running in  
OctaveDE.app
.
./Applications/Octave.app/Contents/Resources/share/octave/site/m
/Applications/Octave.app/Contents/Resources/share/octave/site/m/startup


John Swensen

[Kim Hansen-5]

On Wed, May 14, 2008 at 2:02 PM, John Swensen <jpswensen@...> wrote:

> I am having a strange problem with the load_path while working on OctaveDE.
>  Below I have listed the results of the path() command just after startup.
>  I have been searching for how the load_path is initialized at startup and
> cannot figure out how in the world that extra line is getting injected when
> I start up octave_main from OctaveDE, and it is not happening when simply
> running octave.
>
>
> First 3 lines of output of path() command in Octave when executed from
> Octave.app
> .
> /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
> /Applications/Octave.app/Contents/Resources/libexec/octave/3.0.1/oct/i386-apple-darwin8.9.1
>
>
> First 3 lines of output of path() command in Octave when running in
> OctaveDE.app
> .
> ./Applications/Octave.app/Contents/Resources/share/octave/site/m
> /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup

I think this is the same bug as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477556, and I also
think I have found a solution, patch is attached.

I am not really sure why we start with "." in the xpath variable, as
"." always is in path, I have just tried to fix the bug without
creating a new one.

--
Kim Hansen
Vadgårdsvej 3, 2.tv
2860 Søborg
Fastnet: 3956 2437 -- Mobil: 3091 2437

[sys_path.patch]

---

diff --git a/src/load-path.cc b/src/load-path.cc
--- a/src/load-path.cc
+++ b/src/load-path.cc
@@ -444,7 +444,7 @@
     xpath += dir_path::path_sep_str + tpath;
 
   if (! sys_path.empty ())
-    xpath += sys_path;
+    xpath += dir_path::path_sep_str + sys_path;
 
   do_set (xpath, false);
 }

---

[John Swensen]

On May 14, 2008, at 10:52 AM, Kim Hansen wrote:

> On Wed, May 14, 2008 at 2:02 PM, John Swensen  
> <jpswensen@...> wrote:
>> I am having a strange problem with the load_path while working on  
>> OctaveDE.
>> Below I have listed the results of the path() command just after  
>> startup.
>> I have been searching for how the load_path is initialized at  
>> startup and
>> cannot figure out how in the world that extra line is getting  
>> injected when
>> I start up octave_main from OctaveDE, and it is not happening when  
>> simply
>> running octave.
>>
>>
>> First 3 lines of output of path() command in Octave when executed  
>> from
>> Octave.app
>> .
>> /Applications/Octave.app/Contents/Resources/share/octave/site/m/
>> startup
>> /Applications/Octave.app/Contents/Resources/libexec/octave/3.0.1/
>> oct/i386-apple-darwin8.9.1
>>
>>
>> First 3 lines of output of path() command in Octave when running in
>> OctaveDE.app
>> .
>> ./Applications/Octave.app/Contents/Resources/share/octave/site/m
>> /Applications/Octave.app/Contents/Resources/share/octave/site/m/
>> startup
>
> I think this is the same bug as
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477556, and I also
> think I have found a solution, patch is attached.
>
> I am not really sure why we start with "." in the xpath variable, as
> "." always is in path, I have just tried to fix the bug without
> creating a new one.
>
> --
> Kim Hansen
> Vadgårdsvej 3, 2.tv
> 2860 Søborg
> Fastnet: 3956 2437 -- Mobil: 3091 2437
> <sys_path.patch>

Yes, I think that would fix it, although I found another solution.  As  
long as I start executing OctaveDE.app while in the directory /
Applications/Octave.app/Contents/Resource then things work fine.  I  
don't quite get this, but since I change the directory after Octave  
starts up anyway, it is an acceptable solution for me (and I don't  
have to rebuild Octave.app).

John

[Thomas Weber-8]

Am Mittwoch, den 14.05.2008, 16:52 +0200 schrieb Kim Hansen:

> On Wed, May 14, 2008 at 2:02 PM, John Swensen <jpswensen@...> wrote:
> > I am having a strange problem with the load_path while working on OctaveDE.
> >  Below I have listed the results of the path() command just after startup.
> >  I have been searching for how the load_path is initialized at startup and
> > cannot figure out how in the world that extra line is getting injected when
> > I start up octave_main from OctaveDE, and it is not happening when simply
> > running octave.
> >
> >
> > First 3 lines of output of path() command in Octave when executed from
> > Octave.app
> > .
> > /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
> > /Applications/Octave.app/Contents/Resources/libexec/octave/3.0.1/oct/i386-apple-darwin8.9.1
> >
> >
> > First 3 lines of output of path() command in Octave when running in
> > OctaveDE.app
> > .
> > ./Applications/Octave.app/Contents/Resources/share/octave/site/m
> > /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
>
> I think this is the same bug as
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477556, and I also
> think I have found a solution, patch is attached.
>
> I am not really sure why we start with "." in the xpath variable, as
> "." always is in path, I have just tried to fix the bug without
> creating a new one.

I confirm this fixes the bug in Debian. John, can you comment on the
patch?

        Thomas

[John W. Eaton]

On 14-May-2008, Kim Hansen wrote:

| On Wed, May 14, 2008 at 2:02 PM, John Swensen <jpswensen@...> wrote:
| > I am having a strange problem with the load_path while working on OctaveDE.
| >  Below I have listed the results of the path() command just after startup.
| >  I have been searching for how the load_path is initialized at startup and
| > cannot figure out how in the world that extra line is getting injected when
| > I start up octave_main from OctaveDE, and it is not happening when simply
| > running octave.
| >
| >
| > First 3 lines of output of path() command in Octave when executed from
| > Octave.app
| > .
| > /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
| > /Applications/Octave.app/Contents/Resources/libexec/octave/3.0.1/oct/i386-apple-darwin8.9.1
| >
| >
| > First 3 lines of output of path() command in Octave when running in
| > OctaveDE.app
| > .
| > ./Applications/Octave.app/Contents/Resources/share/octave/site/m
| > /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
|
| I think this is the same bug as
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477556, and I also
| think I have found a solution, patch is attached.

I applied this change.

Instead of sending bare diffs, it would help me if you can commit the
changes to your local hg archive, then export the changeset with "hg
export".

| I am not really sure why we start with "." in the xpath variable, as
| "." always is in path, I have just tried to fix the bug without
| creating a new one.

The idea was that there would be no special code to look for files in
the current directory, so "." must be in the internal list of
directories in the path.  The code that manipulates the path should
ensure that "." remains first in the path.  So "." has to be added
to the path somewhere.  Doesn't it make sense to start with that in
the intialization code?

Thanks,

jwe

[Kim Hansen-5]

On Tue, May 20, 2008 at 10:51 PM, John W. Eaton <jwe@...> wrote:

> On 14-May-2008, Kim Hansen wrote:
>
> | On Wed, May 14, 2008 at 2:02 PM, John Swensen <jpswensen@...> wrote:
> | > I am having a strange problem with the load_path while working on OctaveDE.
> | >  Below I have listed the results of the path() command just after startup.
> | >  I have been searching for how the load_path is initialized at startup and
> | > cannot figure out how in the world that extra line is getting injected when
> | > I start up octave_main from OctaveDE, and it is not happening when simply
> | > running octave.
> | >
> | >
> | > First 3 lines of output of path() command in Octave when executed from
> | > Octave.app
> | > .
> | > /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
> | > /Applications/Octave.app/Contents/Resources/libexec/octave/3.0.1/oct/i386-apple-darwin8.9.1
> | >
> | >
> | > First 3 lines of output of path() command in Octave when running in
> | > OctaveDE.app
> | > .
> | > ./Applications/Octave.app/Contents/Resources/share/octave/site/m
> | > /Applications/Octave.app/Contents/Resources/share/octave/site/m/startup
> |
> | I think this is the same bug as
> | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477556, and I also
> | think I have found a solution, patch is attached.
>
> I applied this change.
>
> Instead of sending bare diffs, it would help me if you can commit the
> changes to your local hg archive, then export the changeset with "hg
> export".

I will try to remember that. What about the changelog entry, do you
still want that in the email or should it be part of the changeset?

>
> | I am not really sure why we start with "." in the xpath variable, as
> | "." always is in path, I have just tried to fix the bug without
> | creating a new one.
>
> The idea was that there would be no special code to look for files in
> the current directory, so "." must be in the internal list of
> directories in the path.  The code that manipulates the path should
> ensure that "." remains first in the path.  So "." has to be added
> to the path somewhere.  Doesn't it make sense to start with that in
> the intialization code?

I expected it to be something like that, but then I was confused by
the fact that "." still was in the path even when the bug prevented it
from being added in the initialization.

--
Kim Hansen
Vadgårdsvej 3, 2.tv
2860 Søborg
Fastnet: 3956 2437 -- Mobil: 3091 2437

[John W. Eaton]

On 21-May-2008, Kim Hansen wrote:

| What about the changelog entry, do you
| still want that in the email or should it be part of the changeset?

For now, it should be part of the changset, but I'm rethinking whether
we should continue to maintain ChangeLog files at all since they
almost always require some work to merge, either because of a conflict
or because they are inserted in the wrong spot with the wrong date.

jwe

[Jaroslav Hajek-2]

John,

what version of Mercurial do you use? I've just imported an older
patch (the matrix_type improvement) and the ChangeLogs were merged
smoothly. The entry is even included at an appropriate place (i.e. the
dates are sorted). I think I haven't had problems with this since I've
upgraded to Mercurial 1.0. Perhaps ChangeLogs are treated specially
now.


On Wed, May 21, 2008 at 12:29 PM, John W. Eaton <jwe@...> wrote:

> On 21-May-2008, Kim Hansen wrote:
>
> | What about the changelog entry, do you
> | still want that in the email or should it be part of the changeset?
>
> For now, it should be part of the changset, but I'm rethinking whether
> we should continue to maintain ChangeLog files at all since they
> almost always require some work to merge, either because of a conflict
> or because they are inserted in the wrong spot with the wrong date.
>
> jwe
>

--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[John W. Eaton]

On 21-May-2008, Jaroslav Hajek wrote:

| what version of Mercurial do you use? I've just imported an older
| patch (the matrix_type improvement) and the ChangeLogs were merged
| smoothly. The entry is even included at an appropriate place (i.e. the
| dates are sorted). I think I haven't had problems with this since I've
| upgraded to Mercurial 1.0. Perhaps ChangeLogs are treated specially
| now.

But that's not what I'd like to happen when I include changes.  I
think the ChangeLog should reflect when the changes were made to my
sources.  I've been importing changes with Mercruial Queues so that I
can fix up conflicts in a merge before committing changes to the
archive, or merge several changesets into one, etc.  That way, the
revision history in the public archive is clean, not a spaghetti mess.
The only thing that is a constant hassle in this way of working is
dealing with ChangeLog files.  So, I'm trying to decide what is the
best way of working here.

jwe