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

Re: [Pharo-project] [ANN] 10209 Watchit integration

by StÃ©phane Ducasse

On Jan 21, 2009, at 5:33 PM, HernÃ¡n Morales Durand wrote: > Thanks! I liked it, it's easier to close the window, particularly > in Pharo where I found not super intuitive how to bring the halos > over a morph. I've updated the SqueakSource adding a 'Watcher' label > in the window too. Yes we should make the halos available on shift or ctlr. Any takers? > There is a lot of things which can be done with this little toy. > One could think in "Watcher Environments" where you can configure > watch points in your image and when a particular condition happens, > the watcher shows up but without stopping execution. Although it's > easier to think in implementing high-level panopticons with the > idea, it has other uses like analyze feedback loops for example or > to detect the value of your predictions about system behaviour. Yeap it is cool. > > Best regards. > > Hernan > > 2009/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I added your code to the bug entry > On Jan 20, 2009, at 9:22 AM, Torsten Bergmann wrote: > > > Hi Stef, > > > >> Now it is nicely integrated in pharo. > > > > Not yet - why not open it in a separate window instead of a plain > > morph on the desk? > > This would be more consistent with inspect it, debug it and explore > > it from the same menu. > > You can also collapse the watch window and move it easily around... > > > > see code below. > > > > Bye > > Torsten > > > > > ----------------------------------------------------------------------------------------- > > watchIt > > > > | result | > > > > self handleEdit: > > [result := textMorph editor compileSelectionAsBlock. > > ((result isKindOf: FakeClassPool) or: [result == > #failedDoit]) > > ifTrue: [^self flash]]. > > (RectangleMorph new) > > layoutPolicy: TableLayout new; > > layoutInset: 3; > > listDirection: #topToBottom; > > hResizing: #shrinkWrap; > > vResizing: #shrinkWrap; > > addMorphBack: (StringMorph contents: textMorph > editor selection); > > addMorphBack: ((UpdatingStringMorph on: result > selector: #value) > > stepTime: 500; > > maximumWidth: nil; > > growable: true); > > color: Color white; > > borderColor: Color black; > > openInWindow > > > > -- > > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit > > allen: http://www.gmx.net/de/go/multimessenger > > > > _______________________________________________ > > 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

Jan. 21, 2009

Re: [Pharo-project] Big problem with the implementation of traits

by StÃ©phane Ducasse

My question was that you removed two traits block of code in one method and added one only to one method. so I was wondering why this was not to two methods (and recompile: false from: oldClass to: newClass was the one you did not change). On Jan 21, 2009, at 2:28 PM, Adrian Lienhard wrote: > > On Jan 20, 2009, at 09:49 , StÃ©phane Ducasse wrote: >> >> Now I was wondering why you did not change >> newClass := self recompile: false from: oldClass to: newClass >> mutate: false. too > > Not sure if I understand what you mean. > > The message #recompile:from:to:mutate: is sent from the two methods I > changed. The important change is that the transfer of the trait > composition has to be done into the class returned by this method, not > into the previous value of newClass (that is, before and and after the > call, the variable newClass points to different instances). > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 21, 2009

Re: [Pharo-project] Plugin organization

by StÃ©phane Ducasse

sounds good to my eyes. regularity is a huge plus to my eyes. I would like to have patterns to organize tests too. We should keep our braincells for real problems. On Jan 21, 2009, at 2:05 PM, Michael Rueger wrote: > Hi all, > > while working on a new (Open)Sophie release I ran into the problem of > where to put some plugin code. In this case it is for the Curl Plugin, > which Steven Riggins ported into Sophie, but the problem is pretty > common I would guess. > > So the problem is this (as illustrated using our Curl package): > > - we have a package Sophie-Curl, which includes the Squeak Curl client > and the CurlPlugin class. > - loaded into a "normal" image, the CurlPlugin ends up being a > subclass > of ProtObject as the superclass is missing. > - now we separate it into Sophie-Curl and Sophie-Curl-Plugin, but that > won't fly with the MC name matching > - so we name it Sophie-Curl and Sophie-Plugin-Curl > > I think that is ugly. > > What I would like to propose is that we organize all plugins in > Pharo in > to a Plugin category. > So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or > alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc. > > That would also allow to simply load all plugins into a VMMaker > image by > using a package "Plugin". > > What do you guys think? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 21, 2009

Re: [Pharo-project] Trait bug to fix....

by Adrian Lienhard

Any suggestion for how to implement this? Without using some reflection tricks, this would imply that the marker methods have to be added and removed depending on the methods added and removed in superclasses. This would significantly complicate the implementation. BTW, this only is an issue if m is implemented as "self explicitRequirement". I never really understood why one would want to explicitly declare requirements. In the end, the difference is to get a different exception than a MNU. If one wants this to see what methods still need to be implemented in a class I would rather suggest to extend the tools to show this (even the ones not explicitly declared) and not use explicit declarations. The algorithm by Nathanael to do exactly this is already in the image. Adrian On Jan 21, 2009, at 21:37 , StÃ©phane Ducasse wrote: >> T requires m >> >> A uses: T >> m ^#fromA >> B subclass: A uses: T >> >> M new m => error explicit requirement > > Begin forwarded message: > >> http://bugs.squeak.org/view.php?id=6534 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 21, 2009

