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

Re: [Pharo-project] [ANN] SystemTracer on SqueakSource

by StÃ©phane Ducasse

excellent initiative. May be you should add jean-baptiste arnaud and mariano since he will have to have a look at them. Jannik was just experimenting to give feedback to john. Stef On Jan 3, 2010, at 6:21 PM, David T. Lewis wrote: > I have created a SqueakSource project called SystemTracing to serve > as a repository for the various SystemTracer implementations that have > appeared in and around Squeak images since Squeak 1.22. The intent is > to make these implementations loadable in modern images, and to provide > a Monticello repository for new development. > > MCHttpRepository > location: 'http://www.squeaksource.com/SystemTracing' > user: 'squeak' > password: 'squeak' > > All classes and package extension methods have been recategoried to > SystemTracing but are otherwise unmodified to the extent possible. > The recategorizing was done by hand-editing the original change sets. > The archive includes historical versions that appeared in early Squeak > images, as well as loadable versions of the SystemTracer2 that is > catalogued on SqueakMap. There is an entry for the SystemTracer64 > that was used to produce the first 64-bit Squeak image, and recent > updates that will enable 64-bit images to be traced from modern > Squeak and Pharo images (there is more work to be done here). > > Developer access is provided for Stephen Pair, John M McIntosh, > Andreas Raab, Eliot Miranda, Jannik Laval, Ian Piumarta. If anyone > else should be added as developer, please speak up. All future > contributions to this archive are required to be MIT licensed. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 3, 2010

Re: [Pharo-project] [Seaside] Mac VM 5.2b1 ships

by Martin PolÃ¡k

Hi, I have tested Squeak 64_32 5.2b1.app with Pharo 1.0rc and tests from my projects (mostly Seaside 2.8 proj.) were green. Input of Czech accented characters works fine. Only problem I had, that I wasn't able to quit VM with Cmd+Q. Regards, Martin PolÃ¡k

Jan. 3, 2010

Re: [Pharo-project] Does OCompletion depend on ECompletion?

by Damien Cassou

2009/12/26 Mariano Martinez Peck <marianopeck(a)gmail.com>: > 0) (mail before)Â OCompletion depend on ECompletion? If true, which packages > ? no, OCompletion is a fork (it includes a modified version of eCompletion). > 1) Does the package OCForOB depend on OCompletion ? yes > > 2) Does the package OCForO2 depend on OCompletion or in OCForOB or in both ? I guess OCForO2 depends on both > 3) Can we put the tests that are in the category "Ocompletion-Tests" under > the package "OCompletion" in a SEPARATE package called "Ocompletion-Tests" > (the same as the category if you want). > > 4) Which packages does OCForOB depend on from OB? Just OmniBrowser or more? > Which ones? > > 5) Which packages does OCForO2 depend on from EnhancedOB? Just OmniBrowser2 > or more? Which ones? > > 6) Does OCompletions depend of Shout ? If true, what packages? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Jan. 3, 2010

Re: [Pharo-project] Issue 1704: Cancelling "extract method" refactoring raises OR2UICancellationError

by Damien Cassou

On Sun, Dec 27, 2009 at 8:58 PM, Danny Chan <chan_dhf(a)yahoo.de> wrote: > In the current 1.0 release candidate I get an UICancellationError when I > select some source code, choose "refactor source/extract method", and > then cancel the dialog asking for the selector name. I can reproduce your problem. It is due to some overrides made by O2. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Jan. 3, 2010

[Pharo-project] [ANN] SystemTracer on SqueakSource

by David T. Lewis

I have created a SqueakSource project called SystemTracing to serve as a repository for the various SystemTracer implementations that have appeared in and around Squeak images since Squeak 1.22. The intent is to make these implementations loadable in modern images, and to provide a Monticello repository for new development. MCHttpRepository location: 'http://www.squeaksource.com/SystemTracing' user: 'squeak' password: 'squeak' All classes and package extension methods have been recategoried to SystemTracing but are otherwise unmodified to the extent possible. The recategorizing was done by hand-editing the original change sets. The archive includes historical versions that appeared in early Squeak images, as well as loadable versions of the SystemTracer2 that is catalogued on SqueakMap. There is an entry for the SystemTracer64 that was used to produce the first 64-bit Squeak image, and recent updates that will enable 64-bit images to be traced from modern Squeak and Pharo images (there is more work to be done here). Developer access is provided for Stephen Pair, John M McIntosh, Andreas Raab, Eliot Miranda, Jannik Laval, Ian Piumarta. If anyone else should be added as developer, please speak up. All future contributions to this archive are required to be MIT licensed. Dave

Jan. 3, 2010

[Pharo-project] Help with CurveFitter

by Alexandre Bergel

Dear List, For Mondrian, I encounter a problem with CurveFitter. I tried to isolate the problem in the following code. You just need to doIt in a workspace: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | myMorph window pane morphCls | morphCls := Morph subclass: #MyTestMorph. morphCls compile: 'drawOn: aCanvas | curve | super drawOn: aCanvas. aCanvas fillOval: (10@30 corner: 150@290) color: Color lightRed borderWidth: 4 borderColor: Color black. curve := CurveFitter new. curve form: ((Form extent: 4@4 depth: Display depth) fillWithColor: Color lightBlue; yourself). curve firstPoint: 10@30. curve secondPoint: 40@150. curve thirdPoint: 140@290. curve displayOn: aCanvas form. '. myMorph := morphCls new. myMorph extent: 3000 @ 2000. window := SystemWindow labelled: 'My Example'. window extent: 640 @ 480. pane := ScrollPane new. pane scroller addMorph: myMorph. window addMorph: pane fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)). window openInWorld. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= What I would like to have, is the curve to go with the oval when I use the scrollbar. Any idea how to fix this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 3, 2010

