bugGNU Octave - Bugs: bug #55823, Calling a subfunction containing...

 
 

bug #55823: Calling a subfunction containing rmdir() from a m-file in an editortab closes the tab

Submitter:  Joel Cottrell <jcottrell>
Submitted:  Mon 04 Mar 2019 05:20:33 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Joel Cottrell Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Dec 2019 10:14:07 AM UTC, comment #51: 

This particular bug keeps me from using Octave 5.1.0. I understand that there is a bug fix, but I do not know how to make use of that. I have no experience in making my own build.

Is there any beta build or so in which this bug fix has been applied?

Dennis <dizze>
Wed 27 Mar 2019 03:21:18 AM UTC, comment #50: 

Thanks everyone! Sorry I can't help test the patch yet, as I'm still new to this and don't have a build environment set up.

Joel Cottrell <jcottrell>
Tue 26 Mar 2019 07:11:04 PM UTC, comment #49: 

With the patch I can't reproduce the original error anymore, so it looks to be fixed. I have no time/priority this week for more testing.

BTW in comment #45:
It is xlsclose.m not xlsopen.m that calls a private function that in turn removes the temporary directory.
I could only partly follow the reasoning in comment #46 but that's probably moot.

Thanks Torsten!

Philip Nienhuis <philipnienhuis>
Group Member
Mon 25 Mar 2019 08:22:33 PM UTC, comment #48: 

Yes, if the patch fixes the issue on other platforms, too, I will cherry-pick this into stable.

Torsten Lilge <ttl>
Group Member
Mon 25 Mar 2019 08:00:26 PM UTC, comment #47: 

Thanks Torsten.
This week I'm in a course so I have to squeeze testing somewhere in between the scenes.

