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

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

by Dale Henrichs

Torsten, Thanks for the feedback! It is much appreciated. I've interspersed comments below. ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | On Wed, Jan 13, 2010 at 2:41 PM, Torsten Bergmann <astares(a)gmx.de> | wrote: | | > Played with Metacello: | > | | First, there is a Metacello mailing list, which I think would be more | accurated that this one. The groups is: | http://groups.google.com/group/metacello | | | > 1. there are various typos in the lessons of the tutorial | > (looks like it was really written in a hurry) | > | > | They are doing an excellent work. You cannot ask more. In addition, | if you | saw the typos, an if it was even versioned code, why didn't you fix | them and | commit ? I appreciate the feedback. I am not a professional writer, but basic documentation is required for Metacello, so I have been doing my best. The best way to deal with issues that you find in the code (including the tutorial) is to submit a bug report (http://code.google.com/p/metacello/issues/entry) If you are motivated to work on Metacello, let me know and I will add you as a developer to the repository as well as add you to the Metacello code project (http://code.google.com/p/metacello/) | | | | > 2. there are two special groups introduced in lesson10 | > "default" and "ALL" - why in a different case? | > | > | I don't know. If you read through earlier Metacello communication, you will find that I have admitted that I am poor at naming things (I am not a professional namer either:). For the most part I have listened to and changed things based on feedback. With that said, I have no good reason for the difference. They are two special strings. I prefer bug reports for issues that you deem important, then I won't lose track of them and will be able to address them in due time. | | | > 3. if these are special then it would be nice to | > have | > | > (MetacelloTutorialConfig project version: '1.0') loadAll. | > (MetacelloTutorialConfig project version: '1.0') loadDefault. | > | > | +1 I think I already told this to Dale at my beginning with | Metacello. #loadDefault is already handled. When you send #load to a version, the 'default' group is loaded (if defined), otherwise all of the packages are loaded. I've been holding off adding too many helper methods, not because they aren't useful, but because Metacello is still fairly new. With the Loader in the pipeline, it may turn out that normal users will never have to send messages directly to the configuration...over time if the usage patterns demand helper methods I will definitely add them. | | | > 4. lesson11Author | > Is the author the initials or the full name? | > | > | Which is the difference between Author and Full name ? Don't put | initials. This part of the code was developed while initials were still used on all three platforms (gemstone, pharo and squeak). Pharo has moved to Full Name and on Pharo, the Full name is used ... I happen to do my development with the full name set to my initials so I understand the confusion (see Issue 44: http://code.google.com/p/metacello/issues/detail?id=44) | | | > In Java's Maven POM (Project Object Model, an XML style | > with project infos) one can specify full developer | > informations, which is good when working in a large team: | > http://maven.apache.org/pom.html#Developers | > That is a very good point. The first order priority for Metacello is to take of the functionality first, if it doesn't do the primary job, then it doesn't matter whether the important, but secondary information is included. I agree that there is a lot of useful information that can be added to the project specs and over time it will be added. Dale

Jan. 13, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Chris Muller

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

Jan. 13, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Mariano Martinez Peck

On Wed, Jan 13, 2010 at 5:43 PM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > Hi, just added ConfigurationOfAlien to the MetacelloRepository. > > > To load Alien using Metacello configurations evaluate > > Gofer new > url: 'http://www.squeaksource.com/MetacelloRepository' ; > package: 'ConfigurationOfAlien'; > load. > (ConfigurationOfAlien project version:'1.0') load. > > > ( John please update the ALIEN squeaksource page with the previous text ) > > > Excellent!!!! Hi Fernando: I checked the Conf, I hope you don't bother if I give you some feedback. In version1: try to put mostly only versions. Static information like spec package: 'Alien-Core' with: [ spec requires: #( 'Alien-Prereqs' ) ]. would be better to put them in the baseline. All static and structure information (groups, requieres, etc) should go in baseline. And in version, only versions, author, date, description, blessing, etc. Post and preload for exaple, it depends. Is they are likely to be always the same, put them in baseline. If they are particular for a version, put them in version. In your case I think they should go on baseline. You didn't put the dependency from Alien-CoreTest to Alien. Think that every package should be perfectly loaded. So, if Alien-CoreTest depends on Alien-Core, then, you have to put it. The same with the examples. > Note: > Using the available MAC VM i the pharo page, you should be able to > run the test correctly. > ( the alien plugin 'IA32ABI 7 May 2009 (e)', is compiled inside that > vm, there's no need for the external one) > > > Metacello question: > > If i want load Alien Examples, the package Alien-MacOSExamples, but don't > want to add them to the above configuration , should i create a new > #versionXXX method ? > > Or provide a class side method like for example > > ConfigurationOfAlien>>loadWithMaxOsExamples > (ConfigurationOfAlien project version:'1.0') > load:#('Alien-MacOsExamples') > > In my opinion, neither. I would use groups for this. Something like this in baseline mehtod: spec group: 'default' with: #('Core' ); group: 'Core' with: #( 'Alien-Core' ); group: 'Tests' with: #( 'Alien-CoreTest' ); group: 'Examples' with: #('Alien-MacOSExamples' ); Then to load the project, you can evaluate: (ConfigurationOfAlien project version: 'xxxx') load (this will install the default, which is core) (ConfigurationOfAlien project version: 'xxxx') load: 'Tests' will load that group or: (ConfigurationOfAlien project version: 'xxxx') load: #('Core' 'Tests' 'Examples' ) and will load everything. For more information you can look in MetacelloRepository, there are a lot of examples. Cheers Mariano > > Saludos, > Fernando > _______________________________________________ > 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] clone vs shallowCopy

by Eliot Miranda

On Tue, Jan 12, 2010 at 11:55 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Now it would be nice to clean that because in VW you have copy, shallowCopy > and postCopy and it works. > They removed veryDeepCopy and other friends even when they were at the time > were they could burn engineering time > on that. > > I think you'll find VW has Object>>dcopy, which is essentially the same as veryDeepCopy, a structure-preserving graph copy. So VW has shallowCopy, copy built upon shallowCopy and postCopy, and dcopy. IMO all three are useful. Old deepCopy is not. > So for me clone is one too many. > And worse cloning and object cannot be a shallowCopy semantics. it should > be more a veryDeepInnerVeryCopy (I could not resist sorry) > Of course we already clean and remove the veryDeepInnerCopy.... No comment. > > >>> - #copy is the normal copy operation. It should be used by default and > >>> never overridden. It calls #postCopy that can be overridden to have > >>> class specific copy semantics. > >>> > >>> - #shallowCopy does a shallow copy. It should never be overridden and > >>> only be used if you want to get these very specific semantics. > >>> > >>> - #deepCopy does a deep copy. It should never be overridden and only > >>> be used if you want to get these very specific semantics. > >>> > >>> - #clone comes from eToys and Morphic (AFAIK). It implements some > >>> other copy semantics than #copy. I don't think that anybody should > >>> call this method, other than code that depends on this particular copy > >>> behavior. > >> > >> we should copy that in Object class comment and all the methods > >> > >> > >> where do you see that it is morphic related for me clone is only > implemented > >> on character, Boolean, Object, SMalltInt symbol, UndefinedObject > > > > Back in the old days, Squeak 1.1 didn't have primitive 148 (which is now > used by both #shallowCopy and #clone). #shallowCopy was the way to create a > "one-level copy" of an Object. It had the same code as today, but with no > primitive. > > Primitive 148 was introduced somewhere between 1.1 and 1.19 (note that > 1.2 came after 1.19). 1.19 (and probably earlier versions, but not 1.1) had > #clone which was primitive only and #shallowCopy which didn't use the > primitive. Morphic was being ported to Squeak at the time and it was the > only user of #clone. Morphs were copied by #clone which was pretty fast, > while other objects used #shallowCopy. Later the use of #clone started to > spread, until primitive 148 was added to #shallowCopy. Sends of #clone were > replaced with #shallowCopy and #copy, but #clone was kept, probably for > backwards compatibility. > > > > #clone and #shallowCopy have a difference in their semantics. If the vm > cannot allocate enough space for the new object, #clone raises an error > immediately, while #shallowCopy signals the low space semaphore, so the > image or the user can do something, then retries the copying. > > > > > > Levente > > > >> > >>> > >>> This is exactly the same problematic as with #=. There can't be just > >>> one #=. Other clients might consider other things when comparing > >>> objects. > >>> > >>> Lukas > >>> > >>> -- > >>> 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 > > _______________________________________________ > > 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 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. > 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. Cheers, Henry

Jan. 13, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Miguel Enrique CobÃ¡ Martinez

> > > > I don't know where is this work. Can you please open a ticket and > label it as 1.0 and puting the link to the thread ? http://code.google.com/p/pharo/issues/detail?id=1808 > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 13, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Schwab,Wilhelm K

That's great news, at least for mac users. What does a penguin herder do to get a plugin? Would it be easier to use a squeak image to build it? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Fernando olivero Sent: Wednesday, January 13, 2010 11:43 AM To: Pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] ConfigurationOfAlien Hi, just added ConfigurationOfAlien to the MetacelloRepository. To load Alien using Metacello configurations evaluate Gofer new url: 'http://www.squeaksource.com/MetacelloRepository' ; package: 'ConfigurationOfAlien'; load. (ConfigurationOfAlien project version:'1.0') load. ( John please update the ALIEN squeaksource page with the previous text ) Note: Using the available MAC VM i the pharo page, you should be able to run the test correctly. ( the alien plugin 'IA32ABI 7 May 2009 (e)', is compiled inside that vm, there's no need for the external one) Metacello question: If i want load Alien Examples, the package Alien-MacOSExamples, but don't want to add them to the above configuration , should i create a new #versionXXX method ? Or provide a class side method like for example ConfigurationOfAlien>>loadWithMaxOsExamples (ConfigurationOfAlien project version:'1.0') load:#('Alien-MacOsExamples') Saludos, Fernando _______________________________________________ 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 Lukas Renggli

>>> WriteBarrier introduces something like immutable objects at the >>> language level by rewriting all state access in an anonymous subclass. >>> Having a compiler at hand certainly makes things simpler. >>> >> Hmm.. what about primitives , which mutating the state of receiver? >> Even worse, there are some, which mutating the state of argument(s). I don't know how WriteBarrier solves that problem (and if it really matters in this case), but it can be: http://scg.unibe.ch/archive/papers/Reng08aTransMemory.pdf Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 13, 2010

Re: [Pharo-project] NewCompiler load on PharoCore

by Gary Chambers

----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, January 13, 2010 4:56 PM Subject: Re: [Pharo-project] NewCompiler load on PharoCore > 2010/1/13 Lukas Renggli <renggli(a)gmail.com>: >>> 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 introduces something like immutable objects at the >> language level by rewriting all state access in an anonymous subclass. >> Having a compiler at hand certainly makes things simpler. >> > Hmm.. what about primitives , which mutating the state of receiver? > Even worse, there are some, which mutating the state of argument(s). Indeed, perhaps the push/pop remappableOop could factor the write barrier in... > >> Lukas >> >> -- >> 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 >> > > > > -- > 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 Lukas Renggli <renggli(a)gmail.com>: >> 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 introduces something like immutable objects at the > language level by rewriting all state access in an anonymous subclass. > Having a compiler at hand certainly makes things simpler. > Hmm.. what about primitives , which mutating the state of receiver? Even worse, there are some, which mutating the state of argument(s). > Lukas > > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 13, 2010