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

Re: [Pharo-project] [Moose-dev] Re: Implementing a DSM in SqMondrian

by Alexandre Bergel

> I guess this mail was supposed to go to moose-dev :). Yes. Apologies to my Pharo fellows. >> I was wondering what the best strategy to implement a DSM will be. I >> see two different strategies: >> 1 - Building the matrix with a formsBuilder. Each shape contained in >> the builder is therefore a cell of the DSM. >> 2 - Having an MONode for each cell. >> >> I would favor option 2, but a special layout need to be defined >> right? > > In VW, you can already do that through "formsBuilder asLayout". I > used this to build an evolution matrix that can be align nicely both > vertically and horizontally. Ah yes! thanks! >> Doru, you said once that Mondrian may not be adapted to build DSM. I >> do not understand (or even feel) why. May you comment on this? > > You can, but it won't be optimal. The reason is that for any > significantly sized matrix you will not want to represent each cell > as an object, but rather treat the complete matrix as one smart > object that optimizes the display. Yes, it makes sense. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 14, 2009

Re: [Pharo-project] Implementing a DSM in SqMondrian

by Tudor Girba

Hi Alex, I guess this mail was supposed to go to moose-dev :). > I was wondering what the best strategy to implement a DSM will be. I > see two different strategies: > 1 - Building the matrix with a formsBuilder. Each shape contained in > the builder is therefore a cell of the DSM. > 2 - Having an MONode for each cell. > > I would favor option 2, but a special layout need to be defined right? In VW, you can already do that through "formsBuilder asLayout". I used this to build an evolution matrix that can be align nicely both vertically and horizontally. > Doru, you said once that Mondrian may not be adapted to build DSM. I > do not understand (or even feel) why. May you comment on this? You can, but it won't be optimal. The reason is that for any significantly sized matrix you will not want to represent each cell as an object, but rather treat the complete matrix as one smart object that optimizes the display. Cheers, Doru > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- www.tudorgirba.com "Beauty is where we see it."

Feb. 14, 2009

[Pharo-project] Implementing a DSM in SqMondrian

by Alexandre Bergel

Hi! I was wondering what the best strategy to implement a DSM will be. I see two different strategies: 1 - Building the matrix with a formsBuilder. Each shape contained in the builder is therefore a cell of the DSM. 2 - Having an MONode for each cell. I would favor option 2, but a special layout need to be defined right? Doru, you said once that Mondrian may not be adapted to build DSM. I do not understand (or even feel) why. May you comment on this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 14, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by Keith Hodges

> So this means that we should integrate changes. I'm planning to go > over kernel extensions Why? we dont use it any more, it was split up into fixes on mantis. Unfortunately this approach, while allowing you to add only the fixes needed for a particular package, doesn't enable them to be unloaded. For the important ones, download http://ftp.squeak.org/3.11/3.10.2-build/090213-0428-Squeak3.10.2-build-beta… and view the change sets, together with the instance side of Squeak310MakeBuildCandidate. I think that you will find that you have most of them already. cheers Keith

Feb. 14, 2009

[Pharo-project] SqMondrian

by Alexandre Bergel

Hi All, I was wondering why is there a method originFor: in FormsBuilder. In VW there is none. Why the builder should know about the bounds of the element to display? I always though the shape was in charge of it. Something else, both in Squeak and VW we have the following method: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= FormsBuilder>>at: aX and: aY "Utility method that makes other methods easier to read." ^self components select: [:component | component gridX = aX and: [component gridY = aY]] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Is there a reason to not store the components in a matrix ? One reason that I see, is that one could have a large compound contains only few elements in it. But still, I find that strange. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 14, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by Geert

StÃ©phane Ducasse-2 wrote: > > what is cruelly needed is a build integration server. Keith is working on > Bob and he needs help. > > Now what is needed is that people go also over the code of keith to > minimize overrides and other things, else we will have again such > discussion and people will get frustrated and think we are assholes (which > is not the case) :). In pharo we really want to avoid overrides and > extensions for the sake of them. So this means that we should integrate > changes. I'm planning to go over kernel extensions today. following the > mail and analysis we did with damien in october (argh) > > Stef > I reckon you guys are all doing a great job! I just feel like I am way too inexperienced to go over the code you guys write. I am actually more a Myers-Briggs (ENFP) visionary type of person and I am looking forward to be able to use Pharo Smalltalk as a platform to bring some of my ideas come to live :P Maybe that's why I am thinking more in terms of high level infrastructure and architecture? Anyway, I will be following this project closely and I will try to get up to speed ASAP so I will ask less silly questions here :) -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p23… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 14, 2009

[Pharo-project] about getting more SmallLint rules

by StÃ©phane Ducasse

lukas I would love to have a rule to check the uses of PopUpMenu, FillInTheBlank and friends :) Stef

Feb. 14, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by StÃ©phane Ducasse

what is cruelly needed is a build integration server. Keith is working on Bob and he needs help. Now what is needed is that people go also over the code of keith to minimize overrides and other things, else we will have again such discussion and people will get frustrated and think we are assholes (which is not the case) :). In pharo we really want to avoid overrides and extensions for the sake of them. So this means that we should integrate changes. I'm planning to go over kernel extensions today. following the mail and analysis we did with damien in october (argh) Stef On Feb 14, 2009, at 1:17 AM, Geert wrote: > > > Keith Hodges wrote: >> >> Squeaksource is the place to manage the source that makes up a >> project. >> You can also set up your own repositories (with ftp for example), >> much >> like other scm tools. >> >> SqueakMap/Universes/ and Sake/Packages are places to publish the >> end results of projects, for others to load. >> >> SqueakMap - is intended to be the directory of all packages, but it >> doesn't support dependencies. >> >> Universes - has packages with dependencies targeted for a specific >> version of squeak. >> >> Sake/Packages >> - has package definitions browseable in a standard class browser >> - supports dependencies >> - supports unloading >> - load current published / or latest beta code it can find >> >> hope this helps clarify our murky world >> >> Keith >> > > Thanks Keith, I had not heard of Sake before ... other than it being a > beautiful Japanese beverage :) > > All these things do seem to serve a different purpose. Would it be > an idea > to simplify things a bit to make it easier to collaborate, share and > innovate? > -- > View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p23… > 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 >

Feb. 14, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by Geert

Keith Hodges wrote: > > Squeaksource is the place to manage the source that makes up a project. > You can also set up your own repositories (with ftp for example), much > like other scm tools. > > SqueakMap/Universes/ and Sake/Packages are places to publish the > end results of projects, for others to load. > > SqueakMap - is intended to be the directory of all packages, but it > doesn't support dependencies. > > Universes - has packages with dependencies targeted for a specific > version of squeak. > > Sake/Packages > - has package definitions browseable in a standard class browser > - supports dependencies > - supports unloading > - load current published / or latest beta code it can find > > hope this helps clarify our murky world > > Keith > Thanks Keith, I had not heard of Sake before ... other than it being a beautiful Japanese beverage :) All these things do seem to serve a different purpose. Would it be an idea to simplify things a bit to make it easier to collaborate, share and innovate? -- View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p23… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 14, 2009

Re: [Pharo-project] Adding a new class category

by Alexandre Bergel

It works. Thanks Cheers, Alexandre On 11 Feb 2009, at 21:13, David RÃ¶thlisberger wrote: > >> Thanks David. Let me know, I am ready to test again > > I fixed it. > You can give it a try using OBAlpha. > > David > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 13, 2009