- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Magnitude should be reimplemented as a Trait

by Nicolas Cellier

I'm not comfortable with English, but to me Magnitude is about ordering rather than just comparing. I expect a TOrderable to describe a fully or partially ordered set. If you define this, then it is a fully ordered set: <= aMagnitude ^(self > aMagnitude) not Beware, due to introduction of NaN, Float is not fully ordered, this require overriding above message in Number. Nicolas 2010/8/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks this is cool :) > > Ideally I would like to have a deep look at the trait implementation and understand also how we can make it more pluggable > but I do not have the time for that. > > Stef > > On Aug 29, 2010, at 7:21 AM, jaayer wrote: > >> I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. >> >> Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. >> >> Additionally, I discovered that this message: >> isMetacelloConfig >> Â Â Â ^ false >> >> needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).<TComparable.st>_______________________________________________ >> 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 >

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Tudor Girba

Hi, On 29 Aug 2010, at 12:31, Mariano Martinez Peck wrote: > On Sun, Aug 29, 2010 at 2:39 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com > > wrote: > I've stuck a version (5.8b4) of the cocoa based os-x squeak cog JIT > based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b4.app.zip > > I spent the last two days becoming very familiar with Open/GL and > rewrote the display logic to use > Open/GL. I am still doing some further optimization, but people > should test this version and let > me know what they find. What are the implications of these optimizations? By the sound of it they should influence the rendering. Is that correct? Are there any tests we could do to see the improvements? > Other Fixes. > I think the control-arrow keys should work now, someone test this > and let me know. > > > Yes, it works! Thanks John. Hmm, the control-arrow and control-shift-arrow keys do not work for me. Is there anything in particular I should do to get them working? Cheers, Doru > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Some battles are better lost than fought."

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Mariano Martinez Peck

On Sun, Aug 29, 2010 at 2:39 AM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > I've stuck a version (5.8b4) of the cocoa based os-x squeak cog JIT based > VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b4.app.zip > > I spent the last two days becoming very familiar with Open/GL and rewrote > the display logic to use > Open/GL. I am still doing some further optimization, but people should > test this version and let > me know what they find. > > Other Fixes. > I think the control-arrow keys should work now, someone test this and let > me know. > > Yes, it works! Thanks John. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > >

Aug. 29, 2010

Re: [Pharo-project] OmniBrowser chapter for PBE 2 is now available

by Lukas Renggli

Some comments: - The term "Widget" is not used in the architecture of the OB framework anywhere. Maybe it would be better to replace it with the term "Panel" that is used in the framework. - Figure 1.1 depicts a bug of the un-themed scroll-bar that has been fixed a long time ago when Polymorph was introduced. - p. 9 at the bottom there is a comma disconnected from the previous word. - p. 12 "This enables a smooth gathering of independently realized commands." -> "..., and allows one to cleanly extend existing browsers without having to patch the system (e.g. refactoring browser)." - p. 13 The definition has nothing to do with editable text. By overriding the right methods in the OBNode a node is directly editable as well. The reason to have a separate OBDefintion is only to be able have multiple different definitions for a single node (e.g. to provide different views on source code from an OBMethodNode: source code, byte code, decompiled code, pretty-printed code). - p. 14 "Each of this method should return the class of the command (and not an instance of it)." This is not true. The requirement is that the returned object responds to #on:for:. There are examples where factory objects or OBCommand instances are returned. - p. 15 "These actions enable interaction with the domain model, however they do not allow further navigation in the metagraph." This is not true. There are various ways to navigate and update the metagraph, e.g. aNode signalSelection (see p.20 "Widget notification"). - Figure 1.5 does depict O2, not the "OmniBrowser System Browser" that is described in the text in Section 1.4. - p. 24: The acknowledgements fit to O2, but they seem distorted in the context of OmniBrowser. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 29, 2010

Re: [Pharo-project] Magnitude should be reimplemented as a Trait

by StÃ©phane Ducasse

thanks this is cool :) Ideally I would like to have a deep look at the trait implementation and understand also how we can make it more pluggable but I do not have the time for that. Stef On Aug 29, 2010, at 7:21 AM, jaayer wrote: > I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. > > Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. > > Additionally, I discovered that this message: > isMetacelloConfig > ^ false > > needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).<TComparable.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010

[Pharo-project] Magnitude should be reimplemented as a Trait

by jaayer

I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another. Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well. Additionally, I discovered that this message: isMetacelloConfig ^ false needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).

Aug. 29, 2010

Re: [Pharo-project] New bytecodes not in blue book ...

by Eliot Miranda

2010/8/28 James Ladd <james_ladd(a)hotmail.com> > Hi All, > > I'm looking at translating some bytecodes and they are not specified in the > blue book. > > The following is what I think they mean and I am wondering if someone here > could > confirm? > http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod… > > 97 <8E 00 01> popIntoTemp: 0 inVectorAt: 1 > > pop into temporary at index 0 the value in vector location 0. > vector is at temporary index 1. > > 109 <8C 00 01> pushTemp: 0 inVectorAt: 1 > > push temporary at index 0 into vector location 0. > vector is at temporary index 1 > > 116 <8D 00 01> storeIntoTemp: 0 inVectorAt: 1 > > store into temporary at index 0 the value in vector location 0. > vector is at temporary index 1. > > From what I can tell these bytecodes are added to support closures. > > Rgs, James. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 29, 2010

[Pharo-project] New bytecodes not in blue book ...

by James Ladd

Hi All, I'm looking at translating some bytecodes and they are not specified in the blue book. The following is what I think they mean and I am wondering if someone here could confirm? 97 <8E 00 01> popIntoTemp: 0 inVectorAt: 1 pop into temporary at index 0 the value in vector location 0. vector is at temporary index 1. 109 <8C 00 01> pushTemp: 0 inVectorAt: 1 push temporary at index 0 into vector location 0. vector is at temporary index 1 116 <8D 00 01> storeIntoTemp: 0 inVectorAt: 1 store into temporary at index 0 the value in vector location 0. vector is at temporary index 1. >From what I can tell these bytecodes are added to support closures. Rgs, James.

Aug. 29, 2010

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by John M McIntosh

I've stuck a version (5.8b4) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b4.app.zip I spent the last two days becoming very familiar with Open/GL and rewrote the display logic to use Open/GL. I am still doing some further optimization, but people should test this version and let me know what they find. Other Fixes. I think the control-arrow keys should work now, someone test this and let me know. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 29, 2010

Re: [Pharo-project] OmniBrowser chapter for PBE 2 is now available

by Alexandre Bergel

Yes, this is cool! Alexandre On 28 Aug 2010, at 10:13, Oscar Nierstrasz wrote: > > Hi Folks, > > There is a new draft chapter on the OmniBrowser framework for Pharo by Example 2 now available: > > http://pharobyexample.org// > > Cheers, > - on > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 28, 2010