Re: Separation into dock widgets

[John Swensen]

On Apr 30, 2011, at 7:29 PM, Jacob Dawid wrote:

> I could reproduce the error and fixed it with dup(). Copying over the values 
> makes sense, because they serve as the model portion for the variable view. 
> Of course, it would be better to reuse the variables allocated by octave, but 
> since accessing them is not thread-safe there is not other way of doing this. 
> I saw you have implemented another model struct about the model portion (a 
> "metamodel"), but that does not solve the issue, it's just replicating what 
> we already have (a model part). You simply stored just a few infos about the 
> variable, but not the value, so the value is not accessible (or only 
> available at request, but then it needs to be copied anyways when requested) 
> - but I want that :)
> 
> You see, there are currently only two real options that solve the issue 
> without sustaining a loss in functionality:
> 
> 1.) Octave guarantees threadsafe access, so its data can be used as a model 
> portion. Advantage: Saves memory in Quint. Disadvantage: Will be slower even 
> if thread-safety is not needed in Octave.
> 
> 2.) Quint does a deep copy. Advantage: Octave performs fast. Disadvantage: 
> Quint requires more memory.
> 
> I rather go for solution 2.).
> 
> As for the windows: History, Workspace and FileView can each be switched off 
> by right clicking on the title and checking them off. I have reverted my 
> changes to make everything dockable again in the current branch since many 
> things were not working correctly. As the Qt docs say 
> (http://doc.qt.nokia.com/latest/qmainwindow.html), having not a central 
> widget is not supported. However I assigned it a dummy widget, but that 
> caused problems when restoring the window state at startup, even when I 
> assigned proper object names. What we really need here is an MDI: 
> http://doc.qt.nokia.com/latest/qmdiarea.html
> 
> 

I would still argue that a copy of every current scope (and global scope) 
variable is the wrong choice.  You have essentially halved the amount of 
available memory for any given stopping point (whether that be a breakpoint 
scope or at the workspace scope).  This is a big problem for any research 
involving large datasets (which encompasses many, many fields of research and 
is becoming more and more prevalent).  Maybe we should create a "dataless" 
symbol_record class.  Then we can have the best of both worlds.  The UI gets 
all relevant information about the variables of various scopes while using a 
minimal amount of memory, and the user can request variables as necessary.  
Maybe it makes sense to have the "dataless" symbol_record actually be smart 
about which variables carry data and which don't so the UI can display 
variables that are smaller than a pre-specified size (e.g. scalars, small 
vectors, etc.).

Doubling the memory consumption of Octave when using the GUI will be a 
deal-breaker for many, many users.

John Swensen