- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

> I'd guess the important thing is to explain on the Pharo web site > that bug fixes are in the 1.1 and are not (always) retrofitted to 1.0 only showstoppers = severe bugs = that can put the system on his knees. But probably we should stay that: "In the current set of ressources only showstoppers or extremely severe bugs are retrofitted in old versions" Stef > > Stephan

May 30, 2010

Re: [Pharo-project] Issue 670: Should clean Morph menu

by Guillermo Polito

I take this thread back to life. Is everyone happy with this menu? Is It useful? :P On Wed, May 26, 2010 at 6:59 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > magic of morphic :) > > Stef > > On May 26, 2010, at 11:29 AM, Gary Chambers wrote: > > > Well, even if a morph does not, at any one time, use a table layout the > settings are preserved and use if switched to a table layout... > > > > Curiously these options are pretty much the only ones I use from the menu > ;-) > > > > > > Regards, Gary > > ----- Original Message ----- > > From: Carla F. Griggio > > To: Pharo-project(a)lists.gforge.inria.fr > > Sent: Tuesday, May 25, 2010 10:25 PM > > Subject: Re: [Pharo-project] Issue 670: Should clean Morph menu > > > > Well, I haven't tried all those actions, but if it helps in any way, the > ones I usually use are: > > > > grab > > delete > > copy text > > submorphs > > inspect > > show actions > > debug-> > > inspect morph > > inspect model > > browse morph class > > browse model class > > > > > > > > I don't see what the layout options do. I don't know much about layouts, > so maybe this doesn't make sense, but... shouldn't the options for table > layout be available only if the morph I'm dealing with has a table layout? > > > > > > > > On Tue, May 25, 2010 at 5:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > **EXCELLENT** > > truly excellent > > Yes we try to sort that and get some cleaning. > > > > > grab > > > copy to paste buffer > > > collapse > > > delete > > > copy text > > > go behind > > > add halo > > > duplicate > > > embed into-> > > > PasteUpMorph > > > SystemWindow > > > resize > > > change color... > > > drop shadow-> > > > show shadow > > > shadow color... > > > shadow offset... > > > layout-> > > > no layout > > > proportional layout > > > table layout > > > change layout inset... > > > child layout-> > > > disable layout in tables > > > horizontal resizing-> > > > rigid > > > shrink wrap > > > space fill > > > vertical resizing-> > > > rigid > > > shrink wrap > > > space fill > > > table layout-> > > > reverse table cells > > > clip to cell size > > > rubber band cells > > > change cell inset... > > > change min cell size... > > > change max cell size... > > > list direction-> > > > ... > > > wrap direction-> > > > ... > > > cell positioning-> > > > ... > > > list centering-> > > > ... > > > wrap centering-> > > > ... > > > list spacing-> > > > ... > > > cell spacing-> > > > ... > > > provide clipping > > > submorphs > > ?? > > > > > inspect > > > explore > > > > > browse hierarchy > > ?? > > > > > save morph in file > > > attach to resource > > ?? > > > > > show actions > > > debug-> > > > inspect morph > > > inspect owner chain > > > inspect model > > > explore morph > > > browse morph class > > > browse model class > > > explore view hierarchy > > > call #tempCommand > > ?? > > > define #tempCommand > > ?? > > > > > open editing > > > edit label... > > > > > > Cheers, > > > Guille > > > _______________________________________________ > > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by Stephan Eggermont

I'd guess the important thing is to explain on the Pharo web site that bug fixes are in the 1.1 and are not (always) retrofitted to 1.0 Stephan

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

