Sat 27 Feb 2016 12:33:27 AM UTC, comment #10:
I think what you were looking for was either program_name() or program_invocation_name().
It's not perfect, but program_invocation_name is the same as program_name when I use run-octave, but is a very long full path to the executable when I am running an installed version of octave.
I don't think these tests need to be a part of the full regression suite. Invoking run-octave, as is done to create the plots for the manual, is a slow processwhich we shouldn't inflict on everyone.
One way forward would be to create a directory under test/ which has all of the m-files you need to do your testing. Next, add a new test target to test/module.mk which runs the scripts in your new directory. This would be manual, but you could run 'make my_newline_tests' before each release to verify nothing has changed.
|
Fri 26 Feb 2016 11:17:46 PM UTC, comment #9:
Do you have any idea how to go around write such tests?
Is there any way to figure out what executable has been used to start a running Octave session? It's not the first element in Octave's argv.
Or another set of tests within test/ as a separate check target? I'm a bit at loss there.
|
Fri 26 Feb 2016 09:23:41 PM UTC, comment #8:
A couple minor tweaks to this one here:
http://hg.savannah.gnu.org/hgweb/octave/rev/8cfd1b47d49f
Please compare the following test cases that were still inserting extra newlines, fixed with this cset.
|
Fri 26 Feb 2016 04:36:19 PM UTC, comment #7:
@Carnë: I modified the commit message to have newlines between the changes to different files. Also, unless the file is ambiguous, like module.mk, we no longer need to put in the directory path to the file so I took that out too. The actual patch works fine so I checked it in here (http://hg.savannah.gnu.org/hgweb/octave/rev/8e94a86ca648).
Given the difficulty involved, and the fact that this is pretty obscure, I would skip writing tests for this. But don't let me stop you if you're motivated.
Marking the bug fixed and closing report.
|
Fri 26 Feb 2016 02:16:12 PM UTC, comment #6:
Carnë, one way to write tests would be to have the test make a system(...) call with the suitable "./run-octave" or "octave" command you want to test.
(In case you want to use jwe's reference to deck chairs, the normal expression is "rearranging deck chairs on the Titanic" -- jwe was just being creative.)
|
Fri 26 Feb 2016 01:46:10 PM UTC, comment #5:
I believe the attached cset fixes this issue. There are newlines being
printed in a couple of places, and triggered by different things. In an Octave
session, the issue is that newlines are printed after catching an exception.
That newline is needed when Octave returns to prompt, for example, when
using Ctr+C at the prompt. However, it is being printed before we decide
whether Octave needs to return to prompt at all.
In the case of running an Octave program or --eval, it seems that the
newline is not needed at all. Error messages already have a newline.
Even when using --persist I didn't came up with a case where it is needed
so I removed the newline completely for those cases.
Here's a session with the attached patch:
Any idea how to write a test for this stuff?
(file #36472)
|
Thu 25 Feb 2016 10:16:55 PM UTC, comment #4:
> Please don't misunderstand me, I like rearranging deck chairs on sinking ships as much as anyone, but why this particular chair?
Ah! I have never heard that expression before. Anyway, I wouldn't compare
Octave to a sinking ship. Also, I report a lot of very minor bugs just so
they are reported somewhere. I'm not requesting others to fix it for me.
It gives me a place to come to when I find time to do it myself, or a
starting point for someone else that may have the same itch.
> Sorry if that sounds bad, but what real problems does this cause?
I guess I am one of those odd people who write Octave programs instead of
only using the interactive session.
One of the things I have been doing a lot lately is finding centre of objects
in images. My programs then write the coordinates of those objects to stdout
which I redirect into a file (I use a build system for my analysis, where
data is the source, results are the target, and I build the results with
my programs).
The simplest analysis of all is counting the number of objects identified.
These are just the number of lines which is trivial in the shel with wc. This
all worked fine for a long time but now failed once I added an exit(). Of
course, this is a very minor thing and I just fixed my own code to avoid
exit() altogether.
Still, this is wrong behaviour, Octave should only be printing newlines
if the program tells it to.
|
Thu 25 Feb 2016 07:18:31 PM UTC, comment #3:
Confirmed, although this is pretty minor.
I added the file finish.m to the cwd with the code
and changed foo_exit.m to
Upon running
So it would seem that the issue is somewhere in the actual exit code.
|
Thu 25 Feb 2016 06:16:13 PM UTC, comment #2:
Please don't misunderstand me, I like rearranging deck chairs on sinking ships as much as anyone, but why this particular chair?
|
Thu 25 Feb 2016 06:14:25 PM UTC, comment #1:
I continue to be amazed that anyone actually cares about this issue.
Sorry if that sounds bad, but what real problems does this cause?
|
Thu 25 Feb 2016 05:37:47 PM UTC, original submission:
When using exit(), Octave prints an empty line:
This can also be seen from the interpreter:
There is bug #41513, about the opposite issue. When exiting with Ctr+D, there was no newline being printed which already got fixed. Undoing that change did not fix this.
|