- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit: history support and OB icons

by StÃ©phane Ducasse

Apparently my tests were wrong. Now I do not understand since when I run the tests the icons do not change. Stef On Nov 20, 2008, at 8:17 PM, David RÃ¶thlisberger wrote: > >> I loaded the fix of John for the menu >> and the changes for SUnit icons and my image freshes when I open >> the Package browser and run the tests >> in 10162 > > which tests? All tests? > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 20, 2008

Re: [Vm-dev] Re: [Pharo-project] Event history question

by Igor Stasenko

2008/11/20 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > Ok, tthe TheInterruptSemaphore is signalled in checkForInterrupts() via > usage of setInterruptPending(). > > As far as I know the only place that it is used is by the VM host platform > keyboard handling logic > only *IF* you are using an image that predates EventSensor (Aug 2000) > > Now since most people use an image that has this class what happens is > > (a) The process running EventSensor>>processEvent: looks at the incoming > VM generated keyboard event and > if it decides that the keys pressed meet it's criteria of what an interrupt > is then it signals in the EventSensor interruptSemaphore > That then wakes up the interrupt watcher process > > InputSensor>>userInterruptWatcher > running at Processor lowIOPriority. > > This means of course the process that is running EventSensor>>processEvent: > has to be able to run. > You could simplify things here and fork off the userInterruptWatcher logic > in EventSensor>>processEvent: > and as I think Michael noticed rip out the InterruptWatcherProcess and > InterruptSemaphore > Good, it makes sense, if we provide enough guarantees that even ticker process is always running in warm & dry & safe conditions. :) This also makes 1 less process hanging around, because there is no need in setting up the userInterruptWatcher and semaphore for it once you can do it from event ticker like following: (self isInterruptEvent: event) ifTrue: [ interruptHandler isAlreadyRunning ifFalse: [ [self handleInterrupt] forkAt: Processor severePriority ] ] This makes it irrelevant, at which priority the current event handling running and safe from gotchas, pointed by Andreas (in numerous "Sensor anyFooBar" sends spreaded throughout the image). Also, i think, it would be good to guarantee that there is only single Process which making calls to primitive and fetching events from VM - obviously the event ticker process. The rest processes should be allowed to talk with Sensor only through shared queue. -- Best regards, Igor Stasenko AKA sig.

Nov. 20, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by David RÃ¶thlisberger

> I loaded the fix of John for the menu > and the changes for SUnit icons and my image freshes when I open the > Package browser and run the tests > in 10162 which tests? All tests? David

Nov. 20, 2008

Unix host windows. (Was: Re: [Pharo-project] HostWindows rewrite)

by Igor Stasenko

