- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Input Sensor fix

by StÃ©phane Ducasse

mickael I loaded the kernel 304 but copy and paste does not work Am I missing an initialize? On Apr 22, 2009, at 9:48 PM, Michael Rueger wrote: > Mariano Martinez Peck wrote: > >> I tried this and: >> >> - Select text with shift works ok. >> - Short cuts are with alt + x , alt + v instead of ctrl + x or ctrl >> + v >> - Swap mouse button doesn't work. > > Thanks for testing! > OK, so another round of digging through crap... > > This stuff HAS TO GO... It's piled crap on history on crap... > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2009

Re: [Pharo-project] Input Sensor fix

by StÃ©phane Ducasse

so I will integrate now. because this is important :) Stef On Apr 22, 2009, at 1:42 PM, Michael Rueger wrote: > Hi all, > > in the Pharo inbox there is now > Kernel-michael_rueger.renggli.304 > > integrated John's Mac menu fixes > fixed problems with shift cursor > fixed and cleaned up input sensor/fetcher installation > > After loading the package you need to execute > InputEventSensor installPollingEventSensorFramework > > > Hopefully this will fix all the recent issues around input events. > > Thanks to all contributors and testers! > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2009

Re: [Pharo-project] Closure simulation errors

by StÃ©phane Ducasse

Thanks I will do an integration later today. Now I have to work on more boring stuff. On Apr 22, 2009, at 9:17 PM, Nicolas Cellier wrote: > As a follow-up, I missed one important change in 'Closure Usage > Fixes.1.cs' > ContextPart>>#runSimulated:contextAtEachStep: > > Load PharoInbox/Kernel-nice.renggli.305 to repair that. > Small progress: the ClosureCompilerTest errors now turned into > failures... > Now, we have to find another mismatch somewhere... > I think it is in Encoder and related to > http://code.google.com/p/pharo/issues/detail?id=743 > > Nicolas > > 2009/4/21 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Since I'm not sure it's the same issue, you have two... >> >> http://code.google.com/p/pharo/issues/detail?id=761 >> http://code.google.com/p/pharo/issues/detail?id=762 >> >> 2009/4/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> can you add an issue on the bugtracker? >>> >>> On Apr 21, 2009, at 1:09 AM, Nicolas Cellier wrote: >>> >>>> You certainly noticed a lot of Closure related tests fail. >>>> A few because of unavailable BlockContext API in BlockClosure... >>>> (most >>>> are fixed yet) >>>> But mainly because of tests messing with: >>>> >>>> MethodContext>>#runSimulated:contextAtEachStep: >>>> >>>> I think something is broken there... One missing or not up to date >>>> change from Eliot probably. >>>> >>>> Also there is a problem in the debugger: when halted in a Closure, >>>> executing restart then proceed won't restart correclty: >>>> Example: >>>> 1) Execute this : >>>> (ScriptLoader new buildConfigurationMapFor: #('foobar.blast')) >>>> load >>>> 2) Open the debugger (click debug) >>>> 3) select top but one context >>>> [] in ScriptLoader>>buildConfigurationMapFor: >>>> 4) click restart, then proceed >>>> >>>> You get Character doesNotUnderstand: #encodeForHttp >>>> a real mess, as if evaluating the code in wrong context... >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2009

Re: [Pharo-project] FFI and Pharo

by StÃ©phane Ducasse

can you add that to the wiki :) Stef On Apr 22, 2009, at 3:34 PM, Mariano Martinez Peck wrote: > Hi! > > Smalltalk listLoadedModules > SmalltalkImage current listLoadedModules > > To load FFI package: > > ScriptLoader loadFFI. > > Cheers, > > Mariano > > On Wed, Apr 22, 2009 at 6:42 AM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr > > wrote: > Hi All, > > I was wondering whether the FFI is included in the Pharo VM. Is there > an easy way to check this? > > Regards, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2009

Re: [Pharo-project] Hack to make mac menus work in post pharo0.1-10284dev09.04.4

by StÃ©phane Ducasse

On Apr 22, 2009, at 1:08 PM, Michael Rueger wrote: > Nicolas Cellier wrote: >> It is because InputEventFectcher does not take care to stop the >> fetcherProcess. >> I think it should: >> >> InputEventFectcher >>shutDown >> fetcherProcess ifNotNil: [fetcherProcess terminate]. >> inputSemaphore ifNotNil: [Smalltalk unregisterExternalObject: >> inputSemaphore] >> >> At least, it should do it on deinstall... > > I've integrate your suggestions, thanks! Where ;)? > > >> IMO, it has been adopted too soon, and we should better revert >> temporarily with such a hack. > > Well, yes and no. > > Yes, it could have used a bit more testing, but the truth is that very > few people test stuff that is not in the update stream. > > No, we are still in alpha and anybody expecting the bleeding edge > version of Pharo to be stable enough for everyday work after every > single update doesn't know what "alpha" means. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 23, 2009

Re: [Pharo-project] Pharo windows hanging ...

by Eagle Offshore

