November 2008 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] some mess in 10161

by Marcus Denker

On 20.11.2008, at 10:48, Pavel Krivanek wrote: > BooleanScriptEditor has an obsolete superClass and should be removed. > I fixed that in 10162 > This removes some next obsolete classes: (Preferences preferenceAt: > #allowEtoyUserCustomEvents) changeInformee: nil changeSelector: nil. > > There's one new 'undeclared' after Smalltalk cleanOutUndeclared. > CPlatform used directly by HostSystemMenus class>>initialize > I put two issues on the bugtracker for those. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 20, 2008

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

by David RÃ¶thlisberger

> Now we should really have a button to execute them :) > I was thinking that clicking on the icons should run the tests :) ok, this is no problem to do. I will work on this. David >>>> On Nov 19, 2008, at 10:02 PM, Simon Denier wrote: >>>> >>>>> Hi all >>>>> >>>>> Just to notify a new enhancement to review in the PharoInbox. >>>>> >>>>> SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.2 >>>>> >>>>> >>>>> Short doc: >>>>> >>>>> Add: >>>>> - support history for test runs as well as progression filter to >>>>> show test in progression, regression >>>>> - support icons in OB to show the current state of a test: passed, >>>>> failed, progressed, regressed... >>>>> >>>>> History support: >>>>> - whenever some test cases run from the TestRunner, their results >>>>> are stored in a class side variable TestResult class>>History >>>>> - contextual menu for history in TestRunner>>error pane: >>>>> 1) History: access submenu to TestRunner instance history: can save >>>>> and show progress between results ran in the same TestRunner; lost >>>>> when this particular instance of TestRunner is closed >>>>> 2) Store results as progress reference: create/update a >>>>> lastStoredRun method on the class side of each TestCase which have >>>>> just been run, containing the results >>>>> 3) Show progress: make a diff between the last run and the >>>>> lastStoredRun, showing progress or regress in tests (new passed, >>>>> new failures, new errors) >>>>> >>>>> The idea is that whenever you are satisfied with the current >>>>> results of some of your tests, you can save this state as a >>>>> reference point with the 'Store results...' action. >>>>> This reference point can be compared with subsequent test results >>>>> to show your progression or regression. >>>>> >>>>> Test results are stored in a class side variable some are kept >>>>> local to your image. Reference results are stored in a special >>>>> method for each TestCase, so that they are saved with their package >>>>> and can be used as a common reference for package developers. So a >>>>> good practice is to store the latest test results as reference >>>>> before committing your changes. >>>>> >>>>> >>>>> Icons support: >>>>> OB Package browser now has icons for test methods in TestCase >>>>> subclasses: >>>>> - green circle: test has passed in the last run >>>>> - red circle: test has failed >>>>> - half green/half red circle: state unknown, test has no history or >>>>> test has changed since last run >>>>> - (no icon): test has raised an error >>>>> - upside green arrow: test has progressed since last reference run >>>>> - downside blue triangle: test has regressed since last reference run >>>>> >>>>> A test is in progression if it goes from error or failure to passed >>>>> state. >>>>> A test is in regression if it goes from passed to error or failure >>>>> state. >>>>> >>>>> The last two icons have other meanings with methods not related to >>>>> test, so we should change them whenever someone has better icons. >>>>> >>>>> Authors: Alexandre Bergel, Simon Denier, David RÃ¶thlisberger >>>>> >>>>> -- >

Nov. 20, 2008

Re: [Pharo-project] [update] #10157

by Marcus Denker

On 18.11.2008, at 11:12, StÃ©phane Ducasse wrote: > Cool > May be we should write a test or two for the classVariable > Yes, test would be nice... I add it to the TODO list. > Marcus do you know the the relationship between classVar and > classPool. > A classVar is added to the classPool dict? > Yes, Marcus > Stef > > > > On Nov 18, 2008, at 10:38 AM, Marcus Denker wrote: > >> >> -> Issue 84: 7136 TraitBehavior-2-dc >> Methods to make the interface of Traits compatible to classes, >> collected by Damien Cassou >> -> Issue 246: fix classVariableNames >> Metaclass shares the class variables with the class. (from Eliott >> Miranda) >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 20, 2008