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

Re: [Pharo-project] Website screenshots

by StÃ©phane Ducasse

Mike I do not know if you can edit the site because adrian is on holiday and I do not remember :) On Sep 16, 2009, at 7:09 PM, Gary Chambers wrote: > I guess the IDE screenshot could do with updating... old-stlye > buttons! > Just mention because linked from Planet Squeak (re: Facelifiting > Smalltalk). > > Might be nice with #showTextEditingState preference enabled now too... > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by StÃ©phane Ducasse

I remembered that. Now I was wondering about the following if we can tag a config we get in essence an Universe: a set of packages wrking with a given tag. But this is not quite the same. One of the problem that universes solved is that if MyApp requires AppA v1 YourApp requires AppA v3 I can load MyApp and YourApp separately but together thy may conflict or do not work Now universe forces me and you to choose when we publish because there was only one AppA the AppA for the current Universe. Stef On Sep 16, 2009, at 6:42 PM, Dale Henrichs wrote: > Stef, > > Under Metacello, when you a release a version, the complete list of > Monticello files are recorded with the version (including load order > dependencies). > > So Metacello is designed to make it possible to load old versions of > projects into new images. > > It is also possible to record the versions of all of the projects > that you are using, so you can record the exact version of Seaside, > Magritte and Pier you are using at a particular point in time, and > then you load that exact configuration into a different image at any > time in the future. > > Dale > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | Ok but for pharo1.0 it would be nice to have it :) > | then after we plug metacello underneath > | > | Doru with metacello will we be able to say > | I want to load in the past the version of moose which worked with > | pharo1.0 > | even if now I'm working on pharo 3.2 (the real future :)) > | > | Stef > | On Sep 16, 2009, at 1:08 PM, Damien Cassou wrote: > | > | > On Wed, Sep 16, 2009 at 11:38 AM, Tudor Girba <girba(a)iam.unibe.ch> > | > | > wrote: > | >> I believe Metacello is a very nice piece of work and it should be > | a > | >> very strong contender for managing releases. The ui tools are not > | >> quite there yet, but it works very nicely for allowing someone to > | >> specify the exact configuration to be loaded. > | > > | > I agree. Universes is cool but: > | > > | > - it requires a dedicated server and only few people installed one > | > | > already > | > - it only allows one administrator per package description > | > - the interface is well... not very nice :-) > | > - we would need to create a new universe from scratch > | > > | > -- > | > Damien Cassou > | > http://damiencassou.seasidehosting.st > | > > | > "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 > | > | > | _______________________________________________ > | 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

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by StÃ©phane Ducasse

good to know. My questioning is more about the infrastructure that we will have to put in place to manage external project to get a kind of universe for pharo based on metacello. Because at the end, I thought that the proposal of damien was that external projects ie Sixx, Ob,.... could be managed used metacello but may be the author does not want so we will have to provide metacello projects for those. Stef On Sep 16, 2009, at 6:35 PM, Dale Henrichs wrote: > Stef, > > I think that the core of Metacello is very solid. Doru is using it > for Moose (a large project) and I am using it for GLASS managing 20 > some individual projects like Pier, Seaside 2.8 and Magritte. I am > working on a Metacello configuration for Seaside 3.0 - almost 70 > packages and around 30 sub projects ... > > The API (DSL actually) and UI is still under development. > > The API is usable but in a few places is probably more complex than > it needs to be. The UI is virtually non-existent, but that is being > worked on, right Doru:). > > So far I've been able to maintain backwards compatibility for the > API as Doru and I have moved the API forward, but until we've > finalized things there's always the chance that we'd need to 'break' > something. > > If we have a good UI, then the changes in the API can be hidden to a > large extent... > > In the end it is probably prudent to wait a bit before going with > widespread usage of Metacello within Pharo and use it only in the > places with particularly difficult configuration issues... > > Within the next month I will be facing a similar decision - I am > pushing hard on Seaside 3.0 on top of GemStone 2.4 and Metacello is > an integral part of the effort. I will need to decide whether the > API is mature enough at that time to push out the GLASS release. > > Dale > > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | Hi > | > | I value the idea that when we look for a software (for example SIXX) > | we can find a version that is working. In the past we used Universes > | and > | if was successful. > | We cannot not have squeakmap and universe at the same time. > | I discussed with damien briefly about that and he told me that we > coud > | > | have > | a metacello alternative. > | Now I wonder if for pharo 1.0 it makes sense. > | May be having a nice Universe for pharo would be good and important. > | > | Dale what do you think? > | Do you see metacello working in the story (may be for 1.1)? > | Stef > | > | > | > | > | > | _______________________________________________ > | 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

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

