- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.4] #14445

by Marcus Denker

14445 ----- Issue 5742: BallonMorph shows flyover help using an extra line http://code.google.com/p/pharo/issues/detail?id=5742 Issue 6150: During snapshot: Send cr after Transcript message for 1.4 http://code.google.com/p/pharo/issues/detail?id=6150 Issue 6147: Code completion in all tools for 1.4 http://code.google.com/p/pharo/issues/detail?id=6147 -- Marcus Denker -- http://marcusdenker.de

June 27, 2012

[Pharo-project] [update 2.0] #20163

by Marcus Denker

20163 ----- Issue 5972: Clean in perform: aSelector orSendTo: another http://code.google.com/p/pharo/issues/detail?id=5972 Issue 6175: Spec example has Undeclared reference http://code.google.com/p/pharo/issues/detail?id=6175 Issue 6176: Add Zodiac https support http://code.google.com/p/pharo/issues/detail?id=6176 -- Marcus Denker -- http://marcusdenker.de

June 27, 2012

Re: [Pharo-project] ConfigurationOfMagritte30

by StÃ©phane Ducasse

I published a new version of the metacello paper. I do not know the process to get it publicly I tried all kinds of scp magic invocation but could not make it. so it is Stef

June 27, 2012

Re: [Pharo-project] Sticky morph after progress morph use

by phil＠highoctane.be

