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

Re: [Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by StÃ©phane Ducasse

I like the idea of continuing to use the old images because this should be good for identifying bottlenecks. :) On Sep 18, 2010, at 12:44 PM, Lukas Renggli wrote: >>> I am already re-building everything on Hudson with this image. >>> Hopefully things go well. One-click images will use Cog. >>> >>> Lukas >> >> Yeah, I was doing the same locally using your builder scripts ;-) >> Works very nice. >> >> With this image we should be able to use Cog for the whole build process as well, no ? >> Hopefully with some good speedup. > > Indeed that should speed up building the images considerably. For now > I will continue to use the old VM for building though, so that the > resulting images can be opened with Cog and traditional VMs. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2010

Re: [Pharo-project] numerical guys brain needed :)

by StÃ©phane Ducasse

yes I think so too. On Sep 18, 2010, at 10:56 AM, Igor Stasenko wrote: > my take is normalize integers after manipulating with them using digitAt:put: > because if not, then you can't rely on size when comparing numbers, > and comparison will become much slower, since you forced to always > compare contents, > regardless that size is different. > > On 18 September 2010 11:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> hi guys >> >> what your take on >> >> http://code.google.com/p/pharo/issues/detail?id=2968 >> >> Stef >> >> "The same value in a LargePositiveInteger and a SmallInteger will not compare properly. The same value in two LargePositiveIntegers will not compare properly, if their byte sizes are different. I think the problem is in Integer>>#digitCompare: It gives incorrect results if the digitLengths are different between receiver and arg. This bug cost me about a day to find and fix. Maybe it has been addressed in a newer image/vm but I thought I would offer my fix to save someone else some time if it hasn't been dealt with yet. (I searched all issues) >> >> Pharo image: Pharo1.0-10508-rc2dev10.01.2.image >> Pharo core version: Pharo-1.0-10508-rc2 Latest update: #10508 >> Virtual machine used: <Squeak 4.2.5b1 - Mac OSX> >> >> >> Steps to reproduce: >> 1. >> >> (Integer new: 6 neg: false) = (Integer new: 8 neg: false) "0 = 0 should return true" >> >> >> 2. >> >> | int | >> int := Integer new: 6 neg: false. >> int digitAt: 1 put: 6. >> ^int = 6 "6 = 6 should return true"" >> _______________________________________________ >> 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

Sept. 18, 2010

Re: [Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by Lukas Renggli

>> I am already re-building everything on Hudson with this image. >> Hopefully things go well. One-click images will use Cog. >> >> Lukas > > Yeah, I was doing the same locally using your builder scripts ;-) > Works very nice. > > With this image we should be able to use Cog for the whole build process as well, no ? > Hopefully with some good speedup. Indeed that should speed up building the images considerably. For now I will continue to use the old VM for building though, so that the resulting images can be opened with Cog and traditional VMs. Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 18, 2010

[Pharo-project] A point about pharo: the red line

by StÃ©phane Ducasse

Hi pharoers We want to stress something that may seem obvious for us but that can may be not for you and that people attending ESUG could discover live :) lucky them :) But you will be able to watch the video and get an idea soon. What is important is that it can explain a lot of our actions and future actions. Here is a list of statements that I tried to make short. - We do pharo because we want to create an ecosystem for companies and research/innovation. - We don't do pharo for fame and fans else we would do ruby or hard-rock. :) (ok probably ruby) - We want to build a powerful open-source community. - Every single node in the community is important. So yes you doing your little project in your corner you are important. Why? Because a community is a synergetic beast and we are all cool because the community is cool. So you are also important to us. For example if you want to give a lecture on pharo, we can help. if you want to do presentations, we can help, if you have problems/ideas let us know. - Often we do actions not because we want credit but just because somebody has to do it: seaside book, esug are to other examples of why we did pharo. Because we need a power rocking hyper cool beautifully designed system. (I know some of you think that I'm lousy and I use too much cool but this is what I mean) - We believe in strong elegant beautiful infrastructure: fix the stuff so that you can go faster to build the next one. We did that with Moose: offer to software engineering researchers a foundation to focus on problems versus rebuilding each time a clean source code meta model and importer. Infrastructure will give us the leverage to build the next generation. Stef and other pharoers

Sept. 18, 2010

Re: [Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by Sven Van Caekenberghe

On 18 Sep 2010, at 10:09, Lukas Renggli wrote: > I am already re-building everything on Hudson with this image. > Hopefully things go well. One-click images will use Cog. > > Lukas Yeah, I was doing the same locally using your builder scripts ;-) Works very nice. With this image we should be able to use Cog for the whole build process as well, no ? Hopefully with some good speedup. > On 18 September 2010 09:58, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Sep 18, 2010, at 9:34 AM, Sven Van Caekenberghe wrote: >> >>> >>> On 12 Sep 2010, at 12:02, Marcus Denker wrote: >>> >>>> https://gforge.inria.fr/frs/download.php/27479/PharoCore-1.1.1.zip >>> >>> The images inside are 11414 but the filenames say otherwise: >>> >> Uhh.... I will redo it. >> >> There are two other fixes I missed, too. >> >>> >>> Will the official 'stable' link move to this one too (or did it already) ? >>> >> >> No, this will be done as soon as we have a full image, too. >> >> Marcus >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2010

Re: [Pharo-project] numerical guys brain needed :)

by Igor Stasenko