>> CCing Pharo list, this was regarding: >> >> http://goran.krampe.se/blog/Squeak/eblankett-dev.rdoc >> >> On 05/30/2010 12:00 PM, Stephan Eggermont wrote: >>> Hello GÃ¶ran, >>> >>> Is there a special reason you tried Pharo 1.0? Your improvements are of >> >> Nope, just (wrongly I agree) thought it was fairly up to date since it was just released. But you are right, depending on release process that does indeed not necessarily correlate. > Pharo 1.0 was in freeze for a loooong time, mostly due to the problematic network changes that ended up getting reverted. > Why none of the bugfixes have been bundled up as a 1.0 upgrade, time money time money time time time time time time time time time and tada time And what is an important fix/enh that should be included 1.1: a bug that really break the system and I do not think that this one broke the system since so far nobody ever complained. Now if as a community we are able to gather money then we can fix that easily :) and 1.1 is far far far better than 1.1 > I'm not entirely certain, but the awareness of marking bugfixes as 1.0.1 has been fairly low :/ > In either case you'd probably not find Date readFrom:pattern: in such a patch. > >> >>> course >>> in 1.1. Feature freeze for 1.0 was long ago. If you're willing to use >>> the bleeding edge >>> in squeak, why not do it in pharo too? >> >> Again, not a conscious choice. I can use bleeding edge in Pharo too, is there an easy place to start? Earlier I used some core + Renggli scripts to get a decent image. >> >>> Which peek bugfix is in Squeak? The 2010-1-13 solution is wrong. >>> See http://code.google.com/p/pharo/issues/detail?id=1813. >> >> I will check it out, gotta work on the house now :) >> >>> Groetjes, >>> Stephan Eggermont >> >> Thanks for the feedback, GÃ¶ran > > The peek bug fix, the perform:withArguments: fix and Date readFrom:pattern: are all in an updated Pharo 1.1. > You can get a fairly recent core image from > https://gforge.inria.fr/frs/download.php/27017/PharoCore-1.1-11367-Beta.zip > or a dev image from > https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… > (Update 11369 included the perform:withArguments: fix, you'd have to do Utilities updateFromServer manually in the dev image) and tons of even cooler ones. Stef

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by StÃ©phane Ducasse

