[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation into dock widgets
From: |
John Swensen |
Subject: |
Re: Separation into dock widgets |
Date: |
Sat, 30 Apr 2011 19:51:07 -0400 |
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
- Re: Separation into dock widgets, (continued)
- Re: Separation into dock widgets, John Swensen, 2011/04/30
- Re: Separation into dock widgets, Jacob Dawid, 2011/04/30
- Re: Separation into dock widgets, John W. Eaton, 2011/04/30
- Re: Separation into dock widgets, John W. Eaton, 2011/04/30
- Re: Separation into dock widgets, John Swensen, 2011/04/30
- Re: Separation into dock widgets, Jacob Dawid, 2011/04/30
- Re: Separation into dock widgets,
John Swensen <=