bug-apl
[Top][All Lists]
Advanced

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

Re: [Bug-apl] Implementing realtime variable viewer support


From: Elias Mårtenson
Subject: Re: [Bug-apl] Implementing realtime variable viewer support
Date: Sat, 15 Feb 2014 19:55:08 +0800

Awesome. I'll add support for this tonight or tomorrow.

Regards,
Elias


On 15 February 2014 19:48, Juergen Sauermann <address@hidden> wrote:
Hi Elias,

I believe deriving from class Symbol is not the right way because there can be multiple
pointers to the original symbol around and when you simply replace a symbol in class Workspace
then you have a mix of the original and the new derived symbol.

I have therefore added a callback function in class Symbol that is called on changes of the symbol.

Use it like this:

void my_monitor(const Symbol & symbol, Symbol_Event sev)
{
   // ...
}

Symbol * monitored = ...

monitored->set_monitor_callback(my_monitor);   // start monitoring
monitored->set_monitor_callback(0);                    // stop monitoring

See SVN 124.

/// Jürgen



On 02/12/2014 05:58 AM, Elias Mårtenson wrote:
I was watching this video where they take advantage of the )ED command in Dyalog which supports realtime updated views of a variable: http://youtu.be/a9xAKttWgP4?t=5m2s

At 5:02 into the above video, the presenter types )ED variablename which opens a window that with the content of a variable. This is a very neat feature.

Obviously, I wanted to see the same thing in GNU APL (for myself, I'd like to see it in an Emacs buffer). So, I started work on this (exactly what method should be used to invoke this feature is a subject for a separate email thread which I will post shortly).

The key feature that is needed is a way to be informed when a variable is changed. Changes to a variable seems to be done through calls to method of Symbol. The key methods are Symbol::assign(), Symbol::assign_indexed() and Symbol::push_value().

The approach I started experimenting with is to create a subclass of Symbol which provides callback functionality when these methods are called, which I can then use to send a message to Emacs when the values are changed. I'm not done with this yet, so I'm not ready to say if this say if it works fully at this point.

Now, I would like to know three things:
  • Is my approach of subclassing Symbol the best way to do it? Assuming it is, the question is:
  • How should I create the new subclassed symbol as a copy of the old one? Would it make sense to create a copy constructor for this class that the subclass can take advantage of?
  • Finally, I'd need to expose a function on Workspace that allows me to replace a symbol with my monitorable (is that a word?) version.
I suppose an alternative approach to all of this would be to add the callback functionality right into the Symbol class, but that would have negative potential performance implications.

What are your thoughts on this?

Regards,
Elias



reply via email to

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