Hi ken it is correct that alien touches the parser? The declarations are not pragmas compliant. Of course your suggestion makes sense. When marcus is back in europe I will check the status of the new handwritten parser because it would be good to use it. Stef On Sep 16, 2009, at 5:36 PM, Ken Treis wrote: > On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote: > >> I separated the extensions to the Parser (necessary to load the >> primitive methods) into a separate package Alien-Prereqs. >> If you load Alien-Prereqs before Alien-Core, it will work. > > > Thanks Johan, that's good news here. I appreciate it. > > Given that Alien requires modifications to the core parser, and that > the Alien-modified parser is backwards-compatible with the base > parser... is there any chance we can get the Alien modifications > into the base? Without that, Pharo software updates that touch > parser code will end up reverting the code in Alien-Prereqs, right? > > -- > Ken Treis > Miriam Technologies, Inc. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Author name prompt window is too big

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 16-09-2009 a las 16:15 +0200, Oscar Nierstrasz escribiÃ³: > Today I was giving a Pharo demo, using a slightly larger than standard > font. > > When I tried to commit a change, the prompt for my user name was > bigger than the available screen space on my laptop. Luckily I could > still type, though I could not see what I was typing. > > Can we please modify Author>>messagePrompt to use a *short* message? > The existing one is ridiculously large. Issue number: http://code.google.com/p/pharo/issues/detail?id=1223 Fixed now: Fixed on System-Support-MiguelCoba.88.mcz on PharoInbox -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Gary Chambers

In principle that is possible. Though Morph doesn't implement a "setter" for extension at the moment... There are, however, a lot of "default" value checks in Morph, likely due to the difficulty of migration in a live image environment. Regards, Gary ----- Original Message ----- From: "Andres Valloud" <avalloud(a)smalltalk.comcastbiz.net> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:56 PM Subject: Re: [Pharo-project] Morph extension OOoohhh... I remember doing similar hacks in Squeak... it's been quite a while since I was familiar with the code, but I thought I'd mention this in case it helps. Today, I get the impression that, more than properties, what morphs need are policy objects. In that way, acting as a response to a property becomes an unconditional message send to a policy object (as opposed to retrieve + valueOrNil check + ifTrue:ifFalse: + and then do something). Particularly with a PIC-capable VM, this should speed up execution (even without PICs, I'd guess even an IC-capable VM should have no problem making this run reasonably fast). But... I am not that familiar with Morphic right now. Would policy objects be a good idea for today's state of affairs? Andres. StÃ©phane Ducasse wrote: > 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 > . > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Author name prompt window is too big

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 16-09-2009 a las 16:51 +0200, StÃ©phane Ducasse escribiÃ³: > open a ticket and submit your code. > Give two significative example would be good (and we do not want . or > _ anyway) > This was on my todo but skipped my mind. > I'll do it. > Stef > > On Sep 16, 2009, at 4:15 PM, Oscar Nierstrasz wrote: > > > > > Today I was giving a Pharo demo, using a slightly larger than standard > > font. > > > > When I tried to commit a change, the prompt for my user name was > > bigger than the available screen space on my laptop. Luckily I could > > still type, though I could not see what I was typing. > > > > Can we please modify Author>>messagePrompt to use a *short* message? > > The existing one is ridiculously large. > > > > Author>>messagePrompt > > ^ > > 'Please type your name. It will be used to sign the changes you make > > to the image. > > Try to write an ASCII approximation of your name with only alphabetic > > characters > > and avoiding, if possible, spaces, accents, dashes and similar > > characters. > > Examples (The prefered form is the first one of each name): > > > > Miguel CobÃ¡ -> MiguelCoba > > Miguel CobÃ¡ -> miguel.coba > > Miguel CobÃ¡ -> miguel_coba > > GÃ¶ran Krampe -> GoranKrampe > > GÃ¶ran Krampe -> GoeranKrampe > > GÃ¶ran Krampe -> goran.krampe > > GÃ¶ran Krampe -> goran_krampe > > Vincent van Gogh -> VincentVanGogh > > StÃ©phane DUCASSE -> StephaneDucasse > > StÃ©phane DUCASSE -> stephane.ducasse > > Yoshiki Oshima -> YoshikiOshima > > Yoshiki Oshima -> yoshiki.oshima > > ' > > > > The first example would be good enough. > > > > - on > > > > > > _______________________________________________ > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 16, 2009

