September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Alien and special objects Array

by Johan Brichau

On 29 Sep 2009, at 19:38, Brian Brown wrote: > I thought #fixTemp was for code compatibility but isn't really needed > because of real closures? so this change should be safe? note that the #fixTemp: method that is used right now comes with the standard pharo image (which does include closures). ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Sept. 30, 2009

[Pharo-project] Alien & Squeak FFI issues on Snow Leopard.

by John M McIntosh

Someone finally managed to fire up a Sophie app http://www.opensophie.org/ on Snow Leopard and immediately found an issue that also affects Squeak users who do fascinating things with FFI The innocent FFI call was apifstat: afileNo statBuffer: buffer <cdecl: long 'fstat' (long MacStat* ) module: 'libc.dylib'> ^self externalCallFailed Now it seems BEFORE Snow Leopard *somehow* the Squeak external primitive call api which is part of the VM to assist in loading plugins or finding function entry points in executable binaries or libraries would return the entry point for fstat by *somehow* finding libc.dylib which is via /usr/lib/libc.dylib -> libSystem.dylib -> libSystem.B.dylib Interestingly this is found implicitly since the mac carbon vm lookup logic never looks in /usr/lib/ Now in Snow Leopard it seems they do less implicit searching, perhaps a security concern? Then it fails. In the past the Unix VM would search a hundred(sic) more places, but I understand less today, but it might still work? Maybe /usr/lib is in the hit list? This issue also applies to Alien because it calls back to the VM for it to find the module and function entry point. Since I have received a request to ensure that doing an explicit full path should be allowed in the squeak carbon macintosh vm. Then a change would be: apifstat: afileNo statBuffer: buffer <cdecl: long 'fstat' (long MacStat* ) module: '/usr/lib/libc.dylib'> ^self externalCallFailed I'll look at doing this shortly. However the workaround is to go to Sophie.app/Contents/Resources and do a ln -s /usr/lib/libc.dylib libc.dylib to create a symbolic link in the Resources directory for libc.dylib since we do explicitly look for libc.dylib in the Resources directory. Obviously if you have a FFI call like above where you are calling a system library Oracle? for example. You might find it no longer works with Snow Leopard on the Macintosh, so you should check. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Sept. 30, 2009

Re: [Pharo-project] [update] closure fixes :)

by Mariano Martinez Peck

I have just tested SqueakDBX and Glorp tests (1000 aprox. in total) and they are all green :) I used the image for a couple of hours and everything seems to be ok. Thanks for this excellent integration! Mariano On Sat, Sep 26, 2009 at 1:05 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > thanks for integrating Stef > > cheers > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 30, 2009

Re: [Pharo-project] [squeak-dev] Mac carbon VM goes to 4.2.2Beta1U

by John M McIntosh

Ok, I've altered the master Squeak 4.2.2beta1U.app.zip and added the signature file. Also I've attached it. People who have made copies (like for the pharo site) might want to re- download it to ensure you've the correct zip file. found via http://smalltalkconsulting.com/squeak.html On 2009-09-29, at 9:12 AM, Bert Freudenberg wrote: > > On 27.09.2009, at 23:49, John M McIntosh wrote: >> >> I've also uploaded the new VM as Squeak 4.2.2beta1U.app.zip >> found via >> http://smalltalkconsulting.com/squeak.html > > Is it intentional there is no "Squeak VM Opt.sig" anymore? > > - Bert - > > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Sept. 29, 2009

[Pharo-project] tabs with icons?

by Tudor Girba

Hi, In Glamour we are using a TabGroupMorph (actually we use a subclass that specifies LazyTabs). The question is if there is a way to add an icon instead of a string? Or perhaps is there another solution for a tab control that allows for icons in the tabs? Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

Sept. 29, 2009

Re: [Pharo-project] Update 10458 fails with MNU

by Martin McClure

StÃ©phane Ducasse wrote: > I published 48 in pharo but this is strange because we have the > repository to gofer > and I do not understand why this package is not found. Thanks, the update now succeeds. Both Gofer-lr.48.mcz and Gofer-lr.51.mcz end up in the package-cache. Regards, -Martin

Sept. 29, 2009

Re: [Pharo-project] Morph extension

by Marcus Denker

