error doesn't return to debug prompt

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

error doesn't return to debug prompt

Olaf Till-2
jwe,

since you are working at error handling at the moment, are you aware
that with current tip, if a command given at the debug prompt causes
an error, it returns to top level, not to the debug prompt?

octave:1> function func ()
> keyboard
> endfunction
octave:2> func
stopped in func at line 2
debug> error ("test")
error: test
error: called from
    func at line 2 column 1
octave:2>

Olaf
--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: error doesn't return to debug prompt

Rik-4
On 10/16/2015 09:00 AM, [hidden email] wrote:
Subject:
error doesn't return to debug prompt
From:
Olaf Till [hidden email]
Date:
10/15/2015 10:50 PM
To:
"John W. Eaton" [hidden email]
CC:
octave maintainers mailing list [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
Message-ID:
<20151016055058.GA12545@till>
Content-Type:
multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s"
Message:
4

jwe,

since you are working at error handling at the moment, are you aware
that with current tip, if a command given at the debug prompt causes
an error, it returns to top level, not to the debug prompt?

octave:1> function func ()
> keyboard
> endfunction
octave:2> func
stopped in func at line 2
debug> error ("test")
error: test
error: called from
    func at line 2 column 1
octave:2> 

Olaf
Olaf,

Can you file a bug report about this so it doesn't get lost?  This is just one of many areas that need to be updated now that exceptions are used in the core.  Maybe you can link your issue report to bug #46216 which is another case of exceptions changing existing behavior.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: error doesn't return to debug prompt

Olaf Till-2
On Mon, Oct 19, 2015 at 10:57:56AM -0700, Rik wrote:
> Can you file a bug report about this so it doesn't get lost?  This is just
> one of many areas that need to be updated now that exceptions are used in
> the core.  Maybe you can link your issue report to bug #46216 which is
> another case of exceptions changing existing behavior.

Have reported it as

<http://savannah.gnu.org/bugs/?46251>

and made the links to #46216 and backwards from there.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

print error and 4.0.1

Michael Godfrey
In reply to this post by Rik-4
Rik,

I thought about the suggestion of enclosing the actual print call to OpenGL
in visible, off ... visible, on...  When I considered this it seemed like
overkill. But, now I wonder: is there any reason to have visible on while
the plot is being printed? If not, this could not only be a helpful fix
for 4.0.1, but it stay in for as long as it takes... It would still be nice to
resolve the seg fault bug, but it is likely from what I have learned that
it is not entirely an Octave problem. I think that the bug report to
the OpenGL folks is still open.

The full test should be:

if (visible on}
    visible off
    actual print xxx
    visible on
else
    actual print xxx
endif

Michael

Reply | Threaded
Open this post in threaded view
|

Re: print error and 4.0.1

Rik-4
On 10/19/2015 04:00 PM, Michael Godfrey wrote:
Rik,

I thought about the suggestion of enclosing the actual print call to OpenGL
in visible, off ... visible, on...  When I considered this it seemed like
overkill. But, now I wonder: is there any reason to have visible on while
the plot is being printed? If not, this could not only be a helpful fix
for 4.0.1, but it stay in for as long as it takes... It would still be nice to
resolve the seg fault bug, but it is likely from what I have learned that
it is not entirely an Octave problem. I think that the bug report to
the OpenGL folks is still open.

The full test should be:

if (visible on}
    visible off
    actual print xxx
    visible on
else
    actual print xxx
endif

Michael


Michael, and anyone else who knows more about the print bug,

I think the issue is reversed.  Isn't the problem that when the figure is invisible Octave goes through the OSMESA libraries, whereas when it is visible it goes through Gl2ps and is okay (at least no segfault).  The big issue seems to be OpenGL and patches on Windows systems.  There are more than four bug reports about crashes of the plot system on Windows platforms that usually only involve clicking on a plot with a patch object.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: print error and 4.0.1

Pantxo
Rik-4 wrote
On 10/19/2015 04:00 PM, Michael Godfrey wrote:
> Rik,
>
> I thought about the suggestion of enclosing the actual print call to OpenGL
> in visible, off ... visible, on...  When I considered this it seemed like
> overkill. But, now I wonder: is there any reason to have visible on while
> the plot is being printed? If not, this could not only be a helpful fix
> for 4.0.1, but it stay in for as long as it takes... It would still be
> nice to
> resolve the seg fault bug, but it is likely from what I have learned that
> it is not entirely an Octave problem. I think that the bug report to
> the OpenGL folks is still open.
>
> The full test should be:
>
> if (visible on}
>     visible off
>     actual print xxx
>     visible on
> else
>     actual print xxx
> endif
>
> Michael
>

Michael, and anyone else who knows more about the print bug,

I think the issue is reversed.  Isn't the problem that when the figure is
invisible Octave goes through the OSMESA libraries, whereas when it is
visible it goes through Gl2ps and is okay (at least no segfault).  The big
issue seems to be OpenGL and patches on Windows systems.  There are more
than four bug reports about crashes of the plot system on Windows platforms
that usually only involve clicking on a plot with a patch object.

--Rik
Hi,

@Michael:
Offscreen printing only works on some linux machines (those that don't use proprietary drivers) so I would not recommend to do this change until we find a way to have it work on most platforms.

@Rik: Can you point to those bugs on windows?
Also, gl2ps_print is called in both situations, either with an OpenGL context/feedback buffer provided by OSMesa (in case "visible", "off") either by Qt/FLTK (which use the default installed openGL driver/library depending on the platform).

Pantxo
Reply | Threaded
Open this post in threaded view
|

Re: print error and 4.0.1

Michael Godfrey


On 10/20/2015 08:24 AM, Pantxo wrote:
Rik-4 wrote
> On 10/19/2015 04:00 PM, Michael Godfrey wrote:
>> Rik,
>>
>> I thought about the suggestion of enclosing the actual print call to
>> OpenGL
>> in visible, off ... visible, on...  When I considered this it seemed like
>> overkill. But, now I wonder: is there any reason to have visible on while
>> the plot is being printed? If not, this could not only be a helpful fix
>> for 4.0.1, but it stay in for as long as it takes... It would still be
>> nice to
>> resolve the seg fault bug, but it is likely from what I have learned that
>> it is not entirely an Octave problem. I think that the bug report to
>> the OpenGL folks is still open.
>>
>> The full test should be:
>>
>> if (visible on}
>>     visible off
>>     actual print xxx
>>     visible on
>> else
>>     actual print xxx
>> endif
>>
>> Michael
>>
> 
> Michael, and anyone else who knows more about the print bug,
> 
> I think the issue is reversed.  Isn't the problem that when the figure is
> invisible Octave goes through the OSMESA libraries, whereas when it is
> visible it goes through Gl2ps and is okay (at least no segfault).  The big
> issue seems to be OpenGL and patches on Windows systems.  There are more
> than four bug reports about crashes of the plot system on Windows
> platforms
> that usually only involve clicking on a plot with a patch object.
> 
> --Rik
Hi,

@Michael:
Offscreen printing only works on some linux machines (those that don't use
proprietary drivers) so I would not recommend to do this change until we
find a way to have it work on most platforms.

@Rik: Can you point to those bugs on windows?
Also, gl2ps_print is called in both situations, either with an OpenGL
context/feedback buffer provided by OSMesa (in case "visible", "off") either
by Qt/FLTK (which use the default installed openGL driver/library depending
on the platform).

Pantxo



--
View this message in context: http://octave.1599824.n4.nabble.com/error-doesn-t-return-to-debug-prompt-tp4672950p4673012.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.

Sorry, I did not realize that the Windows problems are very different from the Linux ones,
and also that some Linux systems show parts of the problem, too.
So, forget my suggestion. It seems it only works on some Linux systems, like Fedora.
However, answering Rik, I should add that the two problems: 1) clicking on a window
after it was drawn, and 2) doing anything to a window as it was being drawn both of
which affected my Fedora system with Intel HD 5000/6000 video, have definitely been
fixed. As long as I use visible 0ff, print, visible on I have no plotting or printing problems.
(This is for the current dev system.) When a pre-4.0.1 becomes available, I will check it.

Michael