Tue 27 Sep 2011 06:11:27 PM UTC, comment #15:
You are welcome to contribute to our discussion on how to create a proper GUI for Octave here:
http://octave.1599824.n4.nabble.com/Release-plans-for-the-GUI-td3790414.html
|
Tue 27 Sep 2011 06:04:01 PM UTC, comment #14:
We are working on a native GUI.
https://bitbucket.org/jordigh/gnu-octave
And this bug report is not the place to discuss it.
|
Tue 27 Sep 2011 05:41:45 PM UTC, comment #13:
@jordigh
Well, first of all - I'm not a programmer. Just a user. Moreover, I'm 'windows'-type user - I need a GUI/IDE. Probably, I'm not the only one if you have "...major projects for creating new-frontends spring up for Octave about twice a year by different individuals...".
The only reason that you have such attempts "for perhaps the 20th time in 10 years" is the consistent failure of the octave team to provide their users such a frontend. As you say - for about 10 years you have not come with a single GUI solution.
Maybe because "this involves learning something"? I do not know. But as long as there is no 'native' solution - I don't care if the others are implemented 'incorrect' from your point of view, as long as they actually function. If you know a better way - go ahead - do it.
Though you have absolutely no right to break the way it works for others and then call them "failed projects". Some of them, were actually quite successful, until you have made them fail.
Oh, and since you are one of the developers of the yet to be 'native' GUI - the whole thing looks just like preventing a competition...
Kind Regards and "sorry to be terse"
Very Unhappy User
|
Tue 02 Aug 2011 07:53:38 PM UTC, comment #12:
I checked in the following change on the default branch:
http://hg.savannah.gnu.org/hgweb/octave/rev/6e1b9f079e0f
This removes the warning and debugging appears to work normally when I run Octave this way:
or
but I have not done extensive testing.
|
Fri 13 May 2011 05:31:18 PM UTC, comment #11:
You never answer my questions, if i question about the orange you answer me about the apple,
anyway thanks for your answer.
Ahh and i do not agree with you that: "but it also reads keystrokes e.g. C-z".
Octave do not read keystrokes for nothing, that is handled through signals (e.g. SIGINT)
which is independent of whether Octave reads by a pipe or a tty.
|
Fri 13 May 2011 01:43:35 PM UTC, comment #10:
I hope you are not suggesting that you are blind to Quint.
Furthermore, note that Octave's debugger reads more than just text, but it also reads keystrokes e.g. C-z for stopping execution. Would you play nethack or use less(1) over a pipe? It's meant to be interactive in a way that a pipe can't be.
|
Thu 12 May 2011 09:19:50 PM UTC, comment #9:
Definitely, there are none so blind as those who will not see.
|
Thu 12 May 2011 09:07:21 PM UTC, comment #8:
Is always necessary to fix all the bugs and not always that connects to Octave through pipes is for realize a front-end.
|
Thu 12 May 2011 09:06:44 PM UTC, comment #7:
I'm sorry, I realise my previous response was again too terse.
The reason why it makes a difference is that debugging is inherently interactive in a way that a script doesn't have to be. Pipes are not meant to be used interactively, but they're fine if you need Octave to process a script and dump output to some file or screen. When you use pipes for an interactive process, however, you end up (1) reimplementing a lot of readline's interface, (2) reimplementing Octave's parser. So because there's no need to do (1) and (2), there is no need to attempt to make debugging work over pipes.
|
Thu 12 May 2011 08:47:41 PM UTC, comment #6:
If there is no frontend, then there is no need to attempt a fix of this bug.
|
Thu 12 May 2011 08:04:34 PM UTC, comment #5:
Forget the front-end, what is the problem that if Octave read by a tty or a pipe when debugging? In this context both are the same thing.
|
Thu 12 May 2011 06:36:53 PM UTC, comment #4:
To be terse: no.
Please consider Quint instead.
And sorry to be terse, but please consider all the failed projects that have attempted to do this with pipes (XOctave, QtOctave, Octave Workshop, GUIOctave to name a few), and why they have failed. Pipes are not the way to go. The proper thing to do, which Quint does, is to hook onto the readline idle loop (and yes, this involves learning something and actually understanding how Octave works instead of treating it like a black box through pipes, which is why it's not what most people want to do at first).
Maybe I'll write a FAQ entry, because as you may have seen in the mailing list, just today we had another person who also wants to start yet another Octave frontend. I'm sorry if I'm being impatient with my response, but we have this happen all the time, for many years now. We're finally trying to fix it the right way, and the right way right now poiints to Quint.
|
Thu 12 May 2011 06:23:03 PM UTC, comment #3:
In the file 'octave/src/input.cc' in 'get_debug_input' function says:
if (stdin_is_tty)
{
...
}
else
warning ("invalid attempt to debug script read from stdin");
why the warning ?
I have modified that for testing if there is any problem for debugging when stdin is a pipe and there was not any problem, all works fine. Here is the modification:
stdin_is_tty = true;
if (stdin_is_tty)
{
...
}
else
warning ("invalid attempt to debug script read from stdin");
Could you fix this for the next version of Octave ?
|
Thu 12 May 2011 02:13:41 AM UTC, comment #2:
I do not think that is limited to read from standard input as Octave does very well, even through pipes, not think there is something special when it read from standard input while debugging, I see that are the same the prompts ps1, ps2, input() and debug>
|
Wed 11 May 2011 09:18:01 PM UTC, comment #1:
Pipes have many inherent limitations, and they suffer from other cross-platform problems. They are not the way to create a front-end.
We have major projects for creating new-frontends spring up for Octave about twice a year by different individuals, and they often use pipes, which is in our view the wrong way to solve this.
There is current work in a Qt GUI for Octave project that is semi-blessed by the dev team, and we're working on integrating it into the Octave sources:
https://bitbucket.org/jordigh/gnu-octave
It would be much more productive if you could join this ongoing effort to give Octave a GUI than to attempt, yet again, for perhaps the 20th time in 10 years, to create an independent frontend project for Octave using pipes.
|
Wed 11 May 2011 08:46:47 PM UTC, original submission:
Would be good that Octave can debug when it reads from a pipe, for example: if i want to make a front-end for Octave, connecting through a pipe, besides a Editor/Debugger like have MATLAB with breakpoints, is not possible now.
|