Is this fix also meant for stable? (can't see that right now). If it works (I suppose it does) the fix might need to go there as well, as it can be viewed as a sort of regression.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 25 Mar 2019 07:25:21 PM UTC, comment #46: 

The io package has uncovered a bug in the logic for checking whether the editor files are located in the removed directory. Actually, the bug shows up each time the removed directory is on another windows drive than the opened files. In this case the file path relative to the directory does not start with ../ although the file is not included in the removed directory or in its subdirectories.

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/d164e70efbf6 should fix this.

Torsten Lilge <ttl>
Group Member
Sun 24 Mar 2019 08:16:30 PM UTC, comment #45: 

Thanks for the tips for speeding up the mxe cycles.

xlsopen removes a temporary directory and this might be the cause for the editor closing the tabs. I guess that in windows, the test whether the open files are located in the removed directory fails, maybe due to the drive letter concept. More tests will follow.

Torsten Lilge <ttl>
Group Member
Sun 24 Mar 2019 07:40:51 PM UTC, comment #44: 

Editor tab also closes upon a "pkg uninstall" command.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 22 Mar 2019 07:47:38 PM UTC, comment #43: 

@Georg Wiora, comment #41:
As outlined vaguely in (top of) comment #7, all that is needed are the spreadsheet-open and spreadsheet-close user-accessible functions xlsopen.m and xlsclose.m. Both are called by xlsread.m, xlswrite.m and xlsfinfo.m.
in fact I think even just the private funcs __OCT_spsh_open__.m and __OCT_spsh_close__.m will do the job.

@Torsten, comment #39:
I still suspect that something with unpack or unzip or so is involved or at least interfering.
In case of installing the io package (or any other package) the .tar.gz file needs to be unpacked first; afterwards the temporary unpacked archive is wiped with the same 'rmdir (<unpacked archive>, "s")' command that looks involved here.

For debugging there's a trick that I tried some time ago with a "keep-files" (IIRC) configure option that will allow to patch Octave in the tmp-default-octave folder in mxe and then continue or restart the build with make zipdist etc.
In fact I often just let it build and install in the ./dist/octave..../ folder, skip building the archive, and ran it from there by rebooting in Windows (or starting a Windows VM) and accessing the ./dist/octave.../ hierarchy from the Windows side using shared folders or ext2fsd.
Some details are in the wiki.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 22 Mar 2019 05:48:14 PM UTC, comment #42: 

@Philip: I am quite sure that the bug lies somewhere in the changeset you mention. I will do some more testing on my windows VM which always take some time due to the long mxe build cycles.

Torsten Lilge <ttl>
Group Member
Fri 22 Mar 2019 09:55:57 AM UTC, comment #41: 


> @Torsten, can you confirm that the bug is only exposed after first running xlsread() (using OCT interface, i.e., w/o Java and/or Excel)?


@Philip: You do not need to call xlsread. It is sufficient to call xlswrite with OCT interface. The bug does not appear using COM interface.

Georg Wiora <gwiora>
Fri 22 Mar 2019 08:29:15 AM UTC, comment #40: 


> the editor tabs were also closed at the end of the io package installation


Hah, another weird bug feature.
The file __init_io__.m is the candidate.
You could try "pkg load io" from an editor tab and see if that tab gets closed.

@Torsten, can you confirm that the bug is only exposed after first running xlsread() (using OCT interface, i.e., w/o Java and/or Excel)?

Again, the bug at hand there didn't occur until early August 2018; so that seems to suggest the problems here could be related to these csets by you that were pushed on Aug. 5:

c2a703df0215 preserve tab position and line when reloading renamed editor file (bug #49322)

-and/or-

d3c6de326bae) close/reload editor tab when file is (re)moved in gui terminal (bug #43922)

but that may be a red herring, as it can also be that those csets uncovered some bug in io. But I cannot imagine where that should occur. Nowhere does the io package link to files in the GUI editor.

Anyay I'll check the io package logic.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 21 Mar 2019 08:55:10 PM UTC, comment #39: 

I can confirm the issue on Window 7 following the steps of comment #36.

Remarkably, the tabs are closed before rmdir () prompts whether to close the entire directory or not.

And even more remarkably, the editor tabs were also closed at the end of the io package installation!

Torsten Lilge <ttl>
Group Member
Thu 21 Mar 2019 06:45:36 PM UTC, comment #38: 

It is weird that a call to the spreadsheet scripts is required to "activate" the bug.  AFAICT it isn't related to xlsread.m nor xlsopen.m / xlsclose.m as there are no problems with other interfaces than OCT.
So it must be the OCT-interface specific subfunctions that need to be investigated.

So what is needed is to stepwise strip down the actual private routines _OCT_spah_open_.m and _OCT_spsh_close_.m to find out exactly what commands "activate" the bug. It have a suspicion that it may be related to unzip or unpack. Unfortunately I have little time for this until early April.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 21 Mar 2019 03:27:49 PM UTC, comment #37: 

I can confirm the behavior described by Philip. I have a script using xlsread and xlswrite that shows the same effect. After running the program GUI complains that the file in the editor would have been deleted and closes the tab.

I am using octave 5.1.0 on Windows 7.

Georg Wiora <gwiora>
Sun 17 Mar 2019 08:51:42 PM UTC, comment #36: 

Torsten,
can you confirm the original bug report in comment #0 with the files in comment #1 ?

What I find is that initially the command-line function try2_rmdir() works as it should (= no bug), but after calling

xlsread('test.xlsx', 1, '', 'oct')

try2_rmdir() will reliably close editor tabs, sometimes several I opened.

In fact all that is needed to set the stage for the bug are these lines:

xls = xlsopen ('test.xlsx', 0, 'oct')  ## creates the unzipped archive
xls = xlsclose (xls)                   ## deletes the archive


It appears like some code snippet in the IO package somehow changes a state so that the bug gets activated.
I checked the relevant io package OCT interface functions for some global settings changes but I can't find any in there that look suspicious.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Mar 2019 08:21:47 PM UTC, comment #35: 

Yes, for me it doesn't reliably show the bug either.

But intriguingly for me the bug is reliably reproduced if I add the lines:

fn = 'C:\Users\<your login name>\AppData\Local\Temp\testdir'
try2_rmdir (fn)


to the readtest.m script that the OP supplied in comment #2 and select & execute (F9) them from there.

Maybe something with the file's encoding? just a WAG.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 17 Mar 2019 07:16:29 PM UTC, comment #34: 

I am not able to reproduce the issue from comment #29 on Windows 7 with a recent default build. The target directory is removed as expected and the editor tab remains open.

Torsten Lilge <ttl>
Group Member
Fri 15 Mar 2019 09:21:35 PM UTC, comment #33: 

Yes, zoom level is per-tab that's why I was asking for other open tabs.

I agree that the cause is most probably in the fix for bug #43922, but I do not think that the path separator is the cause. From the Qt documentation:

Qt uses "/" as a universal directory separator in the same way that "/" is used as a path separator in URLs. If you always use "/" as a directory separator, Qt will translate your paths to conform to the underlying operating system.

Unfortunately, I am currently facing problems with my mxe environment and am not able ti build octave for my windows vm.

Torsten Lilge <ttl>
Group Member
Fri 15 Mar 2019 09:07:58 PM UTC, comment #32: 

The zoom level looks like it's per-tab, so yeah, when a tab is closed the zoom level will be reset.

As you know I don't have Windows to test on, but this is probably related to the same hunk of code that was added to fix bug #43922. Only guessing but maybe due to backslash file separator on Windows, since the code looks like it's trying to iterate through all open tabs and see if they are relative to the directory that was just rmdir'd.

You might even be able to reproduce this with any non-empty tab, the contents may not even have to be the script or function that calls rmdir. Try "edit ans.m", which is an all-comment placeholder file, then try running your rmdir test, and see if the tab is closed.

Mike Miller <mtmiller>
Group Member
Fri 15 Mar 2019 08:59:25 PM UTC, comment #31: 

@Philip: Which tabs are changing the font size? Are there other tabs open while the considered tab is closed?

Torsten Lilge <ttl>
Group Member
Fri 15 Mar 2019 08:16:16 PM UTC, comment #30: 

Another thing I noticed:

I have the editor on a side screen with higher pixel density, so I usually increase font size with Ctrl-+ a few times.
When the tab gets closed (due to rmdir) the editor's zoom state is also reset (that is the flashing I also reported in comment #7 (third line from bottom)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 15 Mar 2019 05:52:59 PM UTC, comment #29: 

Just define the following command-line function:

>> function try2_rmdir (fn)
  confirm_recursive_rmdir (0, "local");
  rmdir (fn, "s");
endfunction
>> which try2_rmdir
'try2_rmdir' is a command-line function
>> try2_rmdir (fn)


Then, create some test directory structure (can be empty) in %APPDATA%\Local\Temp  (in my case C:\Users\Philip\Appdata\Local\Temp), call it e.g., 'testdir'

In the GUI editor create some m-script file containing:

## substitute your login name
fn = 'C:\Users\<your login name>\AppData\Local\Temp\testdir'
try2_rmdir (fn)

and save it to disk.
Select both lines, and press F9
==> editor tab is closed.

OR,

open the m-script file in an editor tab, and call the script from the command line
==> same effect, tab is closed.

What I learn from this is that the io package is off the hook (which I suspected anyway, the io package code has worked fine until early August last year and works fine in Linux as well)
==> Adapting title
(Hopefully the new title describes the situation more clearly)


Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Mar 2019 10:53:48 PM UTC, comment #28: 

The fix in bug #55888 does not fix the original issue here.

But the code snippet in comment #13 now does not close the tab anymore.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 11:45:41 PM UTC, comment #27: 

Ok, thanks to both of you for the additional details. I can't reproduce this bug at all on Debian, and I don't have access to Windows to test it on. It's possible this is also related to the same change that caused bug #55888, but only manifests on Windows for some reason.

Mike Miller <mtmiller>
Group Member
Tue 12 Mar 2019 11:20:27 PM UTC, comment #26: 

@Mike, I see my original problem whenever xlsread() runs successfully and there is a file open in the terminal. This can be achieved by opening readtest.m and pressing F5, or by opening anything at all and running the command by manual command entry, pressing F9, or by right clicking readtest.m in the filebrowser and pressing 'Run'.

Maybe we won't know for sure whether this bug and 55888 are linked until one of them is patched, and I agree that 55888 is the better one to tackle first.

Joel Cottrell <jcottrell>
Tue 12 Mar 2019 10:31:02 PM UTC, comment #25: 

Yes, on my Mageia 6 system I couldn't reproduce it either, that's why this bug is still for Windows only. I didn't try your code in comment #13 on Linux yet.

Torsten wrote last summer in one of the comments in bug #43922 s/th about specific Windows issues. Now, reading back on it I remember that there wer several seemingly loosely correlated bugs that all related to bug #43922.
So I'm not surprised that some manifestations of what we see here only apply to Windows and some apply to "Any" OS.

Let's just wait for Torsten's fix in bug #55888 and see if it solves all issues here.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 08:07:59 PM UTC, comment #24: 

I cannot reproduce following comment #4 on Debian. The single highlighted code line runs fine in the command window, the editor tab with the modified 'readtest.m' stays open, no prompt is shown, I can repeatedly hit F9 to run it multiple times.

Mike Miller <mtmiller>
Group Member
Tue 12 Mar 2019 07:52:17 PM UTC, comment #23: 

Mike, our posts crossed.

See my comment #4 for an example of an unsaved (modified) tab exactly using Joel's example files.

BTW that the OCT interface is required is because that unzips and zips back the spreadsheet files and then wipes the unzipped archive using code somewhere in the io scripts.
The COM interface doesn't do that.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 07:42:21 PM UTC, comment #22: 

"Bisecting" tru the old mxe-installers, it turns out this bug got introduced last summer before Aug 6 and after July 31.

Both the readtest.m (comment #0) and the code in comment #13 work fine in installers built on July 31 and August 1, but fail in an installer built on Aug. 6, 2018.

@Mike:
Because of this "synchronicity" I think you can safely close either this report or bug #55888.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 06:53:56 PM UTC, comment #21: 

@philip When I read the original bug here, I don't see anything about an unsaved tab in the editor. Joel gave a script file 'readtest.m' and said that running it in the editor triggered this bug. He said that the file was closed in the editor and then he reopened it, implying that the file was indeed already saved.

Are you saying that you are unable to reproduce this bug with the files that Joel provided in comment #2? If so then this bug needs more information from Joel about precisely how to reproduce this. If it can't be reproduced except by pasting into a new unsaved tab, then this should be closed and bug #55888 will continue.

I asked Joel in comment #15 for more details, for example how exactly was the script run in the editor, was it saved or unsaved, was it run with F5 or F9, etc.

Mike Miller <mtmiller>
Group Member
Tue 12 Mar 2019 06:51:31 PM UTC, comment #20: 

I just started "bisecting" using my collection of archived crossbuilds.
It turns out this bug dates back from before Sept. 30 last year (Octave-5.0.0 and io-2.4.11).
Intriguing that this bug shows up only now.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 06:31:52 PM UTC, comment #19: 

With the code example in comment #13, if you click "Save" and save the file the bug is  "neutralized".
But running only the first two statements, copying the 3rd line to a new blank script, selecting it and pressing F9 again triggers the bug.

I think bug #55888 is simply a dupe.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 06:27:26 PM UTC, comment #18: 

What I see in comment #13 to #16 is IMO the same thing as the original bug. or can you explain the difference in more detail?

AFAIU the bug is that the editor erroneously links an editor tab's contents with a newly created subdir (AFAICS not necessarily a temp dir) at the very moment that F9 is pressed on a statement containing rmdir on that subdir.
The exact behavior may vary but I think it is the same bug in different disguises.

Joel complained that the editor tab was closed, but that was with a script that wasn't changed.
If something was changed in the script (e.g., adding a space or so) the editor still wants to close the tab but correctly recognizes the change and prompts for confirmation.

I really doubt, or rather, I really can't imagine that the io package has anything to do with it, apart from generating and trying to close an unpacked archive containing a directory structure in different functions, which triggers the bug.
For the time being I'll leave the title as-is.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Mar 2019 03:29:31 AM UTC, comment #17: 

I have tried a couple of other machines with older releases of Octave installed: Xubuntu running Octave 4.2.2 and Windows 7 running Octave 4.4.1. All machines have the latest io package from forge: 2.4.12.

Neither this bug nor 55888 occur in either environment, so it's probably something new/changed in the Octave main codebase since 4.4.1 release in August that is causing these problems in 5.1.0.

I should have tested that earlier.

Joel Cottrell <jcottrell>
Tue 12 Mar 2019 01:35:14 AM UTC, comment #16: 

See bug #55888 for the bug about the editor closing an unnamed script on rmdir.

Mike Miller <mtmiller>
Group Member
Tue 12 Mar 2019 01:22:18 AM UTC, comment #15: 

Joel - OK, it sounds like this bug is still about something very specific to the io package, that a script that has been saved and not modified is closed in the editor. If that's what you're seeing, I think we need more information about how to reproduce that. Can you verify that readtest.m is saved on disk, no changes have been made to it, and you run it with what, F5 or F9? And then the file is closed in the editor with no prompt shown?

I personally don't have Windows to test with, but I downloaded all the attachments you provided in comment #2 and I don't see any problems on my Debian system, the script stays open in the editor after multiple tries to run it with either F5 or F9.

I will file a separate bug report about the script closing an unsaved file when rmdir is called, that is very easy to reproduce.

Mike Miller <mtmiller>
Group Member
Tue 12 Mar 2019 01:09:04 AM UTC, comment #14: 

Hi Mike, yes I see the same thing on Windows; Running those lines with F9 opens an unexpected prompt asking for the as-yet-unsaved script to be saved or closed. If I run F9 on one line at a time, I can see that it's the rmdir line that opens the prompt. The saved script doesn't prompt or close when tested with F5 or F9.

As you say, this appears to be a different symptom from what I originally saw when using the io package, but it may be linked.

I'm not familiar enough with the GUI workings to join in the discussion about oct_spsh_close.m, but I do appreciate your efforts.

Joel Cottrell <jcottrell>
Mon 11 Mar 2019 11:15:03 PM UTC, comment #13: 

Thanks, here's a far simpler example that I tried in Octave 5.1 and on the development branch.


dn = tempname ();
mkdir (dn);
rmdir (dn);


Start Octave, open a new tab in the editor, paste the above, don't save it, highlight all text, and press F9 for "Run Selection". Octave will prompt for the file in the editor to be either closed or saved. If I choose "Save" and give it a file name, the file stays open in the editor. This is on Debian.

Does this match what you're seeing on Windows?

That doesn't seem to describe what this bug report was originally about. If the script is saved first as "readtest.m" then I don't see any prompt and the file is not closed.

Mike Miller <mtmiller>
Group Member
Sun 10 Mar 2019 07:17:46 PM UTC, comment #12: 

A way to reproduce with 50% use of the io package:

1. Open a spreadsheet file (.ods, .xlsx, .gnumeric) using
ptr = xlsopen (<filename>, 0, 'oct')

note the location of the unzipped archive in the ptr structure and copy to clipboard (it is in ptr.workbook) (or keep it some other way)

2. exit Octave
(unzipped archive won't be cleaned up)

3. restart Octave
type:
tdirname =
Ctrl-V
(i.e., assign full pathname of unzipped archive to tdirname by pasting), or type it in if not copied to clipboard.

4. in a blank file in editor, type
confirm_recursive_rmdir (0, "local");
rmdir (tdirname, "s");

and execute these lines. The bug will be triggered (at least on my system).

Next step:
try with any unzipped archive. ATM I just don't have a suitable archive at hand other than spreadsheet files.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 10 Mar 2019 07:04:49 PM UTC, comment #11: 

Also, cd'ing hence and forth shouldn't interfere with a script or file in the editor. That also happens with a file in the editor and then running _run_test-suite_ - I saw no problems with that.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 10 Mar 2019 07:02:12 PM UTC, comment #10: 

@Mike,
I've tried a little but couldn't come up yet with something. I figured creating a hierarchy in %TMP% and then debug-stepping through the following function:

function rmdirtest (tdirname)
  confirm_recursive_rmdir (0, "local");
  rmdir (tdirname, "s");
endfunction


(where tdirname is obviously the "root" dir in the hierarchy) might trigger the bug, but no and I have little time now anyway for Octave. I'm busy with it but progress will be slow.

IIRC there were some bug fixes with files in the editor some weeks or months ago, could be related. Plus, I have a long series of cross-builds archived that I can try, usually 3-4 days apart, unfortunately much less "dense" in last December and January.

My feeling that io itself isn't involved is based on that I never hit this before (and developing the io package files for OCT interface involved a lot of debug stepping through _OCT_spsh_close_.m) and it is definitely the recursive rmdir() statement where it happens.
Also, AFAIU the unzipped spreadsheet file archives aren't locked by e.g., unzip (I know, a WAG) as writing to them and zipping works fine.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 09 Mar 2019 04:55:31 PM UTC, comment #9: 

@philip Can you give an example for reproducing without the io package? What is the relation between xls.workbook and readtest.m? There's a lot of code there, but it looks to me like there is a cd to that directory, then a cd back, followed by the rmdir? Maybe the changing of working directory is what's causing the response in the editor?

Mike Miller <mtmiller>
Group Member
Sat 09 Mar 2019 03:27:19 PM UTC, comment #8: 

4th line from below should read 'rmdir (xls.workbook, "s");'

I'll remove my name from "assigned to" as is seems this is not caused by the io package.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 08 Mar 2019 07:30:10 AM UTC, comment #7: 

Even weirder:

If:
(1) I add the following lines into readtest.m without saving the file:
xls = xlsopen (''test.xlsx', 0, 'oct');
xls = xlsclose (xls)

(2) I open xlsclose.m in the editor ('edit xlsclose')

(3) Add a breakpoint at xlsclose L. 121

(4) Back in readtest.m, I select the two newly added lines and press F9 to execute them

(5) When execution stops at L.2121 in xlsclose.m, I click the "Step into "button
==> execution continues in _oct_spsh_close_.m

(6) Step all the way through _oct_spsh_close_.m

(7) And when _oct_spsh_close_.m is finished, I step all the way through xlsclose.m until back in the prompt in the octave terminal,

==> the file readtest.m is still in the editor but I cannot edit it anymore, it is blocked.
Only thing I can do is click the close button and in the pop-up menu do "Save", "Discard" or "Cancel".

Trying again, and adding some character to readtest.m after every debug step in _oct_spsh_close_.m, it turns out it is line 99 in _oct_spsh_close_.m:

rmdir (xls.workbook, "s");

that does it. when I step over it, the editor screen flashes.
When back in readtest.m I press the close button, if clicking "cancel" the file becomes editable again.

I'm cc-íng the GUI guru; a while ago some fixes were made to the GUI editor that smell to be related.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 08 Mar 2019 12:00:09 AM UTC, comment #6: 

No worries Philip, looking after your health is a priority.
This bug isn't a major problem, as the consequence is usually just inconvenience and there are workarounds.

Joel Cottrell <jcottrell>
Thu 07 Mar 2019 11:07:26 PM UTC, comment #5: 

... and I can reproduce it on Windows 7 as well.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 07 Mar 2019 11:02:47 PM UTC, comment #4: 

Confirmed on Windows 10 with Octave-6.0.0(dev version)

This is really an intriguing one ... I have no idea what is going on.

I opened your file readtest.m in the Octave editor, changed the command
xlsread('test.xlsx')
into
xlsread('test.xlsx', 1, '', 'oct')
selected it using the mouse cursor and pressed F9
Then I got a popup that h file was changed and if I wanted to save the changes, which indicates the editor wants to close the file.

It is only with the (native) OCT interface that it happens. With COM (using MS-Excel behind the scenes) I can't reproduce it.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 07 Mar 2019 06:47:47 PM UTC, comment #3: 

Joel, sorry didn't have time yet and a sore back got in the way. That inconvenience is over but I have a busy time anyway.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 05 Mar 2019 01:32:46 AM UTC, comment #2: 

Hi Philip, thanks for your reply.

Please find attached a test script, some test spreadsheets, and the diary that for the chk_spreadsheet_support and my xlsread tests.

I apparently don't have any of the external interfaces, so it's using the octave native implementation. Perhaps if I install MS Office or one of the other options, I could work around this issue; this computer only has OpenOffice 4.1.3 currently.

(file #46423, file #46424, file #46425, file #46426)

Anonymous
Mon 04 Mar 2019 10:11:48 AM UTC, comment #1: 

Weird.
I only rarely use Win10 (rather Win7, until Jan next year when I have to switch) but I'll try to have a look.
To that end I do need more info:

- Which "interface" do you use? Do you have MS-Office installed?

- Please attach (do not post or include in "verbatim" tags) the output of:

diary on
[a, b, c] = chk_spreadsheet_support ("", 3)
diary off

and upload the "diary" file to this bug report.
If you have a very simple Excel file that "works" to reproduce this behavior please upload it as well.



Philip Nienhuis <philipnienhuis>
Group Member
Mon 04 Mar 2019 05:20:33 AM UTC, original submission:  

Whenever I run the xlsread function in a script, it works properly but closes my script in the Octave editor, so I need to open it again each time.

I'm running io 2.4.12 on Octave 5.1.0 and Windows 10. If anyone else can replicate the problem, it might be worth looking into. I'm unsure whether there's an issue with the io package or the Octave GUI source, or both.

Joel Cottrell <jcottrell>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46427:  test.xls added by None (7KiB - application/octet-stream)
file #46423:  readtest.m added by None (217B - text/plain)
file #46424:  test.ods added by None (10KiB - application/vnd.oasis.opendocument.spreadsheet)
file #46425:  diary added by None (2KiB - application/octet-stream)
file #46426:  test.xlsx added by None (10KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by dizze (Posted a comment)
  • -email is unavailable- added by gwiora (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by jcottrell (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 24 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-06 rik5 Carbon-CopyRemoved 72865 -
    2019-05-27 siko1056 Dependencies- bugs #56380 is dependent
    2019-04-01 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-03-25 ttl StatusConfirmed Ready For Test
    2019-03-15 philipnienhuis SummaryCalling a subfunction containing rmdir() from a m-file in nn editortab closes the tab Calling a subfunction containing rmdir() from a m-file in an editortab closes the tab
    2019-03-15 philipnienhuis CategoryOctave Package GUI
        StatusNeed Info Confirmed
        Summary[octave forge] (io) xlsread(...) call using OCT interface interferes with GUI editor Calling a subfunction containing rmdir() from a m-file in nn editortab closes the tab
    2019-03-12 mtmiller StatusConfirmed Need Info
    2019-03-09 philipnienhuis Assigned tophilipnienhuis None
    2019-03-08 philipnienhuis Carbon-Copy- Added ttl
    2019-03-07 philipnienhuis Item GroupPerformance Unexpected Error or Warning
        StatusNeed Info Confirmed
        Assigned toNone philipnienhuis
        Release5.1.0 dev
        Summary[octave forge] (io) xlsread(...) call interferes with Octave editor GUI [octave forge] (io) xlsread(...) call using OCT interface interferes with GUI editor
    2019-03-05 None Attached File- Added test.xls, #46427
    2019-03-05 None Attached File- Added readtest.m, #46423
        Attached File- Added test.ods, #46424
        Attached File- Added diary, #46425
        Attached File- Added test.xlsx, #46426
    2019-03-04 mtmiller StatusNone Need Info
        Summaryxlsread(...) call interferes with Octave editor GUI [octave forge] (io) xlsread(...) call interferes with Octave editor GUI

    Back to the top

    Powered by Savane 3.14-f13d.
    Corresponding source code