octave-maintainers
[Top][All Lists]
Advanced

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

Re: Testing MXE-Octave


From: PhilipNienhuis
Subject: Re: Testing MXE-Octave
Date: Tue, 12 Feb 2013 10:23:06 -0800 (PST)

Daniel Sebald wrote
> On 02/12/2013 02:17 AM, Philip Nienhuis wrote:
>> Torsten wrote:
>>> On 11.02.2013 23:14, PhilipNienhuis wrote:
>>>> John W. Eaton wrote
>>>>> On 02/11/2013 01:38 PM, Philip Nienhuis wrote:
>>>>>
>>>>>> Here's some feedback on the most obvious glitches I found in the
>>>>>> previous version (with 3.7.1 snapshot):
>>>>>>
>>>>> 
> <snip>
>>>>>>
>>>>>> - The GUI's workspace pane isn't functional - entering something
>>>>>> like "a
>>>>>> = 10" doesn't make a show up in the workspace.
>>>>>
>>>>> Yeah, there are lots of problems with the GUI. I don't think that
>>>>> these
>>>>> problems are specific to the MXE cross build.
>>>>
>>>> IIRC it worked OK with the 3.7.1 snapshot on Linux, so I suspect is
>>>> *is*
>>>> related.
>>>> The UPM version (admittedly based on 3.6.2) doesn't have this issue.
>>>> On all
>>>> recent Linux builds I've made the workspace pane works good as well.
>>>
>>> AFAIK the workspace is updated by a timer and the UPM version does not
>>> use timers (Israel, please correct me if I am wrong). This might explain
>>> why the workspace of the MXE version does not work when the start of a
>>> timer fails at the beginning.
>>
>> That would fit in nicely with the "QObject::timer cannot be started from
>> main thread"-like messages at startup.
> <snip>
> Not sure.  If I'm understanding correctly, the timer isn't associated 
> with the window pane, it is associated with the main thread because it 

My bad, sorry, error message should read:

"QObject::startTimer: timers cannot be started from another thread"


> is only the main thread where the symbol table can be accessed. 
> Associating the timer with the window pane would work only if the symbol 
> table were in some shared memory and then there was a semaphore to 
> protect from the secondary thread from accessing a changing symbol 
> table.  That is my understanding of things right now and I welcome any 
> verification or better explanation.
> 
> Getting back to my last post, why use the timer if the symbol table 
> can't be freely accessed at approximately 0.5 second intervals?  Just 
> wait until the core finishes, i.e., returns to the command line and then 
> access the symbol table and refresh the Qt tree.





--
View this message in context: 
http://octave.1599824.n4.nabble.com/GUI-doesn-t-appear-when-using-run-octave-tp4644161p4649799.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


reply via email to

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