[Pharo-project] Website screenshots

by Gary Chambers

I guess the IDE screenshot could do with updating... old-stlye buttons! Just mention because linked from Planet Squeak (re: Facelifiting Smalltalk). Might be nice with #showTextEditingState preference enabled now too... Regards, Gary

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by Dale Henrichs

Stef, Under Metacello, when you a release a version, the complete list of Monticello files are recorded with the version (including load order dependencies). So Metacello is designed to make it possible to load old versions of projects into new images. It is also possible to record the versions of all of the projects that you are using, so you can record the exact version of Seaside, Magritte and Pier you are using at a particular point in time, and then you load that exact configuration into a different image at any time in the future. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Ok but for pharo1.0 it would be nice to have it :) | then after we plug metacello underneath | | Doru with metacello will we be able to say | I want to load in the past the version of moose which worked with | pharo1.0 | even if now I'm working on pharo 3.2 (the real future :)) | | Stef | On Sep 16, 2009, at 1:08 PM, Damien Cassou wrote: | | > On Wed, Sep 16, 2009 at 11:38 AM, Tudor Girba <girba(a)iam.unibe.ch> | | > wrote: | >> I believe Metacello is a very nice piece of work and it should be | a | >> very strong contender for managing releases. The ui tools are not | >> quite there yet, but it works very nicely for allowing someone to | >> specify the exact configuration to be loaded. | > | > I agree. Universes is cool but: | > | > - it requires a dedicated server and only few people installed one | | > already | > - it only allows one administrator per package description | > - the interface is well... not very nice :-) | > - we would need to create a new universe from scratch | > | > -- | > Damien Cassou | > http://damiencassou.seasidehosting.st | > | > "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 | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by Dale Henrichs

Stef, I think that the core of Metacello is very solid. Doru is using it for Moose (a large project) and I am using it for GLASS managing 20 some individual projects like Pier, Seaside 2.8 and Magritte. I am working on a Metacello configuration for Seaside 3.0 - almost 70 packages and around 30 sub projects ... The API (DSL actually) and UI is still under development. The API is usable but in a few places is probably more complex than it needs to be. The UI is virtually non-existent, but that is being worked on, right Doru:). So far I've been able to maintain backwards compatibility for the API as Doru and I have moved the API forward, but until we've finalized things there's always the chance that we'd need to 'break' something. If we have a good UI, then the changes in the API can be hidden to a large extent... In the end it is probably prudent to wait a bit before going with widespread usage of Metacello within Pharo and use it only in the places with particularly difficult configuration issues... Within the next month I will be facing a similar decision - I am pushing hard on Seaside 3.0 on top of GemStone 2.4 and Metacello is an integral part of the effort. I will need to decide whether the API is mature enough at that time to push out the GLASS release. Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | Hi | | I value the idea that when we look for a software (for example SIXX) | we can find a version that is working. In the past we used Universes | and | if was successful. | We cannot not have squeakmap and universe at the same time. | I discussed with damien briefly about that and he told me that we coud | | have | a metacello alternative. | Now I wonder if for pharo 1.0 it makes sense. | May be having a nice Universe for pharo would be good and important. | | Dale what do you think? | Do you see metacello working in the story (may be for 1.1)? | Stef | | | | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009