Hi, I added an entry in the bugtracker (tagged 1.1), so we can have a look a this during the sprint in Lille. http://code.google.com/p/pharo/issues/detail?id=1254 On 16.09.2009, at 10:55, Gary Chambers wrote: > Have a go with it (use a fresh image rather than anything you might > want to lose...). > Stick the .cs in your image directory, open a workspace and do the > following... > > (FileStream readOnlyFileNamed: 'MorphicExtensionPerformance.1.cs') > fileInSilentlyAnnouncing: nil. > Morph allSubInstances do: [:m | > #(fillStyle layoutPolicy layoutFrame layoutProperties borderStyle > cornerStyle actionMap clipSubmorphs) do: [:prop | > m extension ifNotNilDo: [:extension | > extension otherProperties ifNotNilDo: [:otherProperties | > extension instVarNamed: prop put: ( > otherProperties at: prop ifAbsent: []). > otherProperties removeKey: #prop ifAbsent: []]]]] > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > > > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, September 16, 2009 3:49 PM > Subject: Re: [Pharo-project] Morph extension > > > Gary I would love to see morphic goes faster so we are ready to try :) > > Stef > >> >> >> I've managed to refactor the worst offenders. >> >> Benchmarks for the "opening system browser" below show an >> improvement. >> >> Going from patched to unpatched shows that the unpatched takes >> between 15% >> and 20% longer to complete depending on fonts/theme. >> >> (Benchmark code) >> >> | saveMorphs time | >> [saveMorphs := World submorphs. >> World removeAllMorphs."heh, heh" >> time := [1 to: 10 do: [:i | >> MorphicToolBuilder new open: >> (Browser new setClass: SystemDictionary selector: nil). >> World doOneCycleNow]. >> World submorphs do: [:m | m delete. World doOneCycleNow]. >> ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. >> SystemWindow noteTopWindowIn: World. >> time >> >> (end of benchmark code) >> >> I can make a changeset available for the brave who want to try. >> I have developed a workspace script that (finally) appears to load it >> correctly, >> waas a lot of hung-image before getting there... >> >> (loading tested on 10451-BETA) >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, September 08, 2009 7:01 PM >> Subject: Re: [Pharo-project] Morph extension >> >> >> >> >> StÃ©phane Ducasse skrev: >>> On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: >>> >>> >>>> After some experimenting I can get over 10% perfromance improvement >>>> with >>>> window operations when fillStyle; borderStyle; hResizing; vResizing >>>> are >>>> made as instance variables of Morph, rather than going through >>>> extension. >>>> >>> >>> this is a lot. >>> You really mean Morph or we could get them in subclasses too. >>> >>> >> Inspect this in an image with some windows open, it will give you the >> percentage of morphs with otherProperties containing any given >> property: >> >> |propBag noMorphs| >> propBag := Bag new: 50. >> noMorphs := 0. >> Morph allSubInstances do: [:each | each otherProperties ifNotNil: >> [:props | propBag addAll: props keys. >> noMorphs := noMorphs +1]] . >> noMorphs := noMorphs asFloat. >> propBag sortedCounts collect: [:each | each key: each key / noMorphs; >> yourself] >> >> >> otherProperties is heavily abused. with respectively 98 and 125 >> senders >> of valueOfProperty: / valueOfProperty:ifAbsent:... >> In my case there were _57_ different distinct otherProperties in >> use, an >> average of three, a maximum of 15, and four of them present in over a >> quarter of morphs defining any (80% for the most common one)... >> If moving directly to Morph is a bit extreme, at least _some_ of >> these >> qualify for promotion to direct access in MorphExtension imho, it >> seems >> to have some "free" instvars anyways after the removal of players. >> >> In the interest of seeing which would benefit the most from moving, I >> did a small profile: >> - Dragging a window and switching some between different ones with 2 >> browsers, a monticello browser, a workspace and a Method search open. >> I had the following access numbers: >> 105586->#clipSubmorphs (about 4.5 per millisecond) >> 66029->#layoutProperties >> 62783->#layoutPolicy >> 55556->#theme >> 41312->#hasDropShadow >> 41310->#hasRolloverBorder >> 36817->#fillStyle >> 19241->#cornerStyle >> 13239->#highlightedForDrop >> 13239->#highlightedForMouseDown >> 11945->#roundedCorners >> 11911->#borderStyle >> 10644->#edgeToAdhereTo >> 9020->#paneColor >> 8885->#lastPaneColor >> [rest below 5000 accesses] >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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 > <MorphicExtensionPerformance. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 29, 2009

Re: [Pharo-project] Would be nice to have an RSS feed or kind of blog on the web site

by Marcus Denker

On 23.09.2009, at 04:00, Damien Cassou wrote: > 2009/9/22 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> 1) Have a page in website with a list of the possible blogs that >> talks about >> Pharo. Exactly like what Seaside does: >> http://www.seaside.st/community/weblogs >> The question here is: does someone has a blog that talks about Pharo? > > There are some posts here and there, but nothing about Pharo only. We > should check with people if they use a particular tag. > > >> 2) Have a "official" Pharo blog where we can put news, and related >> stuff. >> The thing here is: public access to edit? or there should be >> someone to >> manage it ? > > I think we need a limited access to some of us. I would like an access > for me to announce new Pharo as I release them. > Yes, I think this would be the best. I will check with Adrian. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 29, 2009

Re: [Pharo-project] Alien and special objects Array

by Brian Brown

On Sep 29, 2009, at 6:49 AM, Johan Brichau wrote: > > > However, I'm not comfortable saying that this is the right patch to > make. Perhaps someone familiar with the compiler or John can tell us > if this is fine? > Another issue might be the compatibility with Squeak here. I should > take a look.... > > I published the patch anyway in the meantime. > I thought #fixTemp was for code compatibility but isn't really needed because of real closures? > On 29 Sep 2009, at 10:50, Torsten Bergmann wrote: > >> Just try it in latest #10462. >> >> with >> >> ScriptLoader loadLatestPackage: 'AlienLoader' from: 'http:// >> www.squeaksource.com/Alien' >> . >> (Smalltalk at: #AlienLoader) load > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2009

Re: [Pharo-project] Update 10458 fails with MNU

by Brian Brown

On Sep 29, 2009, at 2:21 AM, Damien Cassou wrote: > On Tue, Sep 29, 2009 at 7:49 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> We should really discuss if we want to have installer or gofer in the >> core. > > Installer allows to write installation scripts whereas Gofer allows to > load MC packages. Gofer can be seen as a possible backend for > Installer. > > You should not think in term of which one to choose because their > roles are completely different. > I agree completely. I think we should have installer in the core, as it's stated goals and functionality seem to be exactly what we need for our modularized system. Gofer could and should be a backend for it, and if the consensus is include installer in the core, then I will write the adapter for gofer. - Brian > -- > Damien Cassou > http://damiencassou.seasidehosting.st >> We should really discuss if we want to have installer or gofer in the >> core. > > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 29, 2009