Hello David, Today i took a look at the unix port of squeak, where it deals with host windows.. ouch!! The main file - sqUnixX11.c is a big bloat of C code , which tries to deal with anything at once. ouch!! I'm slowly reading it, trying to understand how it works. The Xlib window management is quite different from what i used to see in windoze. As i understand, it using two windows - one for decoration and to be managed by window managers, and second is for actual squeak content. The number of flags, settings, startup options to set-up a host window is overwhelming. The docs, as for everything in unixes, is quite obscure and often don't tell anything about purpose of option/function - just what it does and what it expects as input. As i see in sqUnixEvent.c , the windowIndex member of events is ignored and set to 0. So at first stage it would require to change functions there to honor a window index. I found some analogies with my windoze code - you are also keep own private registry for host windows and operating with 1-based window handles (i'm using 0-based index). There is a couple of interesting things which i discovered: any action, like window move & size can be completely ignored by window manager. Its quite acceptable within my design: you could try to change any window attribute, but there is no guarantee that it will be changed or affect the host window in any way. There is even no guarantee, that given attribute exists. Of course, common attributes, like x,y,width,height, visibility, title , and maybe couple more will be always there, on all platforms. As for the rest attributes - its up to platform implementation to name them and write accessors to them. 2008/11/9 David T. Lewis <lewis(a)mail.msen.com>: > On Sun, Nov 09, 2008 at 05:05:45PM +0200, Igor Stasenko wrote: >> 2008/11/9 David T. Lewis <lewis(a)mail.msen.com>: >> Oh, that's the bits i'm missing. I found the sources of >> HostWindowPlugin for win and mac, but >> was unable to find anything for X11. Can you please send me a sources >> of it, or link for downloads? > > There is no implementation for X11, but I posted a copy of my imcomplete > work to the vm-dev list here: > > http://lists.squeakfoundation.org/pipermail/vm-dev/2008-July/001977.html > > This does have enough support to permit opening windows, moving them, setting > window label, etc but it is incomplete and is not integrated into Squeak in > any useful way. > >> And of course, i don't see a need in packing X and Y into a single 32 >> bit int as its currently done in HostWindowPlugin. > > Good, that sounds fine. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 20, 2008

Re: [Pharo-project] Event history question

by John M McIntosh

Ok, tthe TheInterruptSemaphore is signalled in checkForInterrupts() via usage of setInterruptPending(). As far as I know the only place that it is used is by the VM host platform keyboard handling logic only *IF* you are using an image that predates EventSensor (Aug 2000) Now since most people use an image that has this class what happens is (a) The process running EventSensor>>processEvent: looks at the incoming VM generated keyboard event and if it decides that the keys pressed meet it's criteria of what an interrupt is then it signals in the EventSensor interruptSemaphore That then wakes up the interrupt watcher process InputSensor>>userInterruptWatcher running at Processor lowIOPriority. This means of course the process that is running EventSensor>>processEvent: has to be able to run. You could simplify things here and fork off the userInterruptWatcher logic in EventSensor>>processEvent: and as I think Michael noticed rip out the InterruptWatcherProcess and InterruptSemaphore On 20-Nov-08, at 7:18 AM, Igor Stasenko wrote: > 2008/11/20 Michael Rueger <m.rueger(a)acm.org>: >> Igor Stasenko wrote: >> >>> If i remember correctly, an interrupt semaphore is used to awake a >>> process which watching for interrupts. >>> And indeed, when key combination matching an interrupt key code, >>> it calls setInterruptPending(), which is then eventually leads to >>> signaling a semaphore which registered as interrupt semaphore. >>> You can't handle it on image side, because you may not have chance >>> to >>> get to it (if there's another process running on same or higher >>> priority than event ticker process). >>> While in VM, regardless what image does, it periodically checks for >>> interrupts, and during handling OS events, it checks if an interrupt >>> key pressed, and if so, then signals the semaphore. >>> At least, this is how it looks on Win32. >> >> The question really was if it is in the VM but rather if it (still) >> should >> be in the VM. >> After some discussions with John I'm pretty sure we can remove the >> interrupt >> semaphore code from the VM. For now that would mean that the image >> code >> still referring to it should/can be removed. >> > > In this case, i'd like to read John's reasoning, why its safe to > remove it from VM. >> From my perspective , it should stay, because you can't imitate same > behavior on language side safely. > >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 = = = ========================================================================

Nov. 20, 2008

[Pharo-project] Polymorph in Pharo

by Torsten Bergmann

The ScriptLoader 665 MCZ in the pharo inbox (which is based on 664 from Marcus) adds a simple load script to load the Polymorph UI framework into pharo. There is no need to patch MC as described in http://wiki.squeak.org/squeak/6005 sine an exception handler is used to surpress the progress bar. It's best to close most windows before evaluating the script but in most cases it just works. Thanks to Gary for the nice UI! When to expect an XP like look ;) Have fun, Torsten -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Nov. 20, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by StÃ©phane Ducasse

I loaded the fix of John for the menu and the changes for SUnit icons and my image freshes when I open the Package browser and run the tests in 10162 Stef

Nov. 20, 2008

Re: [Pharo-project] Event history question

by Igor Stasenko

2008/11/20 Michael Rueger <m.rueger(a)acm.org>: > Igor Stasenko wrote: > >> If i remember correctly, an interrupt semaphore is used to awake a >> process which watching for interrupts. >> And indeed, when key combination matching an interrupt key code, >> it calls setInterruptPending(), which is then eventually leads to >> signaling a semaphore which registered as interrupt semaphore. >> You can't handle it on image side, because you may not have chance to >> get to it (if there's another process running on same or higher >> priority than event ticker process). >> While in VM, regardless what image does, it periodically checks for >> interrupts, and during handling OS events, it checks if an interrupt >> key pressed, and if so, then signals the semaphore. >> At least, this is how it looks on Win32. > > The question really was if it is in the VM but rather if it (still) should > be in the VM. > After some discussions with John I'm pretty sure we can remove the interrupt > semaphore code from the VM. For now that would mean that the image code > still referring to it should/can be removed. > In this case, i'd like to read John's reasoning, why its safe to remove it from VM. >From my perspective , it should stay, because you can't imitate same behavior on language side safely. > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 20, 2008

Re: [Pharo-project] About Uppercase for class instance variable

by Alexandre Bergel

ISSUE #342 (Object allSubclasses select: [:cls| cls isMeta]) select: [:cls| cls instVarNames anySatisfy: [:n | n first isUppercase] In a Core-10156 it gives me: a Set(Latin1 class EncodedCharSet class) If I open a browser I have: EncodedCharSet class instanceVariableNames: 'CompoundTextSequence' Latin1 class instanceVariableNames: 'RightHalfSequence' CompoundTextSequence is renamed into compoundTextSequence RightHalfSequence is renamed into rightHalfSequence This fix makes this instance variable perserve their values. SLICE-RenamingInstanceVariable-Alexandre_Bergel.2 in PharoInbox Alexandre On 20 Nov 2008, at 10:26, StÃ©phane Ducasse wrote: > thanks alex. > > Stef > > On Nov 20, 2008, at 2:02 PM, Alexandre Bergel wrote: > >> (Object allSubclasses select: [:cls| cls isMeta]) select: [:cls| >> cls instVarNames anySatisfy: [:n | n first isUppercase] >> In a Core-10156 it gives me: a Set(Latin1 class EncodedCharSet class) >> >> If I open a browser I have: >> EncodedCharSet class >> instanceVariableNames: 'CompoundTextSequence' >> >> Latin1 class >> instanceVariableNames: 'RightHalfSequence' >> >> Shall I create an issue and rename CompoundTextSequence into >> compoundTextSequence and RightHalfSequence into rightHalfSequence >> ? >> >> Alexandre >> >> >> On 20 Nov 2008, at 05:49, StÃ©phane Ducasse wrote: >> >>> Hi >>> >>> I would like to know if you encountered class instance variable >>> with starting uppercase letter? >>> I hate that practice. >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 20, 2008

Re: [Pharo-project] About browsers

by David Pennell

Vassili's work on Hopscotch is a very interesting approach to eliminating modes in the browser. http://bracha.org/hopscotch-wasdett.pdf -david On Thu, Nov 20, 2008 at 2:38 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote:<snip> > > This is another illustration that the UI of Smalltalk browser is full of > modes. > > I would really like to see an IDE where we limit the number of modes. <snip>

Nov. 20, 2008