octave-maintainers
[Top][All Lists]
Advanced

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

synchronize gui's debug actions with the octave core thread (bug #41139)


From: Daniel J Sebald
Subject: synchronize gui's debug actions with the octave core thread (bug #41139)
Date: Sun, 12 Jan 2014 21:01:33 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

Torsten,

I see you added a mutex-protected queue to make the debugger more robust. I like the queue and making the debugger more robust has been a goal I worked on. I would like to point out that with the queue you added this is getting very close to what I did with the prototype "background queue". It's not too difficult to add such a thing. Foreground queue is the existing commands visible to the user (e.g., typing at the command line) and background queue would be commands not visible to the user (initiated by the GUI in response to debugger action, for example). The idea is that with a generic background queue the GUI could send any command.

This construct:

      if (debug == "step")
        Fdbstep ();
      else if (debug == "cont")
        Fdbcont ();
      else if (debug == "quit")
        Fdbquit ();
      else
        Fdbstep (ovl (debug.toStdString ()));

would be much nicer, in my opinion, if done more directly as say:

  // There are no output arguments for dbstep.
  emit queue_background_octave_command ("dbstep ('out');", 0);

  // There are no output arguments for dbcont.
  emit queue_background_octave_command ("dbcont ();", 0);

  // There are no output arguments for dbquit.
  emit queue_background_octave_command ("dbquit ();", 0);

More sophisticated variations on the above would be:

  QString command;
  command = "dbstop (\"" + function_name + "\", ";
  command += QString ().setNum (line) + ");";

  // There is only one output argument for dbstop.
  emit queue_background_octave_command (command, 1);

It's much more direct and generic than queuing intermediate pseudo commands that are then processed to call callbacks.

My point is, things are getting really close (as a result of successive mods for solving existing problems) to a simple, generic way to communicate commands (and data) to/from each of the threads in the system. If you are interested, there are some diff files attached to this patch:

http://savannah.gnu.org/patch/?8016

Dan


reply via email to

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