[Pharo-project] Trait bug to fix....

by StÃ©phane Ducasse

> T requires m > > A uses: T > m ^#fromA > B subclass: A uses: T > > M new m => error explicit requirement Begin forwarded message: > http://bugs.squeak.org/view.php?id=6534

Jan. 21, 2009

Re: [Pharo-project] robust indeed!

by Alexandre Bergel

Thanks Cameron for your nice words. I added a link on download link on http://code.google.com/p/pharo/wiki/Downloads?tm=2 to get the virtual machine. Cheers, Alexandre On 20 Jan 2009, at 16:18, Cameron Sanders wrote: > After finding in Damien Cassou's web pages that a clean build of > Pharo uses > version 3.9.1 of the virtual machine, I have found Pharo to be very > solid > with a light-load test. I left the image running for 5 days, with 2 > hours of > browsing code per day (including do-its on classes I wanted to > explore) and > a little code authoring, and the system continued to behave as- > expected. > There were no large and obvious memory losses and no lock-ups. It > appears > very stable -- the image I am using is about 10 days old. > > One problem: none of the first web pages I encountered leading me to > download Pharo indicated which VM to use. (And that's why I first > went to > 3.10.2 and had flaky behavior.) > > Very nice works people! > Gratefully, > Cam > > > _______________________________________________ > 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. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Dale Henrichs

----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > Is it anything like the "dive" feature in VW? I really liked that. | It | > doesn't have to load the whole object tree, which is much faster | when you | > have a really big root object! | | Have a look at earlier versions of OB-Tools. They implement that, I | replaced it with the behavior of the original inspectors after people | complained about it. I think the chasing-style inspector is much | better than the "dive" thing in VisualWorks, because you don't loose | your navigation context with every click. | I'll go ahead and pull my the chasing inspector into OB-Tools, so that folks can play with it. Dale

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Keith Hodges

> s them out. I was worried that if they were held onto in history, > this would be a problem. > > Keeping the strings around would be useful for me - my current image > has about 20 workspaces open (and in 3.10 dev, this results in lots of > minimized window title bars). Being able to store them off in history > would be nice. > > -Chris Sounds like a job for ScriptManager Keith

Jan. 21, 2009

Re: [Pharo-project] [ANN] 10209 Watchit integration

by HernÃ¡n Morales Durand

Thanks! I liked it, it's easier to close the window, particularly in Pharo where I found not super intuitive how to bring the halos over a morph. I've updated the SqueakSource adding a 'Watcher' label in the window too. There is a lot of things which can be done with this little toy. One could think in "Watcher Environments" where you can configure watch points in your image and when a particular condition happens, the watcher shows up but without stopping execution. Although it's easier to think in implementing high-level panopticons with the idea, it has other uses like analyze feedback loops for example or to detect the value of your predictions about system behaviour. Best regards. Hernan 2009/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I added your code to the bug entry > On Jan 20, 2009, at 9:22 AM, Torsten Bergmann wrote: > > > Hi Stef, > > > >> Now it is nicely integrated in pharo. > > > > Not yet - why not open it in a separate window instead of a plain > > morph on the desk? > > This would be more consistent with inspect it, debug it and explore > > it from the same menu. > > You can also collapse the watch window and move it easily around... > > > > see code below. > > > > Bye > > Torsten > > > > > ----------------------------------------------------------------------------------------- > > watchIt > > > > | result | > > > > self handleEdit: > > [result := textMorph editor compileSelectionAsBlock. > > ((result isKindOf: FakeClassPool) or: [result == > #failedDoit]) > > ifTrue: [^self flash]]. > > (RectangleMorph new) > > layoutPolicy: TableLayout new; > > layoutInset: 3; > > listDirection: #topToBottom; > > hResizing: #shrinkWrap; > > vResizing: #shrinkWrap; > > addMorphBack: (StringMorph contents: textMorph editor > selection); > > addMorphBack: ((UpdatingStringMorph on: result selector: > #value) > > stepTime: 500; > > maximumWidth: nil; > > growable: true); > > color: Color white; > > borderColor: Color black; > > openInWindow > > > > -- > > Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit > > allen: http://www.gmx.net/de/go/multimessenger > > > > _______________________________________________ > > 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 >

Jan. 21, 2009

[Pharo-project] Issue 456: BlockContext equality test is missing

by Damien Cassou

Patch in Pharo-Inbox Kernel package: http://code.google.com/p/pharo/issues/detail?id=456 -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 21, 2009