Tue 10 Nov 2015 04:32:41 PM UTC, comment #12:
I can confirm this now if I run the example in a single Octave session. If I run the commands in one session while another is running, the one that created the scripts doesn't see private/baz, but the one that was idle does.
|
Tue 27 Oct 2015 11:18:38 PM UTC, comment #11:
Hi Pantxo (et al.),
Thanks for the file and config; I have recompiled the development version using your configuration.
I can confirm I'm still getting the same behaviour.
FWIW, I have uploaded a video of the bug here (using the file you provided below):
https://youtu.be/9GJWl_joarI
hopefully that might provide some further insight into what's going on ...
T.
|
Sun 25 Oct 2015 07:47:08 PM UTC, comment #10:
I attached the .m file as requested in comment #8. FWIW my configure options are
so I have debug symbols and bound-check enabled.
(file #35292)
|
Sun 25 Oct 2015 12:49:51 AM UTC, comment #9:
I tried single stepping in debug and also tried pasting 1 line at a time into command window.
I did not get an error
|
Sun 25 Oct 2015 12:00:03 AM UTC, comment #8:
Hi Pantxo.
I am also on Linux Mint 17.2.
Could you post your m-file here to cross-check?
In the process of writing an .m file for you as a testcase, I realised that this issue (bizarrely) does not occur if these commands are run as a script, or as the whole thing copy/pasted onto the terminal. But if you run them one by one on the terminal it will happen.
Did you by any chance perform the console test by simply pasting over the contents of your entire script on the terminal and pressing enter?
Could you try running the commands in my .m file one-by-one (e.g. by pressing F9) and see if you can reproduce the issue?
This is very bizarre ... then again, this wouldn't be the first time you get a different result running commands as a batch compared to individually. (I had a similar experience trying to set figure visibility off/on, as a workaround for the broken shg command - it works if you do this on the console one by one, but just doesn't happen if you run these commands in a script)
T.
(file #35280)
|
Sat 24 Oct 2015 10:36:28 PM UTC, comment #7:
I also tested the example in a clean directory, both at the command prompt and as a .m script.It is on linux mint 17.2 (based on Ubuntu 14.04).
|
Sat 24 Oct 2015 08:29:27 PM UTC, comment #6:
There was no private folder before i ran your code.
I am on ubuntu 15.04 -no error
comment #4 arch linux -has error
JWE is on debian i think
What linux did you try?
|
Sat 24 Oct 2015 07:30:50 PM UTC, comment #5:
Hi Doug,
I have confirmed this bug on three different machines (one laptop and two desktops) using
- Octave 4.0.0 stable on Windows (installed via binary)
- Octave 4.0.0 stable on Linux (compiled), and
- Octave dev version (4.1.0+) on Linux (compiled, obviously)
- Both the GUI and CLI versions on all of the above
In our irc chat where we briefly discussed this, JWE confirmed it independently, but Mike (mtmx) had the same experience as you and Pantxo.
So, yes, it seems this may not be consistent across builds ... unless you're doing something slightly different to what I'm doing. Are you sure there was no private folder before starting the octave session?
|
Sat 24 Oct 2015 06:25:42 PM UTC, comment #4:
Strange, I can confirm this bug as well as bug #46282 in the latest default branch 20653:c16947991354 under Arch linux 4.2.2-1.
|
Sat 24 Oct 2015 06:09:12 PM UTC, comment #3:
This also works for me
default branch and ubuntu 15.04
|
Sat 24 Oct 2015 05:38:46 PM UTC, comment #2:
Hi,
Thanks for your report. Both this bug and bug #46282 work for me with a recent build of the default branch: packages and private directories are searched the first time also. Are you using the stable branch?
|
Sat 24 Oct 2015 02:55:59 PM UTC, comment #1:
Linked bug as per comment below: bug #46282: Newly defined functions within a namespace are inaccessible via that namespace until restart of the octave session
|
Sat 24 Oct 2015 01:19:39 PM UTC, original submission:
Code to reproduce issue from terminal:
A similar bug exists where newly defined functions within a namespace are inaccessible from that namespace until a restart of an octave session. This is likely the same issue under the hood, but I will submit a separate bug report for this and link to it above.
|