> Behalf Of Oleg Kobchenko
>
Oleg, I appreciate your insights a lot (more below).
> Here is an example of forced isigraph
>
> load'plot'
> stat=: 3 : '(''title '',":y)plot $0'
> countdown=. ''"_@:(<"0@:|.@:i.@:[ >@:((stat@:[ ] 6!:3@:])&.>/@:(|.@:[ ,
> <@:])) ])
> 10 countdown 1
>
>
> From: Oleg Kobchenko <[EMAIL PROTECTED]>
> To: Beta forum <[email protected]>
> Sent: Wednesday, June 28, 2006 6:33:04 PM
> Subject: Re: [Jbeta] Tardy graphics (again)
>
>
> Do you remember, why COM has the appartment
> threading model?
I am afraid I do not even know what COM is; I mentioned a C GUI interface
solution only because it was suggested by J/C programmers, or are they C/J
programmers? Either way I will ask them to read your entire response.
>
> A proper way to achieve a long-running task (not necessarily process)
> with GUI status updates is to run the task on a separate thread
> with a callback for updates, which is sync'd on the main thread.
>
> Alternatively it could be a separate process and some
> kind of asynchronous communication like pipes or sockets.
A particular real-time application works along these lines. One part does
the work and a second part displays summary information via OpenGL. I
understand, now, that it should work but we have not test it yet because I
am told that the second part will need considerable reprogramming to move
from J5 to J6.
I guess this is a price that we have to pay for a better OpenGL interface
and for the stated policy to favor newcomers. Yet, new users eventually
become old users, hopefully, and a majority would end supporting the comfort
of a minority (or maybe for that very same reason old users would not ever
become a clear majority?). At any rate, I do appreciate the improved J6
performance.
> In addition, the alternative to callbacks would be polling the
> communication end for data ready hooked on timer or so.
>
> As a quick solution, you could draw your status in a
> window with isigraph, which supports forced updates.
>
> There is no magic here, if you do the same without the above
> in any C++ or Java application, it would behave the same as J 601.
> (It did not in j504 because, I believe it used a separate thread
> for the interpreter, hence Ctrl+Break vs break icon, which
> allowed to updates the session view in the main loop).
That is what happens when one is spoiled (one throw tantrums when the
spoiling stops and it is for a good reason).
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