I am doing something on "Produits remarquables" It is too ugly to show right now. But I have got the exercises set generated, and all the touch interaction working with morphs and some help screens. Now I am working on making it look nicer and checking the student answers with the right ones. Next in line will be the Trigono Bingo. We can work on that together if you want :-) Phil 2012/6/27 Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> > On 27/06/2012 09:14, phil(a)highoctane.be wrote: > > Hilaire, a question: what do you recommend as VM to run DrGeo on an > android > > system? (I am doing a maths app with my wife. It runs fine on iOS/iPad > but > > I'd like to try it out on android systems). > > I am using the stack version of Dimitry. Therefore, nothing unreachable. > > What Math apps are you doing, I am curious. Screenshot please! > > > > Question: did you had any issues with loading PNGs from external files? I > > have a weird thing there. > > No issue with PNG, I am using both to generate and load DrGeo sketch > preview. > > Hilaire > > -- > Dr. Geo -- http://www.drgeo.eu > > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by phil＠highoctane.be

Yes, finishing things up is the hardest part. It is also the part that makes people and great art remembered. As I wrote yesterday on Twitter: Execution is everything. Ideas are nothing. I should add: and everything gets better with late binding :-p Phil 2012/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jun 27, 2012, at 9:24 AM, phil(a)highoctane.be wrote: > > > Stephane, > > > > Wow, there is a limit to your utter awesomeness... Take care! > > > > On this namespace thing... Well, in fact, I found that nice with Java > but at the end of the day, what matters is the modular bit. And we have > that with packages and MC. We do no need the namespaces really. Prefixing > the classes works and scales. Look at any Obj-C app, there are prefixes > everywhere.... and it works well. > > > > No having this additional level makes Pharo much more approachable for > new people. And in order to get traction, this is important. > > yes this is why we have camille (a master student student that is turning > modules around in presence of class extensions and trying to see what would > be the best solution) > now we should finish what we started. > Finishing is more difficult. > > Stef > > > > > Phil > > > > > > > > 2012/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > James > > > > sorry but I'm at home stopped for 10 days because of a burnout (linked > partly to pharo and the business I want to spawn for the community). > > We talked endlessly about namespaces and so far we lived happily > without. Right now I will not talk about that. Read subsystem the paper of > wirfs-brock > > if you want to see what I would prefer to have. But we need to have a > scientific approach to evaluate. > > And yes I read the implementation two years ago. > > Finally did you see the list of topics that I mention? > > - do you want to help in any of them to make pharo better? > > because we have to get them first and I need all my energy for > them. > > > > Stef > > > > > > On Jun 27, 2012, at 12:25 AM, James Foster wrote: > > > > > On Jun 26, 2012, at 12:51 PM, StÃ©phane Ducasse wrote: > > > > > >> On Jun 26, 2012, at 9:30 PM, James Foster wrote: > > >> > > >>> On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: > > >>> > > >>>>>>> What happened to the project from GermÃ¡n Leiva > > >>>>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A > > >>>>>> > > >>>>>> we do not want class level namespace because this is the mess > > >>>>> > > >>>>> As the sponsor for GermÃ¡n's project, I have some interest in this > topic. StÃ©phane has said a couple times that it is wrong but has never > taken time to explain his objections. > > >>>> > > >>>> We do not want to have class name resolution at the granularity of > a class. > > >>> > > >>> And are you saying this because you think GermÃ¡n's implementation > does this? > > >>> > > >>>> Why because it means that in the same package reading the code > containing a class Foo could be a different one. > > >> > > >>>> Why because it means that in the same package, reading the code > containing a class Foo could be a different one. > > >> > ^^^^^ > > >> > > >> Class level namespace import means that in a given class, a method > accessing the variable Foo may end up pointing to another class Foo in a > class in the same package importing another namespace. > > > > > > I still don't understand the definition. What do you mean by "another > class Foo in a class." How can a class be in a class? Is Foo defined in two > packages? Is the method on the class Foo? Should the name be resolved to > the Foo in the package containing the method or to another Foo? Perhaps it > would help if you named the sample classes, packages, and methods. > > > > > > Are you saying that if the namespace is allowed to be defined (or > refined) at any level other than the package, then it is lumped into the > bucket called "class level namespace import"? > > > > > >>> I don't understand your example. I don't know what you mean by > "package reading the code." Are you describing a package that defines > classes Foo and Bar, and a method in a class Bar that references the Foo in > the same package? Are you providing this example because you think GermÃ¡n's > implementation does not support this use case? > > >> > > >> No > > >> I just say that changing binding of variables at the class level is > not a good granularity. I do not want to have > > >> > > >> Object subclass: #NameOfSubclass > > >> instanceVariableNames: '' > > >> classVariableNames: '' > > >> poolDictionaries: '' > > >> category: 'Bob' > > >>>>> environment: > > > > > > Is it your impression that GermÃ¡n's implementation requires this? If > so, on what do you base that understanding? Have you looked at the code? > > > > > >>>> I'm saying that since years. > > >>> > > >>> I agree you have been saying that GermÃ¡n's implementation isn't what > you want. I just don't understand what you don't like about it. > > >> > > >> because this is a class level import. > > > > > > I still don't know what you mean by "class level import" or why you > think GermÃ¡n's implementation fits your definition. > > > > > >>> Name resolution of all variables (including Globals, of which > Classes are a subset) should be part of a method compile. At the time a > method is compiled, an 'environment' should be provided to the compiler > that indicates how global name resolution should occur. > > >> > > >> Usually this is the class of the method. > > > > > > By "Usually" do you mean in pre-namespace Pharo? That is, the class is > one of the factors that the compiler considers in doing name lookup? Is the > "usual" approach good? Would it still be a factor considered by the > compiler in an environment namespace regime? > > > > > >>> This is a tools issue and it should be possible to specify the > default namespace environment for the method, for a method category, for a > class, for a class category, for a package, and for the system as a whole. > > >> > > >> no this is a question of language design. > > > > > > Do you consider packages to be part of the language? I have always > thought that one of the nice things about Smalltalk is how little of the > development environment is actually part of the language. Being able to > augment things through tools rather than changing the language seems to me > to be a feature, not a bug. > > > > > >>> In addition, within a particular method it should be possible to > explicitly reference a particular namespace environment, whether through > syntax (dot or double colons) > > >> > > >> No we do not want to have that. > > >> We want import to be specified at the border: i.e. during module > import. Inside a module the world is flat and as a developer I do not want > to know that this Point is from Core when that one is from MyCore. > > > > > > By "I do not want to know" do you mean "I do not want to be required > to specify" or do you mean "I do not want anyone else to be able to find > out"? If I want to know (say, to build tools), would that be okay? If I'm > willing to let you remain ignorant of a global's source would you be > willing to let me be enlightened? > > > > > >> If I want both, at the module import level I write > > >> > > >> Import: Point from: core as: CorePoint; > > >> import: Point from: dev as: DevPoint; > > > > > > What object implements #'import:from:as:'? > > > > > >>> or through message sends (e.g., a Dictionary's #'at:' method). I > prefer not to add new syntax and favor GemStone's implementation over that > of VisualWorks. > > >> > > >> I dislike them both. > > >> A module should provide a certain level of encapsulation, else naming > convention is good enough. > > >> Because else having namespace does not prevent you to have to declare > that WA is not a namespace somebody else should use. > > > > > > You say that you "do not want to" allow code "to explicitly reference > a particular namespace." Do you mean that arbitrary code should not be able > to see a global that is not explicitly imported at package load time and > that code should never be able to explicitly look at and manipulate > namespaces. Really? This seems to me to be very much contrary to the > existing spirit of reflection and introspection in Smalltalk and would make > tools much more limited. I suspect that this is not really what you mean. > > > > > > I believe that a package should be allowed to provide a default > environment, but I don't see the need to make it mandatory or exclusive. I > believe that a class should be allowed to override the default environment, > but I don't think it should be required. > > > > > > If a class is allowed (but not required) to override the default > (provided by the package/module, for example), does that make it a "class > level import" (and wrong, in your view)? > > > > > > What I understand from your statements so far is that GermÃ¡n's > approach allows too much flexibility (namespace can be specified not just > at the package level but also at the class level and explicitly in code). > You do not want to allow anyone to experiment with different levels of > granularity. Is that it? > > > > > > Thanks for engaging in the discussion. > > > > > > James Foster > > > > > > > > > > > > > > > > > > -- > > Philippe Back > > Dramatic Performance Improvements > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > > > High Octane SPRL > > rue cour Boisacq 101 > > 1301 Bierges > > Belgium > > > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 27, 2012

Re: [Pharo-project] Sticky morph after progress morph use

by Hilaire Fernandes

On 27/06/2012 09:14, phil(a)highoctane.be wrote: > Hilaire, a question: what do you recommend as VM to run DrGeo on an android > system? (I am doing a maths app with my wife. It runs fine on iOS/iPad but > I'd like to try it out on android systems). I am using the stack version of Dimitry. Therefore, nothing unreachable. What Math apps are you doing, I am curious. Screenshot please! > Question: did you had any issues with loading PNGs from external files? I > have a weird thing there. No issue with PNG, I am using both to generate and load DrGeo sketch preview. Hilaire -- Dr. Geo -- http://www.drgeo.eu

June 27, 2012

Re: [Pharo-project] Sticky morph after progress morph use

by Hilaire Fernandes

On 27/06/2012 09:09, Guillermo Polito wrote: > Anyway, Hilaire, if you want to get rid of that progress bar, you only have > to evaluate: > > SystemProgressMorph reset. > > So maybe adding that line at the end of your script can be a workaround... I did that in my own code (but now I am using another rotating wheels), bu problem occurs in part I don't have access to. For example in the Finder it occurs (after I did my image clean up only) Thanks Hilaire -- Dr. Geo -- http://www.drgeo.eu

June 27, 2012

Re: [Pharo-project] ConfigurationOfMagritte30

by StÃ©phane Ducasse

Ok and I'm happy since I wrote a complete section (section 1.11) on that in the Metacello book chapter and everything is explained. I just totally forgot and was sleepy (too many decontracting pills do not help my mind). so forget the post. Now I found some bugs in the chapter before that section and will fix them. Stef On Jun 27, 2012, at 9:24 AM, StÃ©phane Ducasse wrote: > Of course I meant > > >> stable: spec >> <symbolicVersion: #stable> >> >> spec for: #'1.3.x' version: '3.0'. >> spec for: #'1.3.x' version: '3.0'. > > > > Now dale what is the meaning of common when we have? > Does metacello know automatically that it should load common + pharo? > > > baseline300: spec > <version: '3.0-baseline'> > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec author: 'NickAger'. > spec timestamp: '01/30/2011 11:02:07'. > spec repository: 'http://source.lukas-renggli.ch/magritte3'. > spec > project: 'Grease' with: [ > spec > className: 'ConfigurationOfGrease'; > versionString: #'stable'; > loads: #('Core' ); > repository: 'http://www.squeaksource.com/MetacelloRepository' ]; > project: 'Seaside30' with: [ > spec > className: 'ConfigurationOfSeaside30'; > versionString: #'stable'; > loads: #('Core'); > repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > spec > package: 'Magritte-Model' with: [ > spec requires: #('Grease' ) ]; > package: 'Magritte-Tests-Model' with: [ > spec requires: #('Magritte-Model' ) ]; > package: 'Magritte-Seaside' with: [ > spec requires: #('Magritte-Model' 'Seaside30' ) ]; > package: 'Magritte-Deprecated' with: [ > spec requires: #('Magritte-Model') ]. > spec > group: 'default' with: #('Core' ); > group: 'Core' with: #('Magritte-Model' ); > group: 'Tests' with: #('Magritte-Tests-Model' ); > group: 'Seaside' with: #('Magritte-Seaside'); > group: 'Deprecated' with: #('Magritte-Deprecated') ]. > > spec for: #'pharo' do: [ > spec > package: 'Magritte-Model' with: [ > spec includes: #('Magritte-Pharo-Model' ). ]; > package: 'Magritte-Tests-Model' with: [ > spec includes: #('Magritte-Tests-Pharo-Model' ). ]; > package: 'Magritte-Seaside' with: [ > spec includes: #('Magritte-Pharo-Seaside' ). ]; > package: 'Magritte-Pharo-Model' with: [ > spec requires: #('Magritte-Model' ). ]; > package: 'Magritte-Tests-Pharo-Model' with: [ > spec requires: #('Magritte-Pharo-Model' ). ]; > package: 'Magritte-Pharo-Seaside' with: [ > spec requires: #('Magritte-Seaside' ). ]; > package: 'Magritte-Morph' with: [ > spec requires: #('Magritte-Model' ). ]; > package: 'Magritte-Pharo-Tools' with: [ > spec requires: #('Magritte-Deprecated' ). ]. > spec > group: 'Tools' with: #('Magritte-Pharo-Tools') ]. > > spec for: #gemstone do: [ > spec project: 'GsCore' with: [ > spec > className: 'ConfigurationOfGsCore'; > versionString: #'bleedingEdge'; > repository: 'http://seaside.gemstone.com/ss/MetacelloRepository' ]. > spec > package: 'Magritte-Model' with: [ > spec > requires: #('GsCore' ); > includes: #('Magritte-GemStone-Model' ). ]; > package: 'Magritte-Tests-Model' with: [ > spec includes: #('Magritte-Tests-GemStone-Model' ). ]; > package: 'Magritte-Seaside' with: [ > spec includes: #('Magritte-GemStone-Seaside' ). ]; > package: 'Magritte-GemStone-Model' with: [ > spec requires: #('Magritte-Model' ). ]; > package: 'Magritte-Tests-GemStone-Model' with: [ > spec requires: #('Magritte-GemStone-Model' ). ]; > package: 'Magritte-GemStone-Seaside' with: [ > spec requires: #('Magritte-Seaside' ) ] ] > > >> Hi guys >> >> I'm checking magritte 30 to write a updated chapter for the seaside book on magritte and the configurationOfMagritte30 seems wrong to me >> the stable declaration is >> >> stable: spec >> <symbolicVersion: #stable> >> >> spec for: #'common' version: '3.0'. >> >> >> while it should be more >> >> stable: spec >> <symbolicVersion: #stable> >> >> spec for: #'common' version: '1.3.x'. >> spec for: #'common' version: '1.4.x'. >> >> Do you know if magritte30 works on pharo 1.3? and 1.4? >> >> >> I will also change MagicMagritte (I do not know if I have write access to it). >> because stable is >> >> stable: spec >> <symbolicVersion: #stable> >> >> spec for: #'common' version: '1.0' >> >> but I bet that nick (which is on holiday) works with pharo10. I guessed he misunderstood the stable meaning. >> Stef >> >> > >

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by StÃ©phane Ducasse

On Jun 27, 2012, at 9:24 AM, phil(a)highoctane.be wrote: > Stephane, > > Wow, there is a limit to your utter awesomeness... Take care! > > On this namespace thing... Well, in fact, I found that nice with Java but at the end of the day, what matters is the modular bit. And we have that with packages and MC. We do no need the namespaces really. Prefixing the classes works and scales. Look at any Obj-C app, there are prefixes everywhere.... and it works well. > > No having this additional level makes Pharo much more approachable for new people. And in order to get traction, this is important. yes this is why we have camille (a master student student that is turning modules around in presence of class extensions and trying to see what would be the best solution) now we should finish what we started. Finishing is more difficult. Stef > > Phil > > > > 2012/6/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > James > > sorry but I'm at home stopped for 10 days because of a burnout (linked partly to pharo and the business I want to spawn for the community). > We talked endlessly about namespaces and so far we lived happily without. Right now I will not talk about that. Read subsystem the paper of wirfs-brock > if you want to see what I would prefer to have. But we need to have a scientific approach to evaluate. > And yes I read the implementation two years ago. > Finally did you see the list of topics that I mention? > - do you want to help in any of them to make pharo better? > because we have to get them first and I need all my energy for them. > > Stef > > > On Jun 27, 2012, at 12:25 AM, James Foster wrote: > > > On Jun 26, 2012, at 12:51 PM, StÃ©phane Ducasse wrote: > > > >> On Jun 26, 2012, at 9:30 PM, James Foster wrote: > >> > >>> On Jun 26, 2012, at 11:19 AM, StÃ©phane Ducasse wrote: > >>> > >>>>>>> What happened to the project from GermÃ¡n Leiva > >>>>>>> http://www.youtube.com/watch?v=n4I7fSVNX2A > >>>>>> > >>>>>> we do not want class level namespace because this is the mess > >>>>> > >>>>> As the sponsor for GermÃ¡n's project, I have some interest in this topic. StÃ©phane has said a couple times that it is wrong but has never taken time to explain his objections. > >>>> > >>>> We do not want to have class name resolution at the granularity of a class. > >>> > >>> And are you saying this because you think GermÃ¡n's implementation does this? > >>> > >>>> Why because it means that in the same package reading the code containing a class Foo could be a different one. > >> > >>>> Why because it means that in the same package, reading the code containing a class Foo could be a different one. > >> ^^^^^ > >> > >> Class level namespace import means that in a given class, a method accessing the variable Foo may end up pointing to another class Foo in a class in the same package importing another namespace. > > > > I still don't understand the definition. What do you mean by "another class Foo in a class." How can a class be in a class? Is Foo defined in two packages? Is the method on the class Foo? Should the name be resolved to the Foo in the package containing the method or to another Foo? Perhaps it would help if you named the sample classes, packages, and methods. > > > > Are you saying that if the namespace is allowed to be defined (or refined) at any level other than the package, then it is lumped into the bucket called "class level namespace import"? > > > >>> I don't understand your example. I don't know what you mean by "package reading the code." Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think GermÃ¡n's implementation does not support this use case? > >> > >> No > >> I just say that changing binding of variables at the class level is not a good granularity. I do not want to have > >> > >> Object subclass: #NameOfSubclass > >> instanceVariableNames: '' > >> classVariableNames: '' > >> poolDictionaries: '' > >> category: 'Bob' > >>>>> environment: > > > > Is it your impression that GermÃ¡n's implementation requires this? If so, on what do you base that understanding? Have you looked at the code? > > > >>>> I'm saying that since years. > >>> > >>> I agree you have been saying that GermÃ¡n's implementation isn't what you want. I just don't understand what you don't like about it. > >> > >> because this is a class level import. > > > > I still don't know what you mean by "class level import" or why you think GermÃ¡n's implementation fits your definition. > > > >>> Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. > >> > >> Usually this is the class of the method. > > > > By "Usually" do you mean in pre-namespace Pharo? That is, the class is one of the factors that the compiler considers in doing name lookup? Is the "usual" approach good? Would it still be a factor considered by the compiler in an environment namespace regime? > > > >>> This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. > >> > >> no this is a question of language design. > > > > Do you consider packages to be part of the language? I have always thought that one of the nice things about Smalltalk is how little of the development environment is actually part of the language. Being able to augment things through tools rather than changing the language seems to me to be a feature, not a bug. > > > >>> In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) > >> > >> No we do not want to have that. > >> We want import to be specified at the border: i.e. during module import. Inside a module the world is flat and as a developer I do not want to know that this Point is from Core when that one is from MyCore. > > > > By "I do not want to know" do you mean "I do not want to be required to specify" or do you mean "I do not want anyone else to be able to find out"? If I want to know (say, to build tools), would that be okay? If I'm willing to let you remain ignorant of a global's source would you be willing to let me be enlightened? > > > >> If I want both, at the module import level I write > >> > >> Import: Point from: core as: CorePoint; > >> import: Point from: dev as: DevPoint; > > > > What object implements #'import:from:as:'? > > > >>> or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. > >> > >> I dislike them both. > >> A module should provide a certain level of encapsulation, else naming convention is good enough. > >> Because else having namespace does not prevent you to have to declare that WA is not a namespace somebody else should use. > > > > You say that you "do not want to" allow code "to explicitly reference a particular namespace." Do you mean that arbitrary code should not be able to see a global that is not explicitly imported at package load time and that code should never be able to explicitly look at and manipulate namespaces. Really? This seems to me to be very much contrary to the existing spirit of reflection and introspection in Smalltalk and would make tools much more limited. I suspect that this is not really what you mean. > > > > I believe that a package should be allowed to provide a default environment, but I don't see the need to make it mandatory or exclusive. I believe that a class should be allowed to override the default environment, but I don't think it should be required. > > > > If a class is allowed (but not required) to override the default (provided by the package/module, for example), does that make it a "class level import" (and wrong, in your view)? > > > > What I understand from your statements so far is that GermÃ¡n's approach allows too much flexibility (namespace can be specified not just at the package level but also at the class level and explicitly in code). You do not want to allow anyone to experiment with different levels of granularity. Is that it? > > > > Thanks for engaging in the discussion. > > > > James Foster > > > > > > > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium

June 27, 2012

Re: [Pharo-project] ConfigurationOfMagritte30

by StÃ©phane Ducasse

Of course I meant > stable: spec > <symbolicVersion: #stable> > > spec for: #'1.3.x' version: '3.0'. > spec for: #'1.3.x' version: '3.0'. Now dale what is the meaning of common when we have? Does metacello know automatically that it should load common + pharo? baseline300: spec <version: '3.0-baseline'> spec for: #'common' do: [ spec blessing: #'baseline'. spec author: 'NickAger'. spec timestamp: '01/30/2011 11:02:07'. spec repository: 'http://source.lukas-renggli.ch/magritte3'. spec project: 'Grease' with: [ spec className: 'ConfigurationOfGrease'; versionString: #'stable'; loads: #('Core' ); repository: 'http://www.squeaksource.com/MetacelloRepository' ]; project: 'Seaside30' with: [ spec className: 'ConfigurationOfSeaside30'; versionString: #'stable'; loads: #('Core'); repository: 'http://www.squeaksource.com/MetacelloRepository' ]. spec package: 'Magritte-Model' with: [ spec requires: #('Grease' ) ]; package: 'Magritte-Tests-Model' with: [ spec requires: #('Magritte-Model' ) ]; package: 'Magritte-Seaside' with: [ spec requires: #('Magritte-Model' 'Seaside30' ) ]; package: 'Magritte-Deprecated' with: [ spec requires: #('Magritte-Model') ]. spec group: 'default' with: #('Core' ); group: 'Core' with: #('Magritte-Model' ); group: 'Tests' with: #('Magritte-Tests-Model' ); group: 'Seaside' with: #('Magritte-Seaside'); group: 'Deprecated' with: #('Magritte-Deprecated') ]. spec for: #'pharo' do: [ spec package: 'Magritte-Model' with: [ spec includes: #('Magritte-Pharo-Model' ). ]; package: 'Magritte-Tests-Model' with: [ spec includes: #('Magritte-Tests-Pharo-Model' ). ]; package: 'Magritte-Seaside' with: [ spec includes: #('Magritte-Pharo-Seaside' ). ]; package: 'Magritte-Pharo-Model' with: [ spec requires: #('Magritte-Model' ). ]; package: 'Magritte-Tests-Pharo-Model' with: [ spec requires: #('Magritte-Pharo-Model' ). ]; package: 'Magritte-Pharo-Seaside' with: [ spec requires: #('Magritte-Seaside' ). ]; package: 'Magritte-Morph' with: [ spec requires: #('Magritte-Model' ). ]; package: 'Magritte-Pharo-Tools' with: [ spec requires: #('Magritte-Deprecated' ). ]. spec group: 'Tools' with: #('Magritte-Pharo-Tools') ]. spec for: #gemstone do: [ spec project: 'GsCore' with: [ spec className: 'ConfigurationOfGsCore'; versionString: #'bleedingEdge'; repository: 'http://seaside.gemstone.com/ss/MetacelloRepository' ]. spec package: 'Magritte-Model' with: [ spec requires: #('GsCore' ); includes: #('Magritte-GemStone-Model' ). ]; package: 'Magritte-Tests-Model' with: [ spec includes: #('Magritte-Tests-GemStone-Model' ). ]; package: 'Magritte-Seaside' with: [ spec includes: #('Magritte-GemStone-Seaside' ). ]; package: 'Magritte-GemStone-Model' with: [ spec requires: #('Magritte-Model' ). ]; package: 'Magritte-Tests-GemStone-Model' with: [ spec requires: #('Magritte-GemStone-Model' ). ]; package: 'Magritte-GemStone-Seaside' with: [ spec requires: #('Magritte-Seaside' ) ] ] > Hi guys > > I'm checking magritte 30 to write a updated chapter for the seaside book on magritte and the configurationOfMagritte30 seems wrong to me > the stable declaration is > > stable: spec > <symbolicVersion: #stable> > > spec for: #'common' version: '3.0'. > > > while it should be more > > stable: spec > <symbolicVersion: #stable> > > spec for: #'common' version: '1.3.x'. > spec for: #'common' version: '1.4.x'. > > Do you know if magritte30 works on pharo 1.3? and 1.4? > > > I will also change MagicMagritte (I do not know if I have write access to it). > because stable is > > stable: spec > <symbolicVersion: #stable> > > spec for: #'common' version: '1.0' > > but I bet that nick (which is on holiday) works with pharo10. I guessed he misunderstood the stable meaning. > Stef > >

June 27, 2012