octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #47585] GUI editor does not show already activ


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #47585] GUI editor does not show already active breakpoints when a file is opened
Date: Mon, 11 Apr 2016 00:38:26 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15

Follow-up Comment #7, bug #47585 (project octave):

Indenting and identifying parse errors would save a lot of user hours, it's
just that it would be easier to do these things if there were a nice framework
for doing so.

It's a caught-between-a-rock-and-a-hard-place type of situation, really.  The
major contributors have to be the ones to implement/test some generic way of
GUI/core, cross-thread communication.

As I see it, the program isn't made less buggy by calling core routines
directly across a thread.  At worst, it is leaving a potentially difficult bug
for some future user to understand, plus not a path to robust, dependable
code.  It would also be nice to stay withing the GUI's framework.  If
anything, isolating dodgy code to some hack or kludge file would be good. 
Say, creating some bogus command process that calls
"dbstatus('justopenedfile')" command for which the framework could send a
signal and get back an octave_value_list.  That is,



octave:14> edit print
octave:15> dbstop plot 216
ans =  216
octave:16> dbstop plot 229
ans =  229
octave:17> dbstop print 357
ans =  357
octave:18> brklist = dbstatus('plot')
brklist =

  scalar structure containing the fields:

    name = plot
    file = /usr/local/share/octave/4.1.0+/m/plot/draw/plot.m
    line =

       216   229



That way, the file-editor-tab.c/h files could be programmed to the proper
framework conventions and the dodgy cross-thread code could be kept somewhere
else for eventual replacement.  From what I remember, that returned structure
for dbstatus is in an octave_value_list.


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]