Sorry, can't help more than that. And this problem will be the same in
any toolkit you would use, not just IUP.
Best,
Scuri
Em 11/08/2015 11:52, Jörg F. Wittenberger <joerg.wittenber...@softeyes.net>
escreveu:
> Am 11.08.2015 um 16:31 schrieb "Jörg F. Wittenberger":
> > Am 11.08.2015 um 16:27 schrieb Antonio Scuri:
> >> Maybe you can try the IDLE and see how it behaves.
> >>
> >> There is also another possibility. The IDLE callback is somewhat
> >> equivalent of
> >>
> >> while(IupLoopStep() != IUP_CLOSE)
> >> {
> >> do something
> >> }
> >
> > Not too bad. Though that's essentially the loop my program is sitting
> in.
> >
> > "do something" would be in my app "1. do Iup-Calls 2. poll i/o"
> >
> > But if I don't have *any* IupFlush in there, than I don't see any
> > progress ever. That's confusing me.
>
> Turns out that's not completely true.
>
> If "do something" does wait some time, than I'm in the same position as
> if IupMailLoop would simply sit idle until it fires the timer.
>
> In practice: it takes forever.
>
>
> >
> >
> >> But this is also high CPU consuming.
> >>
> >> So, to avoid this, you can try:
> >>
> >> while(IupLoopStepWait() != IUP_CLOSE)
> >> {
> >> do something
> >> }
> >>
> >> But I would start with the IDLE. In GTK is much better handled than in
> >> Windows.
> >>
> >> Best,
> >> Scuri
> >>
> >>
> >> On Tue, Aug 11, 2015 at 11:09 AM, "Jörg F. Wittenberger" <
> >> joerg.wittenber...@softeyes.net> wrote:
> >>
> >>> Sorry again.
> >>>
> >>> I've been distracted and did not read to the end of your message.
> >>>
> >>> Am 11.08.2015 um 15:39 schrieb Antonio Scuri:
> >>>> Ok. Now I see.
> >>>>
> >>>> IupFlush is usually used when you need to processes messages after
> >>>> changing elements attributes that need to be updated by the system.
> >>>>
> >>>> I would recommend using IupMainLoop and something else for the
> database
> >>>> connections, not the way around using IupFlush.
> >>>>
> >>>> There are several ways how to pool secondary systems:
> >>>>
> >>>> - Use a second thread to processes it (frequently used)
> >>>
> >>> That's the "complicated" way I can see. Have an embeddes
> >>> Lua-Interpreter executed dynamically generated Lua code.
> >>>
> >>>> - Use a IupTimer to check from time to time if there is something to
> be
> >>>> processed on it (limited by a minimum time interval for not too fast
> >>>> processing)
> >>>
> >>> That's what we startet with. But since I can't make the timer return
> >>> "right now", it will hopelessly slow down the application. To no
> >>> usable. Example: e few hundred results to be read from the database
> and
> >>> display in a matrix. Takes forever while Iup is sitting most of the
> >>> time in idle until the timer will check for i/o and notice a new item.
> >>>
> >>>> - Use the IDLE callback to process it (high CPU use since it will be
> >>>> running all the time)
> >>>
> >>> As you said: that's the CPU hook. I read that in the docs and thought
> >>> there must be a better way.
> >>>
> >>> Sorry again for the incomplete reply before.
> >>>
> >>> /Jörg
> >>>
> >>>>
> >>>> Best,
> >>>> Scuri
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Aug 11, 2015 at 10:11 AM, "Jörg F. Wittenberger" <
> >>>> joerg.wittenber...@softeyes.net> wrote:
> >>>>
> >>>>> Sorry for following up on my own message.
> >>>>>
> >>>>> I just considered the problem again and got stuck.
> >>>>>
> >>>>> Am 11.08.2015 um 14:04 schrieb "Jörg F. Wittenberger":
> >>>>>> Am 10.08.2015 um 19:20 schrieb Antonio Scuri:
> >>>>>>> Well, I really don't know.
> >>>>>>>
> >>>>>>> Just know that the calls are not actually "active all at the same
> >>>>> time".
> >>>>>>> When you call IupFlush in one of them, it will stop that one,
> >>> processes
> >>>>> the
> >>>>>>> pending messages one by one, then return to that one. If that can
> >>> occur
> >>>>>>> recursively then it is a real nightmare to manage. You will have a
> >>> hard
> >>>>>>> time to know what is the order that things are happening.
> >>>>>>
> >>>>>> Ah' I see.
> >>>>>
> >>>>> Maybe I don't really see.
> >>>>>
> >>>>> So when exactly SHOULD I call IupFlush? Which one is the strategy
> >>>>> natural to Iup. Changing the app side of things is simple. There is
> >>>>> not so much to change by now. I'm still exploring/learning the
> toolkit.
> >>>>>
> >>>>> So far the first strategy I tried was to simply run IupMainLoop and
> call
> >>>>> Iup functions from the callbacks.
> >>>>>
> >>>>> This did work as long as there Iup was the only source of events to
> be
> >>>>> considered. But there is some i/o going on (database connections
> etc.).
> >>>>> So I switched to the next strategy :
> >>>>>
> >>>>> 2nd: In a loop
> >>>>> 1. Call all Iup* things to build the GUI as app logic suggests at
> this
> >>>>> point in time.
> >>>>> 2. Call IupFlush. (Former version: call IupLoopStep and IupFlush
> if
> >>>>> that does not return IUP_CLOSE, but that seemed to add no value over
> >>>>> just IupFlush.)
> >>>>> 3. Poll other I/O for a moment. Goto 1 processing the results.
> >>>>>
> >>>>> This did work most of the time, but sometimes it would just not
> result
> >>>>> in updates as expected. Turned out some calls (I don't recall which
> one
> >>>>> it where) would executed in (1.) call callbacks again. (I recall
> having
> >>>>> read about this in the docs, so no surprise here so far.)
> >>>>>
> >>>>> At this point I had to do wild guess work how I should handle this.
> >>>>>
> >>>>> Option A: Record the callbacks job to be execute later and return
> >>>>> immediately.
> >>>>> Option B: Execute the Job right now.
> >>>>>
> >>>>> The former resulted eventually in the segfaults during IupFlush in
> step
> >>>>> (2). To I settled so far on Option B. But this required me to Call
> >>>>> IupFlush also in the recursive invocation.
> >>>>>
> >>>>>
> >>>>> So, to repeat myself: which strategy is natural to Iup?
> >>>>>
> >>>>> When must I call IupFlush?
> >>>>>
> >>>>> As I'm reading your reply, I'd understand that calling IupFlush from
> >>>>> withing callbacks is no good idea, correct?
> >>>>>
> >>>>> If so: how would I make those changes take effect? Because: if I
> call
> >>>>> "too many" (whatever that is _I_ have no way to know) Iup* things
> (e.g.
> >>>>> IupDestroy) from within a single callback, then I get the segfault.
> >>>>>
> >>>>>
> >>>>> Thanks so much
> >>>>>
> >>>>> /Jörg
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Maybe it's a good idea to add a remark pointing this out in the
> manual.
> >>>>>> Me, reading the manual, gathered that calling IupFlush would never
> >>>>>> hurt, just advance the processing at the Iup side of things.
> >>>>>>
> >>>>>>> I would recommend you to get a step back are rethink that
> strategy.
> >>>>>>
> >>>>>> So far this never became a strategy. It failed straight in the
> first
> >>>>>> experiment. It's just my missunderstanding of the docs and an
> >>>>> experiment.
> >>>>>>
> >>>>>>> Independent from IUP, or other toolkits, what you are trying to
> >>>>> implement?
> >>>>>>
> >>>>>> There is a very simple RDF/DublinCore inspired inventory application
> >>> for
> >>>>>> a small archive (archive of physical things, kind of a museum - not
> the
> >>>>>> family of file formats). I'm using it as "personal wiki" for my
> notes
> >>>>> too.
> >>>>>>
> >>>>>> The original is a web app. I'm trying replace the Web-Interface
> with a
> >>>>>> native GUI.
> >>>>>>
> >>>>>> /Jörg
> >>>>>>
> >>>>>>
> >>>>>>> Best,
> >>>>>>> Scuri
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Aug 8, 2015 at 9:58 AM, "Jörg F. Wittenberger" <
> >>>>>>> joerg.wittenber...@softeyes.net> wrote:
> >>>>>>>
> >>>>>>>> ((Sorry, this is not exactly the message I want to reply to, but
> at
> >>>>>>>> least it's the correct thread. (The other message is already gone
> >>>>> here.)))
> >>>>>>>>
> >>>>>>>> I managed to understand the problem a little better.
> >>>>>>>>
> >>>>>>>> Maybe I'm dong something against the philosophy of correct Iup
> usage
> >>>>> here?
> >>>>>>>>
> >>>>>>>> What's happened is that the action callback from my apps
> back-button
> >>> is
> >>>>>>>> called as often as I click it. Eventually my action callback will
> >>> also
> >>>>>>>> call IupFlush. (Is this a No-No?) This IupFlush in turn enables
> the
> >>>>>>>> next action callback to be activated. Thus there are 4-5 calls
> >>> active
> >>>>>>>> at the same time.
> >>>>>>>>
> >>>>>>>> Each of those calls does essentially the same: recreate scrollbox
> >>> full
> >>>>>>>> of controls (from different data sets). Then detach the (only)
> child
> >>>>> of
> >>>>>>>> the target container, IupDestroy that detached child, IupAppend
> the
> >>> new
> >>>>>>>> one and IupRefresh the container.
> >>>>>>>>
> >>>>>>>> Since the data set is different, those action callback take a
> >>> different
> >>>>>>>> amount of time (while waiting for the data base etc.).
> >>>>>>>>
> >>>>>>>> By throwing in some additional calls to IupFlush into the code
> (I'd
> >>>>>>>> believe this _should_ not hurt, shouldn't it?) I've been able to
> get
> >>> it
> >>>>>>>> all mixed up. Up to the point that controls belonging to
> different
> >>>>> data
> >>>>>>>> sets / callbacks ended up mixed into the same container.
> >>>>>>>>
> >>>>>>>> To put it in other words: those nested action callbacks in
> >>> combination
> >>>>>>>> with IupFlush enabled me to (accidentally) implement a kind of
> green
> >>>>>>>> threads on top of Iup. Unfortunately without proper locking.
> >>>>>>>>
> >>>>>>>> Having too few IupFlush's there will result in the segfault. More
> >>>>>>>> flushes make it appear to work. Even more flushes confuse the
> layout
> >>>>>>>> logic.
> >>>>>>>>
> >>>>>>>> How should this being done right?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>>
> >>>>>>>> /Jörg
> >>>>>>>>
> >>>>>>>> Am 05.08.2015 um 10:50 schrieb "Jörg F. Wittenberger":
> >>>>>>>>> Hi Antonio,
> >>>>>>>>>
> >>>>>>>>> during IupFlush my program dumped a core like this:
> >>>>>>>>>
> >>>>>>>>> Program terminated with signal SIGSEGV, Segmentation fault.
> >>>>>>>>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
> >>>>>>>>> /usr/local/lib/libiup.so
> >>>>>>>>> (gdb) bt
> >>>>>>>>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
> >>>>>>>>> /usr/local/lib/libiup.so
> >>>>>>>>> #1 0x00000000 in ?? ()
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Anything I can do to help debugging that one?
> >>>>>>>>>
> >>>>>>>>> Best
> >>>>>>>>>
> >>>>>>>>> /Jörg
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Iup-users mailing list
> > Iup-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/iup-users
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Iup-users mailing list
> Iup-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/iup-users
>
>
------------------------------------------------------------------------------
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
