- Pharo-dev - lists.pharo.org

[Pharo-project] Polymorph in Pharo
by Torsten Bergmann Nov. 21, 2008

Nov. 21, 2008

>hmm.. i trying to install polymorph-widgets from universes on 10156- >dev image Did you try to patch the PCPackageLoader>>basicLoad method to disable the progress bar before loading as described in http://wiki.squeak.org/squeak/6005? It's also best just to have only one window (workspace) open, since some UI changes dont work with existing windows. Otherwise use the new script loader script from the inbox. In a 10160-dev this works without problems. 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

1 0

[Pharo-project] Alien progress
by John M McIntosh Nov. 21, 2008

Nov. 21, 2008

Ok, well I have some change sets to load the compiler changes, the base system, the platform pieces. Then load the plugin code, changes etc to interpreter. That all now compiles and links ok. And I can invoke the quicksort sample, then the Objective-C exampleNSOpenPanel but when I try the exampleOpenWindowWithModalAlert I get smoke... However this means it's 90% there. Note classAlien := ObjcAllocateClassPairAlien primFFICallResult: ObjectiveCClassAlien new with: className asAlien with: superclassName asAlien. core dumps but docs say that objc_allocateClassPair takes 3 parms... As indicated below, so mmm clue that something just isn't right objc_allocateClassPair Creates a new class and metaclass. objc_allocateClassPair(Class superclass, const char *name, size_t extraBytes) Parameterssuperclass The class to use as the new class's superclass, or Nil to create a new root class. name The string to use as the new class's name. The string will be copied. extraBytes The number of bytes to allocate for indexed ivars at the end of the class and metaclass objects. This should usually be 0. Return Value The new class, or Nil if the class could not be created (for example, the desired name is already in use). -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

Unix host windows. (Was: Re: [Pharo-project] HostWindows rewrite)
by Igor Stasenko Nov. 21, 2008

Nov. 21, 2008

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.

2 3

Re: [Pharo-project] Process stuck in 10156+OB?
by Igor Stasenko Nov. 20, 2008

Nov. 20, 2008

2008/11/18 Simon Denier <Simon.Denier(a)inria.fr>: > Good luck > > > Actually, I dont know where to start, I cant open a window or interrupt the > vm. > Hmm, an image, which you just sent me (10157ready.image), starts without any problems on my windoze box. No 100% CPU load, all is just working as always. Looks like the bug is VM/platform dependent, or you gave me wrong image?. > On 18 nov. 08, at 19:58, Igor Stasenko wrote: > >> 2008/11/18 Simon Denier <Simon.Denier(a)inria.fr>: >>> >>> On 18 nov. 08, at 18:32, Alexandre Bergel wrote: >>> >>>> Let us know Igor, this triggered my curiosity. >>>> >>>> Alexandre >>>> >>>> >>>> On 18 Nov 2008, at 14:25, Igor Stasenko wrote: >>>> >>>>> 2008/11/18 Marcus Denker <denker(a)iam.unibe.ch>: >>>>>> >>>>>> On 18.11.2008, at 17:11, Simon Denier wrote: >>>>>> >>>>>>> If I dowload the latest 10156 image, do a ScriptLoader loadOB, save >>>>>>> it >>>>>>> as >>>>>>> new image, quit and then relaunch the new image, my new image is >>>>>>> unusable >>>>>>> because almost unresponsive: something is eating 100% CPU time. >>>>>>> >>>>>>> - problem is the same if I upgrade to 10157 >>>>>>> - however there seems to be no problem if I just continue to work in >>>>>>> the >>>>>>> image without quitting. >>>>>>> >>>>>>> It's a weird behaviour. >>>>>>> >>>>>> >>>>>> Yes, I will undo some process related changes... maybe removing >>>>>> Process >>>>>> from >>>>>> the specialObjectsArray was a dunb idea ;-) >>>>>> I will put it back in. >>>>>> >>>>> Don't be so haste :) >>>>> I'd rather try to reproduce the problem and find solution. >>> >>> Should be easy to reproduce :) but I can send my image to whoever is able >>> to >>> work on it. >>> >> send it to me, i'll try to figure out what is wrong >>> >>>>> >>>>> >>>>> a 100% cpu hog at startup time could be a problem with Delays, or >>>>> different semaphores which has dropped during #clearExternalObjects >>>>> but not correctly reinstantiated again at following startup phase. >>>>> >>>>>> Marcus >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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 >>>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > Simon > > > > > -- Best regards, Igor Stasenko AKA sig.

6 9

Re: [Pharo-project] Event history question
by John M McIntosh Nov. 20, 2008

Nov. 20, 2008

Actually it's Michael who is messing in this area to improve the event handler for Pharo (and in general) as part of some funding from ESUG for the iPhone VM development work. Me? I'm just an innocent bystander. I'd assume he has to fork off any logic with low io process priority which is what I think happens if you follow the bouncing ball by reviewing what installInterruptWatcher and handleUserInterrupt do. The key consideration is that fetchMoreEvents is the trigger, not the code in the VM. On 20-Nov-08, at 10:58 AM, Andreas Raab wrote: > Hi John - > > The reasoning sounds about right but you have to be *very* careful > when making changes to that logic. As a simple example, > fetchMoreEvents is not only called from the event tickler and > consequently the interrupt handler might be forked at the priority > of some random process using "Sensor anyButtonPressed" ;-) If I > remember correctly, there were several other gotchas in this area (I > tried changing some of this stuff in Croquet once) and since this is > a place where screwing up will make a lot of people *very* unhappy I > would advise extreme caution when making these changes. > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

[Pharo-project] Event history question
by Michael Rueger Nov. 20, 2008

Nov. 20, 2008

Hi all, the event handling rewrite slowly starts to work :-) I'm currently fighting the parts where polling is used (like moving a window), but more on that later. The question I have is about user interrupt handling. I'm a bit confused and don't remember the history there: was there first an interrupt semaphore that then was abandoned or was it introduced but then not supported on some platforms? Or phrased differently: do we want user interrupt go through an interrupt semaphore or rather handle it on the image side? Michael

3 5

[Pharo-project] About Uppercase for class instance variable
by StÃ©phane Ducasse Nov. 20, 2008

Nov. 20, 2008

Hi I would like to know if you encountered class instance variable with starting uppercase letter? I hate that practice. Stef

2 4

[Pharo-project] some mess in 10161
by Pavel Krivanek Nov. 20, 2008

Nov. 20, 2008

BooleanScriptEditor has an obsolete superClass and should be removed. 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 -- Pavel

3 2

[Pharo-project] [update] #10157
by Marcus Denker Nov. 20, 2008

Nov. 20, 2008

-> 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

2 2

[Pharo-project] [update] 10161/10162
by Marcus Denker Nov. 20, 2008

Nov. 20, 2008

update10161 -> Issue 323: look at all the senders of noviceMode and try to remove this preference -> remove more etoy classes -> SystemNavigation default removeUnsentMessagesWithProgressBarInPackageNamed: EToys -> remove preferences: Preferences removePreference: #simpleMenus. Preferences removePreference: #mvcProjectsAllowed. Preferences removePreference: #uniTilesClassic. Preferences removePreference: #universalTiles. Preferences removePreference: #typeCheckingInTileScripting. Preferences removePreference: #eToyFriendly. Preferences removePreference: #eToyLoginEnabled. Preferences removePreference: #useVectorVocabulary. Preferences removePreference: #noviceMode. Preferences removePreference: #dropProducesWatcher. ------------------------------------------------------ update10162 More etoys/vocabulary cleans -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0