[Pharo-project] Save As breaks when the image name ends with ..image

by StÃ©phane Ducasse

in 11131 if you do saveAs foo..image then saveAs -> you get an error. Stef http://code.google.com/p/pharo/issues/list?cursor=1734 Fixed splitNameVersionExtensionFor: fileName " answer an array with the root name, version # and extension. See comment in nextSequentialNameFor: for more details" | baseName version extension i j | baseName := self class baseNameFor: fileName. extension := self class extensionFor: fileName. i := j := baseName findLast: [:c | c isDigit not]. i = 0 ifTrue: [version := 0] ifFalse: [(baseName at: i) = $. ifTrue: [version := [(baseName copyFrom: i+1 to: baseName size) asNumber] on: Error do: [:ex| 0]. j := j - 1] ifFalse: [version := 0]. baseName := baseName copyFrom: 1 to: j]. ^ Array with: baseName with: version with: extension

Jan. 3, 2010

Re: [Pharo-project] Does someone know why Nile is in Dev images?

by Schwab,Wilhelm K

Mariano, You _like_ the new inspector???? :) Can't stand it myself. If I want that kind of view, I use the explorer. Selecting the standard toolset (so far at least) makes it "go away," so I'm happy. One thing that I miss is the diving inspector that started in VW (IIRC) and was ported to Dolphin. Nile causes me no trouble, and I am glad to see movement away from the Squeak streams. We will not be able to rid ourselves of the latter w/o elevating Nile to being a part of the system. Your point about putting it in the core is well-taken, but I think having it in the dev/web images is a good thing because it should help drive Moose and other groups to dev as opposed to the core. Given our obvious need to test before releasing the dev/web images, anything that promotes their use is helpful. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Sunday, January 03, 2010 7:03 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Does someone know why Nile is in Dev images? Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of very good people have worked and is still working in Nile project. So, I am sure it is an excellent product. However, I don't think it should be in Dev image. Dev image is for "Developers". So, we put tools like NewInspector, RoelTyper, E and OCompletion, Refactoring, etc. But why Nile ? I am not agree this is neither a way to push Nile to be used. It is no difference if you already have the code in the image or not, it is just one click of difference (as you have the Nile-All). Even if it where the case, I think it should be in Core image. The way to push a project to be used is to write documentation, tutorials, show the benefits over other implementations....and so on. If Moose use it, ok, put it as a dependency. Now you have a Metacello configuration for Moose :) I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses Slime and it is not in the image. Just my opinion. I hope no one feels offended. What others think about this ? Cheers Mariano On Sun, Jan 3, 2010 at 11:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Nile is in dev because it should be progressively use to replace existing streams. For example in Moose some important collection extensions depend on it. > Does another package of the dev image depends on Nile? If not, I don't understand why it is part of the dev image. I see it as any other external package but not a "dev tool" that should be included. > > Thanks > > Mariano > _______________________________________________ > 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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 3, 2010

Re: [Pharo-project] Does someone know why Nile is in Dev images?

by Alexandre Bergel

Hi Mariano, I haven't got the chance yet to use Nile unfortunately. But excluding it from Pharo will dramatically reduce the chance that people will look at it. Cheers, Alexandre On 3 Jan 2010, at 13:03, Mariano Martinez Peck wrote: > Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a > lot of very good people have worked and is still working in Nile > project. So, I am sure it is an excellent product. > > However, I don't think it should be in Dev image. Dev image is for > "Developers". So, we put tools like NewInspector, RoelTyper, E and > OCompletion, Refactoring, etc. But why Nile ? > > I am not agree this is neither a way to push Nile to be used. It is > no difference if you already have the code in the image or not, it > is just one click of difference (as you have the Nile-All). Even if > it where the case, I think it should be in Core image. The way to > push a project to be used is to write documentation, tutorials, show > the benefits over other implementations....and so on. > > If Moose use it, ok, put it as a dependency. Now you have a > Metacello configuration for Moose :) > I mean, in SqueakDBX we use FFI and we don't put in the image. > Seaside uses Slime and it is not in the image. > > Just my opinion. I hope no one feels offended. > > What others think about this ? > > Cheers > > Mariano > > On Sun, Jan 3, 2010 at 11:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > Nile is in dev because it should be progressively use to replace > existing streams. > For example in Moose some important collection extensions depend on > it. > > > > Does another package of the dev image depends on Nile? If not, I > don't understand why it is part of the dev image. I see it as any > other external package but not a "dev tool" that should be included. > > > > Thanks > > > > Mariano > > _______________________________________________ > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 3, 2010

Re: [Pharo-project] Code Critics pragmas for classes - do they need to be on instance *and* class side?

by Lukas Renggli

> I was specifically thinking of "class not referenced", which seems strange > to have to put on both sides. But I suppose there could be other class > checks for which there could be utility in treating Â class and instance > separately; I haven't come across a case so far. Ok, you convinced me. I've fixed this (but not tested it) in Refactoring-Core-lr.93. Let me know if this is better. Name: Refactoring-Core-lr.93 Author: lr Time: 3 January 2010, 3:25:42 pm UUID: c8f01646-b4cc-420a-a05e-dd8a0a81a305 Ancestors: Refactoring-Core-TestRunner.92 - for lint issues in class environments filter the instance and class side Lukas > > ...Stan > > -- > View this message in context: http://n2.nabble.com/Code-Critics-pragmas-for-classes-do-they-need-to-be-on… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 3, 2010