my take is normalize integers after manipulating with them using digitAt:put: because if not, then you can't rely on size when comparing numbers, and comparison will become much slower, since you forced to always compare contents, regardless that size is different. On 18 September 2010 11:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi guys > > what your take on > > Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=2968 > > Stef > > "The same value in a LargePositiveInteger and a SmallInteger will not compare properly. The same value in two LargePositiveIntegers will not compare properly, if their byte sizes are different. I think the problem is in Integer>>#digitCompare: It gives incorrect results if the digitLengths are different between receiver and arg. This bug cost me about a day to find and fix. Maybe it has been addressed in a newer image/vm but I thought I would offer my fix to save someone else some time if it hasn't been dealt with yet. (I searched all issues) > > Pharo image: Pharo1.0-10508-rc2dev10.01.2.image > Pharo core version: Pharo-1.0-10508-rc2 Latest update: #10508 > Virtual machine used: <Squeak 4.2.5b1 - Mac OSX> > > > Steps to reproduce: > 1. > > (Integer new: 6 neg: false) = (Integer new: 8 neg: false) "0 = 0 should return true" > > > 2. > > | int | > int := Integer new: 6 neg: false. > int digitAt: 1 put: 6. > ^int = 6 Â Â "6 = 6 should return true"" > _______________________________________________ > 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.

Sept. 18, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Hilaire Fernandes

Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision. Anyway the open source ecosystem Darwin alike evolution law will prevail. Hilaire Le 18/09/2010 10:09, StÃ©phane Ducasse a Ã©crit : > Hi Juan > > My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change > you did in CUIS. > If somebody wants to help this would be great. > > Stef > > > On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote: > >> DeNigris Sean wrote: >>> I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. >>> >>> I think it's amazingly powerful and universally misunderstood. >> >> I agree. >> >>> Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: >>> 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible >>> 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. >>> >>> Morphic seems ideal for group #1. I think the key questions are: >>> * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? >>> >> >> I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: >> - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. >> - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering. >> >>> * what would it take (if possible) to get there from the current implementation? >>> >> >> The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2. >> >>> Two issues I've noticed: >>> 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. >>> 2. I'm not clear whether the hooks for modifying behavior are >>> a. available in all the right places >>> b. working >>> c. widely understood >>> >>> I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. >>> >> >> I'd like to be part of that. Are you setting up a mail list? >> >>> A quick example of my (seemingly common) experience: >>> For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. >>> >>> I tried (one of these felt very satisfying): >>> * Morph>>on:send:to:, which sounded good, but never got called >>> * intercepting Morph>>processEvent:using: (which I was told was not a good idea) >>> * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). >>> * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. >>> >>> Sean >> >> Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already. >> >> You'd really try Cuis. You'll find it much easier to understand and extend. >> >> Cheers, >> Juan Vuletich >> -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Sept. 18, 2010

[Pharo-project] numerical guys brain needed :)

by StÃ©phane Ducasse

hi guys what your take on http://code.google.com/p/pharo/issues/detail?id=2968 Stef "The same value in a LargePositiveInteger and a SmallInteger will not compare properly. The same value in two LargePositiveIntegers will not compare properly, if their byte sizes are different. I think the problem is in Integer>>#digitCompare: It gives incorrect results if the digitLengths are different between receiver and arg. This bug cost me about a day to find and fix. Maybe it has been addressed in a newer image/vm but I thought I would offer my fix to save someone else some time if it hasn't been dealt with yet. (I searched all issues) Pharo image: Pharo1.0-10508-rc2dev10.01.2.image Pharo core version: Pharo-1.0-10508-rc2 Latest update: #10508 Virtual machine used: <Squeak 4.2.5b1 - Mac OSX> Steps to reproduce: 1. (Integer new: 6 neg: false) = (Integer new: 8 neg: false) "0 = 0 should return true" 2. | int | int := Integer new: 6 neg: false. int digitAt: 1 put: 6. ^int = 6 "6 = 6 should return true""

Sept. 18, 2010

Re: [Pharo-project] [squeak-dev] Re: Morphic

by StÃ©phane Ducasse

Yes and I would like to have a kind of MVP model. Stef On Sep 18, 2010, at 9:15 AM, Hilaire Fernandes wrote: > Le 17/09/2010 23:58, Juan Vuletich a Ã©crit : >> DeNigris Sean wrote: >>> I was doing a lot of playing with Morphic this week at ESUG in >>> Barcelona. Many people seem to really not like it and complain about >>> it, but it seems very vague i.e. they can't point to a specific >>> problem with it. >>> >>> I think it's amazingly powerful and universally misunderstood. >> >> I agree. > > > I agree too. This is also why I like so much Polymorph, it adds the > widgets layer on top of Morphic. So now we have the option to use > barebone Moprh for very special widgetries and also standard widget > provided by Polymorph. It becomes very productive to write GUI > application... > > Hilaire > > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > >

Sept. 18, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by StÃ©phane Ducasse

Hi Juan My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great. Stef On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote: > DeNigris Sean wrote: >> I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. >> >> I think it's amazingly powerful and universally misunderstood. > > I agree. > >> Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: >> 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible >> 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. >> >> Morphic seems ideal for group #1. I think the key questions are: >> * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? >> > > I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: > - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. > - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering. > >> * what would it take (if possible) to get there from the current implementation? >> > > The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2. > >> Two issues I've noticed: >> 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. >> 2. I'm not clear whether the hooks for modifying behavior are >> a. available in all the right places >> b. working >> c. widely understood >> >> I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. >> > > I'd like to be part of that. Are you setting up a mail list? > >> A quick example of my (seemingly common) experience: >> For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. >> >> I tried (one of these felt very satisfying): >> * Morph>>on:send:to:, which sounded good, but never got called >> * intercepting Morph>>processEvent:using: (which I was told was not a good idea) >> * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). >> * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. >> >> Sean > > Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already. > > You'd really try Cuis. You'll find it much easier to understand and extend. > > Cheers, > Juan Vuletich >

Sept. 18, 2010