> Hi, > > i found rome API very close to OpenVG. > Still OpenVG is a bit superior :) > So, i'm using it as a guide to model/implement Rome interfaces. Excellent! > So, here is my thoughts (i also having a draft class skeleton for them): frankly consider that we are working on Rome because we need something to get access to Cairo/ whatever but we are newbie at the level. Now the good point for us is that we are smart newbies :) and ready to learn fast. So our first idea is - make it work (romePluginCanvas) - make all romeReferenceCanvas Get feedback, improve it improve it improve it as well as make all the code use it make all the code use it . So thanks for your brainstorming/ideas/wishes > Because, we could simply do: > > canvas fill: myPath with: myPaint > > instead of: > > canvas selectFill: myPaint. > canvas fill: myPath. > > Because you anyways can't draw a paths without paints, i don't see why > canvas should have a notion of 'current fill' or 'current paint'. > I think that with paint's encapsulation, its not necessary. > > > I'd like to hear your thoughts about it. No idea. Now at the back end level or "reference level" is there a value to separate? because like that you can do > canvas selectFill: myPaint. > canvas fill: myPath. > canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath.canvas fill: myPath. Stef > Paints: > > Paint is an object, which when applied to path, renders(draws) the > path using paint's unique properties. > > I defined two methods in paint's base class: > > fillPath: aPath on: aCanvas > > self subclassResponsibility > > strokePath: aPath on: aCanvas > > self subclassResponsibility > > So, to draw a path, one should use a concrete paint to either fill it > or stroke it (or both, if you want, but its handled by canvas and > still will end up with separate fill & stroke requests to paint). > > I started from a quite basic things: > > NullPaint > Paint which does not performs any drawing. > Applying this paint to any path won't lead to any > changes/processing. A simple OO approach to define 'nothing' :) > > SolidColorPaint > instanceVariableNames: 'color' > > Paint with solid color. Most trivial thing which can be done :) > > RomePen > instanceVariableNames: 'paint capStyle joinStyle width dash' > > A 'pen' paint is just encapsulating a set of properties, which is used > for stroke. > It is using another paint, which should handle the fills (in 'paint' > ivar), while various stroke properties should be handled by itself. > Filling with pen, will be the same as filling with its paint. While > doing a stoke is different (includes path processing, given the values > of pen's properties etc etc). > I'm not sure with this part. Maybe stroke properties would be better > to leave in canvas? Both OpenVG and Rome seems like following this > road, > but i don't quite like that stroke properties is global for canvas and > lacking a proper encapsulation. > > CompositePaint > Quite dumb thing. Holds a list of paints. When asked to fill or > stroke the path, applies paints from own list. > > GradientPaint (abstract) > LinearGradient > RadialGradient > etc.. > paints which will use gradients for fills. Nothing fancy :) > > > Canvas protocol: > > selectFill: anObject > > fill := anObject asRomePaintOn: self > > - selects a paint which will be used for fills. > > selectPen: anObject > > pen := anObject asRomePaintOn: self > > - selects a paint which will be used for stokes. > > > stroke: anObject > | path | > path := anObject asRomePathOn: self. > > fill strokePath: path on: self. > > - stroke a path using currently selected 'pen' paint > > fill: anObject > | path | > path := anObject asRomePathOn: self. > > fill fillPath: path on: self. > > - fill path using paint for fills > > > fillAndStroke: anObject > | path | > path := anObject asRomePathOn: self. > > fill fillPath: path on: self. > pen strokePath: path on: self > > - fill and stroke path. > > And from that point, i wonder, do we need to have a paint's selection > mechanisms at all? > > Because, we could simply do: > > canvas fill: myPath with: myPaint > > instead of: > > canvas selectFill: myPaint. > canvas fill: myPath. > > Because you anyways can't draw a paths without paints, i don't see why > canvas should have a notion of 'current fill' or 'current paint'. > I think that with paint's encapsulation, its not necessary. > > > I'd like to hear your thoughts about it. > > > -- > 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

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by Henrik Sperre Johansen

On 30.05.2010 13:24, GÃ¶ran Krampe wrote: > Hi! > > CCing Pharo list, this was regarding: > > http://goran.krampe.se/blog/Squeak/eblankett-dev.rdoc > > On 05/30/2010 12:00 PM, Stephan Eggermont wrote: >> Hello GÃ¶ran, >> >> Is there a special reason you tried Pharo 1.0? Your improvements are of > > Nope, just (wrongly I agree) thought it was fairly up to date since it > was just released. But you are right, depending on release process > that does indeed not necessarily correlate. Pharo 1.0 was in freeze for a loooong time, mostly due to the problematic network changes that ended up getting reverted. Why none of the bugfixes have been bundled up as a 1.0 upgrade, I'm not entirely certain, but the awareness of marking bugfixes as 1.0.1 has been fairly low :/ In either case you'd probably not find Date readFrom:pattern: in such a patch. > >> course >> in 1.1. Feature freeze for 1.0 was long ago. If you're willing to use >> the bleeding edge >> in squeak, why not do it in pharo too? > > Again, not a conscious choice. I can use bleeding edge in Pharo too, > is there an easy place to start? Earlier I used some core + Renggli > scripts to get a decent image. > >> Which peek bugfix is in Squeak? The 2010-1-13 solution is wrong. >> See http://code.google.com/p/pharo/issues/detail?id=1813. > > I will check it out, gotta work on the house now :) > >> Groetjes, >> Stephan Eggermont > > Thanks for the feedback, GÃ¶ran The peek bug fix, the perform:withArguments: fix and Date readFrom:pattern: are all in an updated Pharo 1.1. You can get a fairly recent core image from https://gforge.inria.fr/frs/download.php/27017/PharoCore-1.1-11367-Beta.zip or a dev image from https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… (Update 11369 included the perform:withArguments: fix, you'd have to do Utilities updateFromServer manually in the dev image) Cheers, Henry

May 30, 2010

Re: [Pharo-project] how to add an entry in World Menu (was: CommandShell)

by StÃ©phane Ducasse

thanks alain! On May 30, 2010, at 1:51 PM, Alain Plantec wrote: > > http://book.pharo-project.org/book/TipsAndTricks/DeclaringSetting > Alain > > Le 28/05/2010 07:33, Alain Plantec a Ã©crit : >> Le 27/05/2010 23:02, laurent laffont a Ã©crit : >>> See http://book.pharo-project.org/book/TipsAndTricks/WorldMenuRegistration >> yep! >>> >>> Can someone write a little example on how to add Settings ? I need this :) >> ok, I will. >> Cheers >> Alain >>> >>> Cheers, >>> >>> Laurent >>> >>> On Thu, May 27, 2010 at 9:56 PM, laurent laffont <laurent.laffont(a)gmail.com <mailto:laurent.laffont@gmail.com>> wrote: >>> >>> On Thu, May 27, 2010 at 4:45 PM, David T. Lewis >>> <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: >>> >>> On Thu, May 27, 2010 at 09:04:37AM +0200, laurent laffont wrote: >>> > Hi Dave, >>> > >>> > I've managed to make it running in Pharo (remove all >>> isMorphic ifFalse ... >>> > stuff, change menu registration, a little work is needed to >>> adapt to Pharo >>> > new settings system). It works (I can publish a package when >>> back at home). >>> > >>> > Now I suppose you want to keep it running on Squeak, I don't >>> know how to >>> > handle differences on world menu and preferences. >>> > >>> > For the MVC part, is there some value in keeping it ? >>> >>> Hi Laurent, >>> >>> Thanks, I would be very interested in seeing your changes, >>> especially the >>> menu registration fixes. >>> >>> >>> For menu registration, add >>> >>> CommandShell class>>#menuCommandOn: aBuilder >>> <worldMenu> >>> (aBuilder item: #'Command Shell') >>> parent: #Tools; >>> action:[self open]; >>> help: 'Smalltalk simulation of a Unix command shell '. >>> >>> and comment / remove Preferences in CommandShell class>>#initialize. >>> >>> >>> Laurent >>> >>> >>> I do want to keep this working on MVC and on other Squeak >>> images. What >>> I really need to do is repackage CommandShell and OSProcess so >>> that >>> everything is not all in two giant packages. I originally >>> "packaged" >>> these many years ago before Squeak had real packages and >>> Monticello, >>> so I basically separated things into two completely separate >>> SAR packages >>> that could be independently maintained (even though >>> CommandShell and >>> OSProcess were intended to work together). That was quite a >>> project >>> at the time, but it is badly out of date now, so I need to go back >>> and make this stuff work properly with Metacello configurations. >>> >>> Dave >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> <mailto:Pharo-project@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

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

Hi goran and stephan It is difficult to follow if we should take action. Apparently we do not have all the story. so if we should something please tell us. Now 1.1 got so much improvements may be it worth to have a look at it. You can find a direct link on 1.1 from http://www.pharo-project.org/home Stef > Hi! > > CCing Pharo list, this was regarding: > > http://goran.krampe.se/blog/Squeak/eblankett-dev.rdoc > > On 05/30/2010 12:00 PM, Stephan Eggermont wrote: >> Hello GÃ¶ran, >> >> Is there a special reason you tried Pharo 1.0? Your improvements are of > > Nope, just (wrongly I agree) thought it was fairly up to date since it was just released. But you are right, depending on release process that does indeed not necessarily correlate. > >> course >> in 1.1. Feature freeze for 1.0 was long ago. If you're willing to use >> the bleeding edge >> in squeak, why not do it in pharo too? > > Again, not a conscious choice. I can use bleeding edge in Pharo too, is there an easy place to start? Earlier I used some core + Renggli scripts to get a decent image. > >> Which peek bugfix is in Squeak? The 2010-1-13 solution is wrong. >> See http://code.google.com/p/pharo/issues/detail?id=1813. > > I will check it out, gotta work on the house now :) > >> Groetjes, >> Stephan Eggermont > > Thanks for the feedback, GÃ¶ran > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 30, 2010

Re: [Pharo-project] How do I install seaside in Pharo 1.0?

by Mariano Martinez Peck

On Sat, May 29, 2010 at 6:43 PM, magique poter <sebovick(a)gmail.com> wrote: > >> I have problem installing Seaside on Pharo 1.0. Evaluate > >> ConfigurationOfSeaside >> workspace > >> did not work. > > > > Hi! > Hello! Thanks for your response, > No problem. > > > In the Smalltalk world, when you see aClass >> aMmethod > > it means that you are talking about the method aMethod from the class > > aClass. > > > > Actually, what you CAN evaluate is something like this: > > > > AClass >> #aMethodName > > > > example > > > > ConfigurationOfSeaside >> #workspace > > There is no ConfigurationOfSeaside class in the Pharo 1.0 image. How > can this work? > > No, it cannot work, as you suspected. That's why you should download first the ConfigurationOfSeaside class. > >> I have also tryed this code: > >> Gofer new > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfSeaside'; > >> load. > >> ((Smalltalk at: #ConfigurationOfSeaside ) project latestVersion) load > >> it did not work to. > >> > > > > > > Try: > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfSeaside30'; > > load. > With this, you download the package ConfigurationOfSeaside30 from the squeaksource project ConfigurationOfSeaside30 This is exactly the same as opening the Monticello Browser, add the package http://www.squeaksource.com/MetacelloRepository Then select the package ConfigurationOfSeaside30 and press the "load" button. > > ((Smalltalk at: #ConfigurationOfSeaside30 ) project latestVersion) load > Ok it works! > > > >> Why does the code > >> DEVImageWorkspaces openExternalProjectWorkspace > >> did not show an easy way to install Seaside (it was the case before)? > >> > > > > What is before and what is now? > > Before (in the late Pharo release), there was a code to evaluate like > other external packages magma, aida, moose... like this: > > "Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside30'; > load. > ((Smalltalk at: #ConfigurationOfSeaside30 ) project latestVersion) load" > > For both seaside2.8 and seaside 3.0. I have found this simple steps to > install external packages very handy for starting programming in > smaltalk, without have to deeply understand the Metacello packages > system (I should start to understand it...). > > Ok...you are right. There were other people that had the same problem and I changed it for Pharo 1.1. Can you please download such image and tell us if is better and give us changes/feedback ? Here is the link: https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… Cheers Mariano > Thanks for your help! > > Sebovick > > Mariano > > > >> > >> Cordialy > >> > >> _______________________________________________ > >> 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 >

May 30, 2010

[Pharo-project] Rome/Athens notes

by Igor Stasenko

Hi, i found rome API very close to OpenVG. Still OpenVG is a bit superior :) So, i'm using it as a guide to model/implement Rome interfaces. So, here is my thoughts (i also having a draft class skeleton for them): Paints: Paint is an object, which when applied to path, renders(draws) the path using paint's unique properties. I defined two methods in paint's base class: fillPath: aPath on: aCanvas self subclassResponsibility strokePath: aPath on: aCanvas self subclassResponsibility So, to draw a path, one should use a concrete paint to either fill it or stroke it (or both, if you want, but its handled by canvas and still will end up with separate fill & stroke requests to paint). I started from a quite basic things: NullPaint Paint which does not performs any drawing. Applying this paint to any path won't lead to any changes/processing. A simple OO approach to define 'nothing' :) SolidColorPaint instanceVariableNames: 'color' Paint with solid color. Most trivial thing which can be done :) RomePen instanceVariableNames: 'paint capStyle joinStyle width dash' A 'pen' paint is just encapsulating a set of properties, which is used for stroke. It is using another paint, which should handle the fills (in 'paint' ivar), while various stroke properties should be handled by itself. Filling with pen, will be the same as filling with its paint. While doing a stoke is different (includes path processing, given the values of pen's properties etc etc). I'm not sure with this part. Maybe stroke properties would be better to leave in canvas? Both OpenVG and Rome seems like following this road, but i don't quite like that stroke properties is global for canvas and lacking a proper encapsulation. CompositePaint Quite dumb thing. Holds a list of paints. When asked to fill or stroke the path, applies paints from own list. GradientPaint (abstract) LinearGradient RadialGradient etc.. paints which will use gradients for fills. Nothing fancy :) Canvas protocol: selectFill: anObject fill := anObject asRomePaintOn: self - selects a paint which will be used for fills. selectPen: anObject pen := anObject asRomePaintOn: self - selects a paint which will be used for stokes. stroke: anObject | path | path := anObject asRomePathOn: self. fill strokePath: path on: self. - stroke a path using currently selected 'pen' paint fill: anObject | path | path := anObject asRomePathOn: self. fill fillPath: path on: self. - fill path using paint for fills fillAndStroke: anObject | path | path := anObject asRomePathOn: self. fill fillPath: path on: self. pen strokePath: path on: self - fill and stroke path. And from that point, i wonder, do we need to have a paint's selection mechanisms at all? Because, we could simply do: canvas fill: myPath with: myPaint instead of: canvas selectFill: myPaint. canvas fill: myPath. Because you anyways can't draw a paths without paints, i don't see why canvas should have a notion of 'current fill' or 'current paint'. I think that with paint's encapsulation, its not necessary. I'd like to hear your thoughts about it. -- Best regards, Igor Stasenko AKA sig.

May 30, 2010