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

[Pharo-project] [update 1.1] #11155

by StÃ©phane Ducasse

11155 ----- - Issue 1805: Bitmap fonts need reinitialization StrikeFont installDejaVu - Merged CompilerTests.lr.17.mcz merged Compiler-cwp.73.mcz from Colin "The compiler now uses notifications to signal that a correctable error has been found in the method source, rather than interacting directly with the user." - Issue 332: Arithmetic protocol should be removed from Collections and Strings I took the decision to remove the arithmetic protocol from collections and if people want it back we still can but if was not really complete and well done. Stef

Jan. 13, 2010

Re: [Pharo-project] Was: "I cannot believe. . ." on Object implementation

by csrabak＠bol.com.br

I share this dream and invite you folks to envision a such implementation that becomes an example of good OOP techniques. Nowadays we have to avoid using Object to show any good practice. . . Em 13/01/2010 07:54, Igor Stasenko < siguctua(a)gmail.com > escreveu: Kill them , please. :) I dreaming about the time, when every method in Object will have a very strong reasons to stay there. 2010/1/13 StÃ©phane Ducasse : > hold on :) > we will kill a lot of them one at a time with a nice chainsaw :) > > Stef > > On Jan 13, 2010, at 8:58 AM, Lukas Renggli wrote: > >> And #defaultColor and #inform: and #modelSleep and #modelWakeUp and >> #modelWakeUpIn: and ... >> >> 2010/1/12 StÃ©phane Ducasse : >>> argh....... >>> May be not putting everything in Object would help. >>> >>> Stef >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 > -- 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

Jan. 13, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Igor Stasenko

2010/1/13 Martin McClure <martin(a)hand2mouse.com>: > Eliot Miranda wrote: >> A *much* better way to implement this is to support immutability in the >> VM (I know, I know, but all the code is available in the Newspeak VM), >> mark objects one wants to mark as dirty as immutable, catch the >> NoModificationError exception, and proceed after having made the object >> mutable and marked it dirty. Â No creating hidden classes, no trying to >> get change class to work for compact classes, etc. Â Just a simple >> VM-implemented write barrier that can also be used for a host of other >> things (object-database mapping, debugging, immutable literals etc). > > Since object dirtying is at the core of the product I work with, and > I've worked extensively with both methods of implementing write barriers... > > I very strongly agree with Eliot. *So* much nicer a way to do this. > It could be more efficient, in respect that you don't need to create shadow classes. But triggering exception leads to stack unwinding to find a handler, which inevitably leads to deoptimizing all contexts.. and if stack depth is high (between point of writing attempt and hook, where magma will handle exception), this will be much slower than WriteBarrier implementation, described by Cris, which checking the value in-place, without the need of touching exception machinery. Just 2 cents. > Regards, > > -Martin > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2010

Re: [Pharo-project] Flaw in SocketStream>>peek detected

by Igor Stasenko

http://bugs.squeak.org/view.php?id=7446 -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Martin McClure

Eliot Miranda wrote: > A *much* better way to implement this is to support immutability in the > VM (I know, I know, but all the code is available in the Newspeak VM), > mark objects one wants to mark as dirty as immutable, catch the > NoModificationError exception, and proceed after having made the object > mutable and marked it dirty. No creating hidden classes, no trying to > get change class to work for compact classes, etc. Just a simple > VM-implemented write barrier that can also be used for a host of other > things (object-database mapping, debugging, immutable literals etc). Since object dirtying is at the core of the product I work with, and I've worked extensively with both methods of implementing write barriers... I very strongly agree with Eliot. *So* much nicer a way to do this. Regards, -Martin

Jan. 13, 2010

Re: [Pharo-project] Comments on Metacello and ConfigurationOfExternalWebBrowser

by Dale Henrichs

----- "Torsten Bergmann" <astares(a)gmx.de> wrote: | >And the other thing is that you put everything under spec for: | #common | | Depends on the meaning of common (only Pharo and other Squeak | Distributions) or does it include other Smalltalks (VW, VAST) too? | If Metacello gets ported then you are right. | | The tutorial only says: | "In addition to #common, there are pre-defined attributes for each of | the | platforms upon which Metacello runs (#pharo, #squeak, #gemstone and | #squeakCommon)." | | However FFI (which is definitely limited to Squeak derivates) | is also #common and I used it as a template. | | Maybe #squeakCommon is right for FFI and ExternalWebBrowser | since this is what is used in the seaside, swazoo, ... configs. Torsten, My opinion on the platform attributes (#pharo, #squeak, #gemstone and #squeakCommon) is that attribute should reflect intention. If the code that is being configured is intended to run on all platforms, then using the #common attribute is fine. In the MetacelloRepository, the primary motivation for the configurations is to specify the packages and versions that are to be loaded into the Pharo environment and reflects the decisions made by the Pharo developers. Therefore, it makes a lot of sense to use the #pharo platform for those configurations, because the target environment for the configuration _is_ Pharo. The ConfigigurationOfOmniBrowser is an interesting example. OmniBrowser runs on GemStone, Pharo and Squeak, but the choice of which specific packages to load is likely to be different for each platform (for a variety of reasons). So I don't think there is an absolutely right answer to the question. Besides, even though code is intended to run on all three platforms, over time changes may be made that make in non-portable to one or more platforms, so even with the best intentions... Much like the underlying code base, if the configuration is actively used and maintained, each configuration will eventually find a steady state answer that works. Dale

