gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] gplot (was: wave storage)


From: Felix Salfelder
Subject: Re: [Gnucap-devel] gplot (was: wave storage)
Date: Sun, 5 Oct 2014 19:08:56 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Abhinav.

On Sun, Oct 05, 2014 at 02:56:42PM +0000, Abhinav singh wrote:
> Along with breaking the loop click on New button serve one more
> purpose. It invokes the append_page() function and if you are going to
> change this then you have to think how to invoke this function.

there are other situations, where one might want to call gui functions
from the gnucap thread. see the gui-thread branch for two possible
implementations (-DUGLY_POLLING switches to the second).

> There is no frozen window problem here both windows (i.e. analyzer and
> gnucap main terminal) are active. Just once run the code from
> AbhinavSingh-WIP without any modification if it works then we will go
> on one by one with the changes you had made after that(may be
> helpful).

the code from AbhinavSingh-WIP does not work for me. that's why i have
changed it. the changes are trivial and unrelated. the problem with the
frozen prompt is a race condition that does not happen with gui-thread.

while i'm at it: there is another possible race with GRAPH::graphmap.
for example, how do you make sure that
delete graph->graphmap[_title]; (from CMD_PLOT::do_it)
does not interfere with the plotter? (curiously, a similar problem also
affects to the wave storage rewrite...)

> Actually i post ponded some works to do in my inter-semester break
> which includes this left pane thing and a command shell.

i see, so there's no need to search the code :)

> >> multiple windows require multiple threads. but gtk takes care of this.
> >> i think it's best to start just one pthread. but i'm not sure whether
> >> multiple windows make sense already -- maybe i want a command window or
> >> something like it later on.
> >
> command window?Elaborate please.

it might make sense to access the command prompt from the graphical ui.
(i haven't thougt about how to do this in detail...)

then it *might* make sense to have graphical widgets controlling the
simulator (load netlist/run simulation/whatever). i don't have an urgent
need for this, nor will i implement it. maybe someone else? i guess that
a command prompt delegation is a sort of prerequisite.

> > i have implemented a simple example of how (i think) gnucap should
> > communicate with the gui thread. please checkout the "gui-thread" branch
> > and have a look. it is not fully complete, but it should be pretty
> > obvious.
> >
> Ya sure, but need little time.

that's fine.

cheers
felix



reply via email to

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