I assume c and d will get fixed (since doing animation from worker threads is pretty much the point). b - well of course you can't do UI work from FFI - you're not on the UI thread - unless you call performSelectorOnMainThread:... from there. a - I dunno - it seems like squeak's vm ought to do most work not on the UI thread except for UI things but the runtime models aren't exactly what I'd call fundamentally compatible since Cocoa wants to own the runloop and just call you back now and then via delegates or notifications. I have a Cocoa MIDI/CoreAudio AudioUnits host that makes heavy use of coreaudio (which ends up spawning a few dozen threads) but still animates pictures of keyboards, sound meters, etc.... in near real time and does it all by calling performSelectorOnMainThread:... and it all works like a charm so long as I remember to invoke the graphics update routines via performSelectorOnMainThread:. I would like to try out the new Cocoa bridge on a Mac at some point and see what can be done with it. -Todd Blanchard On Apr 22, 2009, at 10:30 PM, John M McIntosh wrote: > Ok, I have to comment since i'm up to my neck with alligators over > performSelectorOnMainThread: In fact just this evening 4 hours toasted > to document a bug with this call with Apple for tomorrow. > > (a) people don't realize with the carbon os-x vm we run on the Main > Thread and poll for os-x events that then get dispatch to the squeak > vm event handlers. > This leads to the interesting jerky non-responsive feedback you get > with the VM when you accidently kill the morphic polling loop, since > we aren't servicing > the UI event polling fast enough since we are using a fallback 1/2 > second ancient piece of code that in the past looked for the > interrupt key. > > (b) If you use the Unix os-x vm, that spins the squeak thread off as a > background task, now if you do UI related work via FFI then you die. > > (c) performSelectorOnMainThread: has lots of interesting bugs on the > iPhone, especially if you try to do view animation with it. > > (d) the iphone vm runs as a background thread, but deadlocks with > UIWebView between it and the main thread, are interesting, all > solvable, but interesting. Fortunately in the future we can migrate > back to (a) on the iPhone. > > (e) if you run on the Main Thread then you need something to handle > event callbacks from the UI when you call the UI to service a UI > event. Fortunately this has been worked out and is easier than (d) > > Frankly (a), (b), (c) and did I mention (d) are serious complications > I could do without. > > On 22-Apr-09, at 9:17 PM, Eagle Offshore wrote: > >> >> On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote: >> >>> But this is not the only UI framework which hates the concurrency - >>> take a look at "groundbreaking" Mac OS :) >> >> yes, but they have a nice mechanism for dealing with this when a >> worker thread wants to update the UI >> >> - (void)performSelectorOnMainThread:(SEL)aSelector withObject: >> (id)arg waitUntilDone:(BOOL)wait; >> >> Is there a Squeak equivalent for getting something invoked on the >> main UI thread? >> >> -Todd Blanchard >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 23, 2009

[Pharo-project] Call Graph Optimization in PHARO?

by stepken

Hi! Before that refactoring and traits implementation stuff did you do any Call Graph Optimization? I mean, in Smalltalk, especially Squeak as being a 'reflective' language this should be done first to minimize cross side incompatiblity effects with older squeak packages, which happen to appear all the time. regards, Guido Stepken

April 23, 2009

Re: [Pharo-project] Pharo windows hanging ...

by Michael Rueger

John M McIntosh wrote: > Ok, I have to comment since i'm up to my neck with alligators over > performSelectorOnMainThread: In fact just this evening 4 hours toasted > to document a bug with this call with Apple for tomorrow. > > (a) people don't realize with the carbon os-x vm we run on the Main > Thread and poll for os-x events that then get dispatch to the squeak > vm event handlers. > This leads to the interesting jerky non-responsive feedback you get > with the VM when you accidently kill the morphic polling loop, since > we aren't servicing > the UI event polling fast enough since we are using a fallback 1/2 > second ancient piece of code that in the past looked for the > interrupt key. This is gone in the new event sensor design. Michael

April 23, 2009

Re: [Pharo-project] Pharo windows hanging ...

by John M McIntosh

Ok, I have to comment since i'm up to my neck with alligators over performSelectorOnMainThread: In fact just this evening 4 hours toasted to document a bug with this call with Apple for tomorrow. (a) people don't realize with the carbon os-x vm we run on the Main Thread and poll for os-x events that then get dispatch to the squeak vm event handlers. This leads to the interesting jerky non-responsive feedback you get with the VM when you accidently kill the morphic polling loop, since we aren't servicing the UI event polling fast enough since we are using a fallback 1/2 second ancient piece of code that in the past looked for the interrupt key. (b) If you use the Unix os-x vm, that spins the squeak thread off as a background task, now if you do UI related work via FFI then you die. (c) performSelectorOnMainThread: has lots of interesting bugs on the iPhone, especially if you try to do view animation with it. (d) the iphone vm runs as a background thread, but deadlocks with UIWebView between it and the main thread, are interesting, all solvable, but interesting. Fortunately in the future we can migrate back to (a) on the iPhone. (e) if you run on the Main Thread then you need something to handle event callbacks from the UI when you call the UI to service a UI event. Fortunately this has been worked out and is easier than (d) Frankly (a), (b), (c) and did I mention (d) are serious complications I could do without. On 22-Apr-09, at 9:17 PM, Eagle Offshore wrote: > > On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote: > >> But this is not the only UI framework which hates the concurrency - >> take a look at "groundbreaking" Mac OS :) > > yes, but they have a nice mechanism for dealing with this when a > worker thread wants to update the UI > > - (void)performSelectorOnMainThread:(SEL)aSelector withObject: > (id)arg waitUntilDone:(BOOL)wait; > > Is there a Squeak equivalent for getting something invoked on the > main UI thread? > > -Todd Blanchard > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 23, 2009

Re: [Pharo-project] Pharo windows hanging ...

by David T. Lewis

On Wed, Apr 22, 2009 at 09:17:12PM -0700, Eagle Offshore wrote: > > On Apr 22, 2009, at 11:38 AM, Igor Stasenko wrote: > > >But this is not the only UI framework which hates the concurrency - > >take a look at "groundbreaking" Mac OS :) > > yes, but they have a nice mechanism for dealing with this when a > worker thread wants to update the UI > > - (void)performSelectorOnMainThread:(SEL)aSelector withObject:(id)arg > waitUntilDone:(BOOL)wait; > > Is there a Squeak equivalent for getting something invoked on the main > UI thread? WorldState class>>addDeferredUIMessage:

April 23, 2009