Jan. 13, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Chris Muller

Sounds great, I agree that is cleaner than the old WriteBarrier hack. Of course, I'd also like look into using a JIT-compiler enabled VM that can make *everything* a bit faster, not just Magma commits.. 2010/1/13 Eliot Miranda <eliot.miranda(a)gmail.com>: > A *much* better way to implement this is to support immutability in the VM > (I know, I know, but all the code is available in the Newspeak VM), mark > objects one wants to mark as dirty as immutable, catch the > NoModificationError exception, and proceed after having made the object > mutable and marked it dirty. Â No creating hidden classes, no trying to get > change class to work for compact classes, etc. Â Just a simple VM-implemented > write barrier that can also be used for a host of other things > (object-database mapping, debugging, immutable literals etc). > > On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <asqueaker(a)gmail.com> wrote: >> >> A great description of what WriteBarrier does and how it works can be >> found in the WriteBarrier class-comment, itself. >> >> In a nutshell, when an object is added to a WriteBarrier, a subclass >> is dynamically compiled for it, but not added to the Smalltalk >> dictionary. Â The name of the class is the same as its superclass but >> with a '*' appended to it. >> >> After creating the subclass, WriteBarrier looks at all "definitions" >> of each instance variable, and adds methods to override the methods in >> its superclass. Â The generated override checks the pre-state of the >> instVar, calls super, then compares the post-state of the instVar to >> the pre-state. >> >> If it changed, it signals so that the application (Magma) can mark it >> dirty. >> >> So, it allows Magma to operate with a smaller readSet, which speeds up >> the part of the commit process relating to detection of changed >> objects for building the CommitPackage which is shipped off to the >> server.. >> >> Â - Chris >> >> 2010/1/13 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: >> > El miÃ©, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribiÃ³: >> >> Can someone clarify, why WriteBarrier depends on compiler (new >> >> compiler or old compiler - not really important). >> >> I just wonder what compiler functionality its depends on. >> > >> > WriteBarrier uses the class BytecodeGenerator that is part of the >> > package NewCompiler (that is currently on rewrite for the closure >> > images). Why it need it and how it use it, I really don't know. I have >> > only a vague idea of what WriteBarrier does, and as Mariano said, I use >> > Magma but never used or activated the WriteBarrier functionality of it. >> > >> > Cheers >> >> >> >> 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> > >> >> > >> >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <asqueaker(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> 2010/1/12 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> > Magma depends on NewCompiler ??? >> >> >> >> >> >> No, WriteBarrier depends on NewCompiler. >> >> >> >> >> >> Magma can, at the explicit option of the user, turn on the >> >> >> WriteBarrier option if the WriteBarrier package is present. >> >> >> WriteBarrier used to be self-contained, later it became dependent on >> >> >> NewCompiler. >> >> >> >> >> >> Unless the WriteBarrier option is switched on by the user, its >> >> >> presence or absence in the image (as well as NewCompiler) has no >> >> >> effect on Magma. >> >> >> >> >> > >> >> > Thanks for the clarification Chris. It was strange for me that Â as I >> >> > used >> >> > Magma a couple of times and I never installed WriteBarrier neither >> >> > NewCompiler. >> >> > >> >> > Cheers >> >> > >> >> > Mariano >> >> > >> >> > >> >> >> >> >> >> Â - Chris >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> > >> >> >> >> >> >> >> >> -- >> >> 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 >> > >> > -- >> > Miguel CobÃ¡ >> > http://miguel.leugim.com.mx >> > >> > >> > _______________________________________________ >> > 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. 13, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Eliot Miranda

A *much* better way to implement this is to support immutability in the VM (I know, I know, but all the code is available in the Newspeak VM), mark objects one wants to mark as dirty as immutable, catch the NoModificationError exception, and proceed after having made the object mutable and marked it dirty. No creating hidden classes, no trying to get change class to work for compact classes, etc. Just a simple VM-implemented write barrier that can also be used for a host of other things (object-database mapping, debugging, immutable literals etc). On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <asqueaker(a)gmail.com> wrote: > A great description of what WriteBarrier does and how it works can be > found in the WriteBarrier class-comment, itself. > > In a nutshell, when an object is added to a WriteBarrier, a subclass > is dynamically compiled for it, but not added to the Smalltalk > dictionary. The name of the class is the same as its superclass but > with a '*' appended to it. > > After creating the subclass, WriteBarrier looks at all "definitions" > of each instance variable, and adds methods to override the methods in > its superclass. The generated override checks the pre-state of the > instVar, calls super, then compares the post-state of the instVar to > the pre-state. > > If it changed, it signals so that the application (Magma) can mark it > dirty. > > So, it allows Magma to operate with a smaller readSet, which speeds up > the part of the commit process relating to detection of changed > objects for building the CommitPackage which is shipped off to the > server.. > > - Chris > > 2010/1/13 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > > El miÃ©, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribiÃ³: > >> Can someone clarify, why WriteBarrier depends on compiler (new > >> compiler or old compiler - not really important). > >> I just wonder what compiler functionality its depends on. > > > > WriteBarrier uses the class BytecodeGenerator that is part of the > > package NewCompiler (that is currently on rewrite for the closure > > images). Why it need it and how it use it, I really don't know. I have > > only a vague idea of what WriteBarrier does, and as Mariano said, I use > > Magma but never used or activated the WriteBarrier functionality of it. > > > > Cheers > >> > >> 2010/1/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> > > >> > > >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <asqueaker(a)gmail.com> > wrote: > >> >> > >> >> 2010/1/12 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> > Magma depends on NewCompiler ??? > >> >> > >> >> No, WriteBarrier depends on NewCompiler. > >> >> > >> >> Magma can, at the explicit option of the user, turn on the > >> >> WriteBarrier option if the WriteBarrier package is present. > >> >> WriteBarrier used to be self-contained, later it became dependent on > >> >> NewCompiler. > >> >> > >> >> Unless the WriteBarrier option is switched on by the user, its > >> >> presence or absence in the image (as well as NewCompiler) has no > >> >> effect on Magma. > >> >> > >> > > >> > Thanks for the clarification Chris. It was strange for me that as I > used > >> > Magma a couple of times and I never installed WriteBarrier neither > >> > NewCompiler. > >> > > >> > Cheers > >> > > >> > Mariano > >> > > >> > > >> >> > >> >> - Chris > >> >> > >> >> _______________________________________________ > >> >> 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 > >> > > >> > >> > >> > >> -- > >> 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 > > > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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. 13, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Henrik Johansen

On Jan 13, 2010, at 7:00 23PM, Levente Uzonyi wrote: > On Wed, 13 Jan 2010, Henrik Johansen wrote: > >> >> On Jan 13, 2010, at 6:06 53PM, Schwab,Wilhelm K wrote: >> >>> That's great news, at least for mac users. What does a penguin herder do to get a plugin? >> >> 1) Download VM sources for latest release from www.squeakvm.org. >> 2) Make an image with VMMaker and AlienPlugin. >> 3) Use VMMakerTool to generate AlienPlugin sources. >> 4) (possibly) use special sqVirtualMachine.c/h from the \Cross\plugins\IA32ABI folder. >> 5) Try to compile, fix errors that pop up. >> 6) Repeat step5 enough times that you end up with a compiled plugin. > > 7) Run the tests and wonder why your plugin doesn't work. Repeat 1-7 a few times. > 8) Give up and wait till someone else succeeds. Well, yes. > >> >> >>> Would it be easier to use a squeak image to build it? >> Only step 2, unless you load from www.squeaksource.org/JBARepo, and run VMMakerLoader loadAndFix. > > I wonder why are these packages forked. It's not really forked, just installing versions different to what is in VMMaker repository that needs to be changed to work with Pharo. In specific, the two I remember: - One of the methods specified in MiscPrimitivePlugin didn't work/return an error for WideStrings. The solution in Pharo was to introduce an extra layer of indirection, since the method itself was called many places, the original definition was moved to a method called ...viaPrimitive (should be renamed prim...), and handling introduced before prim call was made. (using fallback instead if param was WideString). - One of the methods used by VMMaker had a spelling error, which has been fixed in Pharo, something with occurrencesOf: I think. Cheers, Henry

Jan. 13, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Levente Uzonyi

On Wed, 13 Jan 2010, Henrik Johansen wrote: > > On Jan 13, 2010, at 6:06 53PM, Schwab,Wilhelm K wrote: > >> That's great news, at least for mac users. What does a penguin herder do to get a plugin? > > 1) Download VM sources for latest release from www.squeakvm.org. > 2) Make an image with VMMaker and AlienPlugin. > 3) Use VMMakerTool to generate AlienPlugin sources. > 4) (possibly) use special sqVirtualMachine.c/h from the \Cross\plugins\IA32ABI folder. > 5) Try to compile, fix errors that pop up. > 6) Repeat step5 enough times that you end up with a compiled plugin. 7) Run the tests and wonder why your plugin doesn't work. Repeat 1-7 a few times. 8) Give up and wait till someone else succeeds. > > >> Would it be easier to use a squeak image to build it? > Only step 2, unless you load from www.squeaksource.org/JBARepo, and run VMMakerLoader loadAndFix. I wonder why are these packages forked. Levente > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 13, 2010