- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.1] #11243

by Jorge Ressia

Yes, the New compiler is not better. However, I think the New Compiler is the right direction to pursue. After fighting with it for some months to make the Closures work in it I can tell you that I learn a great deal from it, painfully :) . But I now have a pretty good idea of what it is required to have a modularized compiler with more suitable abstraction for this particular domain. I implemented many tests and I have to implement a lot more. Then, I believe that by expressing ourselves through these tests we will be able to modify the compiler to make it look the way we want. At least that is my plan with the New compiler. Cheers, Jorge On Thu, Mar 4, 2010 at 9:53 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> I'll try to build the tests and come up with a better solution. >> >> You what I would love to spend 2/3 weeks just coding in the new compiler and making sure >> that it has the right abstractions/messages to deal with issue like that. > > The problem is that the New Compiler is not really in a better state > than the old compiler. Of course it has more objects and is much > easier to extend, but all in all it is a mess too. This is mostly due > to the fact that the system below it changed quite a bit in the past > years (pragmas, properties, closures, primitives, new bytecodes, ...) > and that the New Compiler had to be patched and changed quite heavily > to accommodate these new requirements that it was not designed for. > Maintaining and fixing the New Compiler got so extremely expensive > that it is questionable if this is still a viable platform? Ask Jorge > and Marcus. > > 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 >

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Lukas Renggli

>> I'll try to build the tests and come up with a better solution. > > You what I would love to spend 2/3 weeks just coding in the new compiler and making sure > that it has the right abstractions/messages to deal with issue like that. The problem is that the New Compiler is not really in a better state than the old compiler. Of course it has more objects and is much easier to extend, but all in all it is a mess too. This is mostly due to the fact that the system below it changed quite a bit in the past years (pragmas, properties, closures, primitives, new bytecodes, ...) and that the New Compiler had to be patched and changed quite heavily to accommodate these new requirements that it was not designed for. Maintaining and fixing the New Compiler got so extremely expensive that it is questionable if this is still a viable platform? Ask Jorge and Marcus. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by StÃ©phane Ducasse

On Mar 4, 2010, at 9:37 AM, Jorge Ressia wrote: > Hi Adrian, > > Yep, I have the same problem as you. My idea was to make it work as > before without completely changing it. Basically because I did not > have the test support to validate my changes. > Anyhow, what I propose is to write a bunch of tests for every case > that we know and then if new cases show up add them to the test suite. > And then play with the code. > > I will work on that today, is that ok? excellent. > For the explanation of what is going on is that now node can be an > instance variable node, then the behavior that was there was not > appropriate in the sense that instance variable nodes do not > understand #scope. > However, why this validation "(node isTemp or: [requestor > interactive])" was there in the first place is not that clear to me, > but it's been there since 1999. > > I'll try to build the tests and come up with a better solution. You what I would love to spend 2/3 weeks just coding in the new compiler and making sure that it has the right abstractions/messages to deal with issue like that. I looks to me that the compiler is pre object design time from time to time > > Cheers, > > Jorge > > On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> Jorge, >> >> I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? >> >> This is the code: >> >> "When non-interactive raise the error only if its a duplicate" >> (node isTemp or: [requestor interactive]) >> ifTrue:[ ((node isTemp) and: [node scope <= 0] ) >> ifFalse: [^self notify:'Name is already defined' ]] >> >> Cheers, >> Adrian >> >> On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: >> >>> 11243 >>> ----- >>> >>> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >>> Problem fixed: >>> We cannot have twice the same block arg in a method >>> >>> [:each | each ...] >>> [:each | each ...] >>> >>> THANKS jorge :) >>> Do you like good bio beer? >>> >>> Stef >>> >>> >>> _______________________________________________ >>> 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

March 4, 2010

Re: [Pharo-project] SmalltalkImage current vs Smalltalk : plan B

by Andreas Raab

On 3/4/2010 12:03 AM, StÃ©phane Ducasse wrote: > I like plan B. > at the end I would like to have. Marcus came back from germany and we will discuss. > > Smalltalk -> sole instance of System (aka SmalltalkImage) > > SystemDictionary -> renamed into Namespace > and it accessible via > Smalltalk environment > Smalltalk namespace > > Or Smalltalk is just an holder for a couple of globals > Smalltalk image -> SmalltalkImage current > Smalltalk vm -> SmalltalkVM (not yet done) > Smalltalk namespace -> Namespace instance > > If you want to help we can start going in that direction. > > I decided that I will not rant about the past anymore because I want new and POSITIVE energy. > Now just a bit of knowledge of the past is still good. Indeed. Time for some more context: The only portion of that work that has ever been criticized as overly zealous was the abomination named "SmalltalkImage current". You've done lots of useful things but SmalltalkImage was unmotivated and pointless because contrary to the other changes it never encapsulated any useful domain, was verbose just for the purpose of being verbose and caused more problems than it could ever hope to solve. We'll be all better off without it. The changes done for SpaceTally, ChangeSet, PointerFinder, even SystemNavigation *did* cover useful domains and were consequently never debated. It would be good if you remembered the things that were accepted along with the things that caused discussions because it might help you to restore a more balanced view of the Squeak community. Cheers, - Andreas > For new guys in the community, just imagine that SpaceTally was defined in SystemDictionary. Yes! too > > Similarly > Smalltalk spaceTally > vs > SpaceTally new > > Smalltalk currentChangeset > vs. Changeset current > > Smalltalk pointersTo: C > vs PointerFinder pointersTo: C > > Smalltalk browserAllCallsOn: > vs > Finder/SystemNavigation browserAllCallsOn: > > Take scratch and you will see how it was in 2.8 :) > > So I believe that "Abstraction is a Good Thing" (TM) > > I spent far too many hours arguing in the past. Now we will make it the way we believe it is beautiful and > people that do not like it are not forced to use Pharo. > > Stef > > > On Mar 4, 2010, at 12:30 AM, Nicolas Cellier wrote: > >> For now, plan A has more votes than plan B. >> plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. >> Let SmalltalkImage current ^Smalltalk for crossfork compatibility >> plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = >> SystemDictionary. >> Use messages indirections like: >> Smalltalk vm imagePath >> Smalltalk commandLine optionAt: 2. >> etc... (see previous thread) >> >> At 1st step, they are not much different: >> both unify Smalltalk and SmalltalkImage current API. >> >> Also Plan A is much simpler, thus attractive. But: >> - Plan A is essentially coming back to 3.8 statu quo. >> - Plan B is essentially introducing message indirections >> >> Advantages of plan B I see for the future: >> - cleaner separation of concerns >> - less vulnerable to refactoring (thanks to messages indirection) >> - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) >> easier thru messages >> >> Last, I do not desesperate to sell plan B to other forks. >> See the outline pf plan B below. >> >> So do you still buy plan A ? >> >> Nicolas >> >> >> ------------------------------------------ >> OUTLINE OF PLAN B : >> ------------------------------------------ >> >> PART I - Fusion of the 2 APIs in 1 >> 1) add a globals instance variable to SmalltalkImage >> 2) initialize this instance variable SmalltalkImage current globals: Smalltalk >> 3) implement SystemDictionary methods in use to SmalltalkImage, and >> redirect them through globals >> MessageSentToGlobalFinder testMessagesSentToSmalltalk may help >> 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. >> >> PART II - Refactoring >> 1) add a few messages in SmalltalkImage (vm ^self) >> 2) refactor users of SmalltalkImage current -> Smalltalk vm (or >> Smalltalk commandLine or...) >> This is the compatibility layer which will enable cross fork compatibility >> >> PART III - Provide cross fork compatibility layers: >> simple, Cuis and Pharo and Squeak3.8 and... just have to respond to >> Smalltalk vm (and a few others) >> either ^self or ^SmalltalkImage current or whatever they prefer >> >> PART IV - deeper refactorings >> 1) split SmalltalkImage at will (no precipitation good Rationale SHALL >> be provided). >> 2) introduce other Smalltalk hooks for not so well known classes >> (SystemNavigation / SourceFiles etc...) >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Nicolas Cellier

2010/3/4 Tudor Girba <tudor.girba(a)gmail.com>: > Hi, > > I do not understand the arguments that go in the direction of: because > a block is an object, it should have no spaces inside and it should > not have the code starting on a new line. This is a bit like saying > that a method should not be indented and the code should start on the > same line as the definition. Or in the same line, it is like saying > that because all statements belong to a block, they should all be > written on the same line. > > Visual thinking was mentioned as a defense for these arguments, but > the first role of any visual notation is to make you identify > structure fast. > > The comments of Yanni go in the correct, in my opinion, direction. So, > when you have something like: > > Â Â ifTrue: > Â Â Â Â [self clearCaches. > Â Â Â Â self current soleInstance yada yada blah blah > Â Â Â Â self recomputeAngle] > > you break visual alignment and it is more difficult to see that the > first "self..." is in the same context as the second "self...". Of > course, practice can solve everything and in time you can get used to > this, but that does not make it natural. > > Another visual problem with "[" and "]" is that they are but one > character, and if you place them together with something else, like > "[self", they lose their visual identity (btw, we read words in chunks > not by characters) and get harder to spot. It's true that some fonts > and extra coloring could solve this problem, but whitespace is always > the best and least invasive design weapon. > > Another problem with having no space between the [ and the rest is > that you basically render useless the nice feature of Smalltalk > environments to double click and select everything inside. The reason > is that I have to go to great pain to get the mouse exactly in the > right place. > > > An indentation like below solves the above visual problems. > > boolean ifTrue: [ > Â Â Â Â self clearCaches. > Â Â Â Â self current soleInstance yada yada blah blah > Â Â Â Â self recomputeAngle ] > > The lines are clearly belonging together, [ is clearly observed and > clicking anywhere on the first line after [ will select the whole block. > > Yet another thing it solves is the consistency between block and > method. They both define behavior, and thus Â it would be great if they > would be treated similarly. This is better seen in the context of a > block with parameter: > Strange to see how subjective it is... My brain is well trained to rectangle blocks and I arrive to the opposite conclusions on each point. Nicolas > aCollection do: [ :each | > Â Â Â Â Â Â Â Â self something. > Â Â Â Â Â Â Â Â self somethingElse. ] > > Just like a method has the top line with the signature and the > parameters, a block should be the same. In this case, each is a > parameter and it is clearly distinct from everything else. When there > is no parameter, this is information made very clear, too (because of > the absence of anything following [ ). > > > An argument against this convention was that it looks like C and that > blocks are not dumb {. While I understand the built-in adversity, we > are talking about a visual notation that makes sense for Smalltalk and > not one that make it different from everything else around us. > > Another option would be to have: > boolean ifTrue: > Â Â Â Â [ Â Â Â self clearCaches. > Â Â Â Â Â Â Â Â self current soleInstance yada yada blah blah > Â Â Â Â Â Â Â Â self recomputeAngle ] > > with everything inside the block being aligned. However, this has the > problem of wasting space. One space can also be used, but only when > the font is monospaced, so it would not work in general. Furthermore, > it would be inconsistent or even more space wasting when it comes to > blocks with parameters. > > Cheers, > Doru > > > On 4 Mar 2010, at 03:38, Chris Muller wrote: > >>>> Â Â ifTrue: [ >>>> Â Â Â Â line1 yo. >>>> Â Â Â Â line2 eh ] >>> >>> Horrible, horrible, horrible ;) Â Poor block. Â The block is an >>> object... >> >> Exactly what I was thinking; and how some of the new editor features >> since 3.9, that seem to reify "statements". Â For example, clicking >> inside parens or square-brackets selects that statement(s). Â I also >> really enjoyed the ability to "surround", thereby creating additional >> statement-levels. >> >> The whole interaction becomes much more liked working with tiled code >> rather than a text-editor. >> >>> I think the conclusion has to be (and I can confirm that the >>> VisualWorks >>> team was equally divided) that no one formatting regime will make >>> every one >>> happy and that all regimes will make a substantial minority >>> unhappy. Â So >>> perhaps we should step up to having code formatted automatically >>> according >>> to tailorable preferences. >> >> >> >>> My only concern is comment formatting but the way to deal with that >>> is to >>> use automatic formatting and deal with comment problems as they >>> arise. Â I >>> always used to be concerned about e.g. comments spanning multiple >>> lines. >>> Â But without day to day exposure I don't think one can know how >>> much of an >>> issue it is. >> >> As someone who's logged 5-digits of hours in Squeak these last few >> years, I think the best thing is to just not. Â Let 'em wrap! Â Use >> shout to turn them light gray, so they don't really intrude on the >> code, but are there if you want focus on the extra prose. >> >> Unfortunately, the real problem with comments within BlockNodes is how >> they duplicate themselves within the parse-tree.. ouch! Â I hope that >> is what you and Nicolas were talking about or that you'll have a fix >> for that.. >> >>> One upside will be less effort reformatting when indent levels >>> change. Â Have >>> you noticed that Smalltalk tends to be more difficult to reformat >>> than C >>> syntax languages, I guess because of keywords? Â Not having to worry >>> about >>> this could be great. >> >> Very cool, I hope there'll be enough additional consensus to adopt >> these Beckian formats for Squeaks pretty-print refinement. >> >>> Of course, what format gets written to a source file could still be >>> a source >>> of conflict ;) Â We may all want our syntax to be the Â format of >>> record :) >> >> Absolutely. Â To not, would be the machine dictating to the user. >> Invoking automatic formatting is always the users choice. >> browseWithPrettyPrint allows readers to have it formatted dynamically >> if they wish.. >> >> Cheers.. >> >>> P.S. Â and don't get me started on the trailing period (putrid >>> excressence), >>> or the space between ^ and the return expression (vomitous mass). >> >> _______________________________________________ >> 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 > > "Live like you mean it." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Jorge Ressia

Hi Adrian, Yep, I have the same problem as you. My idea was to make it work as before without completely changing it. Basically because I did not have the test support to validate my changes. Anyhow, what I propose is to write a bunch of tests for every case that we know and then if new cases show up add them to the test suite. And then play with the code. I will work on that today, is that ok? For the explanation of what is going on is that now node can be an instance variable node, then the behavior that was there was not appropriate in the sense that instance variable nodes do not understand #scope. However, why this validation "(node isTemp or: [requestor interactive])" was there in the first place is not that clear to me, but it's been there since 1999. I'll try to build the tests and come up with a better solution. Cheers, Jorge On Thu, Mar 4, 2010 at 9:14 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Jorge, > > I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? > > This is the code: > > "When non-interactive raise the error only if its a duplicate" > (node isTemp or: [requestor interactive]) > Â Â Â Â ifTrue:[ ((node isTemp) and: [node scope <= 0] ) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: [^self notify:'Name is already defined' ]] > > Cheers, > Adrian > > On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: > >> 11243 >> ----- >> >> - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed >> Â Â Â Problem fixed: >> We cannot have twice the same block arg in a method >> >> Â Â Â [:each | each ...] >> Â Â Â [:each | each ...] >> >> THANKS jorge :) >> Do you like good bio beer? >> >> Stef >> >> >> _______________________________________________ >> 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 >

March 4, 2010

Re: [Pharo-project] about code formatting in pharo

by Tudor Girba

Hi, I do not understand the arguments that go in the direction of: because a block is an object, it should have no spaces inside and it should not have the code starting on a new line. This is a bit like saying that a method should not be indented and the code should start on the same line as the definition. Or in the same line, it is like saying that because all statements belong to a block, they should all be written on the same line. Visual thinking was mentioned as a defense for these arguments, but the first role of any visual notation is to make you identify structure fast. The comments of Yanni go in the correct, in my opinion, direction. So, when you have something like: ifTrue: [self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle] you break visual alignment and it is more difficult to see that the first "self..." is in the same context as the second "self...". Of course, practice can solve everything and in time you can get used to this, but that does not make it natural. Another visual problem with "[" and "]" is that they are but one character, and if you place them together with something else, like "[self", they lose their visual identity (btw, we read words in chunks not by characters) and get harder to spot. It's true that some fonts and extra coloring could solve this problem, but whitespace is always the best and least invasive design weapon. Another problem with having no space between the [ and the rest is that you basically render useless the nice feature of Smalltalk environments to double click and select everything inside. The reason is that I have to go to great pain to get the mouse exactly in the right place. An indentation like below solves the above visual problems. boolean ifTrue: [ self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle ] The lines are clearly belonging together, [ is clearly observed and clicking anywhere on the first line after [ will select the whole block. Yet another thing it solves is the consistency between block and method. They both define behavior, and thus it would be great if they would be treated similarly. This is better seen in the context of a block with parameter: aCollection do: [ :each | self something. self somethingElse. ] Just like a method has the top line with the signature and the parameters, a block should be the same. In this case, each is a parameter and it is clearly distinct from everything else. When there is no parameter, this is information made very clear, too (because of the absence of anything following [ ). An argument against this convention was that it looks like C and that blocks are not dumb {. While I understand the built-in adversity, we are talking about a visual notation that makes sense for Smalltalk and not one that make it different from everything else around us. Another option would be to have: boolean ifTrue: [ self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle ] with everything inside the block being aligned. However, this has the problem of wasting space. One space can also be used, but only when the font is monospaced, so it would not work in general. Furthermore, it would be inconsistent or even more space wasting when it comes to blocks with parameters. Cheers, Doru On 4 Mar 2010, at 03:38, Chris Muller wrote: >>> ifTrue: [ >>> line1 yo. >>> line2 eh ] >> >> Horrible, horrible, horrible ;) Poor block. The block is an >> object... > > Exactly what I was thinking; and how some of the new editor features > since 3.9, that seem to reify "statements". For example, clicking > inside parens or square-brackets selects that statement(s). I also > really enjoyed the ability to "surround", thereby creating additional > statement-levels. > > The whole interaction becomes much more liked working with tiled code > rather than a text-editor. > >> I think the conclusion has to be (and I can confirm that the >> VisualWorks >> team was equally divided) that no one formatting regime will make >> every one >> happy and that all regimes will make a substantial minority >> unhappy. So >> perhaps we should step up to having code formatted automatically >> according >> to tailorable preferences. > > > >> My only concern is comment formatting but the way to deal with that >> is to >> use automatic formatting and deal with comment problems as they >> arise. I >> always used to be concerned about e.g. comments spanning multiple >> lines. >> But without day to day exposure I don't think one can know how >> much of an >> issue it is. > > As someone who's logged 5-digits of hours in Squeak these last few > years, I think the best thing is to just not. Let 'em wrap! Use > shout to turn them light gray, so they don't really intrude on the > code, but are there if you want focus on the extra prose. > > Unfortunately, the real problem with comments within BlockNodes is how > they duplicate themselves within the parse-tree.. ouch! I hope that > is what you and Nicolas were talking about or that you'll have a fix > for that.. > >> One upside will be less effort reformatting when indent levels >> change. Have >> you noticed that Smalltalk tends to be more difficult to reformat >> than C >> syntax languages, I guess because of keywords? Not having to worry >> about >> this could be great. > > Very cool, I hope there'll be enough additional consensus to adopt > these Beckian formats for Squeaks pretty-print refinement. > >> Of course, what format gets written to a source file could still be >> a source >> of conflict ;) We may all want our syntax to be the format of >> record :) > > Absolutely. To not, would be the machine dictating to the user. > Invoking automatic formatting is always the users choice. > browseWithPrettyPrint allows readers to have it formatted dynamically > if they wish.. > > Cheers.. > >> P.S. and don't get me started on the trailing period (putrid >> excressence), >> or the space between ^ and the return expression (vomitous mass). > > _______________________________________________ > 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 "Live like you mean it."

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Adrian Lienhard

Jorge, I looked at the code to integrate in 1.0. And I really have troubles understanding it (even after drawing a boolean table for the different combinations of or: ifTrue: and: ifFalse:). Is it correct that the warning is shown when node isTemp is false and requestor interactive is true? Is the comment still accurate? This is the code: "When non-interactive raise the error only if its a duplicate" (node isTemp or: [requestor interactive]) ifTrue:[ ((node isTemp) and: [node scope <= 0] ) ifFalse: [^self notify:'Name is already defined' ]] Cheers, Adrian On Mar 3, 2010, at 20:47 , StÃ©phane Ducasse wrote: > 11243 > ----- > > - Issue 2102: Fix the fact that local temp can shadow silently instance var --- fixed > Problem fixed: > We cannot have twice the same block arg in a method > > [:each | each ...] > [:each | each ...] > > THANKS jorge :) > Do you like good bio beer? > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010

Re: [Pharo-project] SmalltalkImage current vs Smalltalk : plan B

by StÃ©phane Ducasse

I like plan B. at the end I would like to have. Marcus came back from germany and we will discuss. Smalltalk -> sole instance of System (aka SmalltalkImage) SystemDictionary -> renamed into Namespace and it accessible via Smalltalk environment Smalltalk namespace Or Smalltalk is just an holder for a couple of globals Smalltalk image -> SmalltalkImage current Smalltalk vm -> SmalltalkVM (not yet done) Smalltalk namespace -> Namespace instance If you want to help we can start going in that direction. I decided that I will not rant about the past anymore because I want new and POSITIVE energy. Now just a bit of knowledge of the past is still good. For new guys in the community, just imagine that SpaceTally was defined in SystemDictionary. Yes! too Similarly Smalltalk spaceTally vs SpaceTally new Smalltalk currentChangeset vs. Changeset current Smalltalk pointersTo: C vs PointerFinder pointersTo: C Smalltalk browserAllCallsOn: vs Finder/SystemNavigation browserAllCallsOn: Take scratch and you will see how it was in 2.8 :) So I believe that "Abstraction is a Good Thing" (TM) I spent far too many hours arguing in the past. Now we will make it the way we believe it is beautiful and people that do not like it are not forced to use Pharo. Stef On Mar 4, 2010, at 12:30 AM, Nicolas Cellier wrote: > For now, plan A has more votes than plan B. > plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. > Let SmalltalkImage current ^Smalltalk for crossfork compatibility > plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = > SystemDictionary. > Use messages indirections like: > Smalltalk vm imagePath > Smalltalk commandLine optionAt: 2. > etc... (see previous thread) > > At 1st step, they are not much different: > both unify Smalltalk and SmalltalkImage current API. > > Also Plan A is much simpler, thus attractive. But: > - Plan A is essentially coming back to 3.8 statu quo. > - Plan B is essentially introducing message indirections > > Advantages of plan B I see for the future: > - cleaner separation of concerns > - less vulnerable to refactoring (thanks to messages indirection) > - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) > easier thru messages > > Last, I do not desesperate to sell plan B to other forks. > See the outline pf plan B below. > > So do you still buy plan A ? > > Nicolas > > > ------------------------------------------ > OUTLINE OF PLAN B : > ------------------------------------------ > > PART I - Fusion of the 2 APIs in 1 > 1) add a globals instance variable to SmalltalkImage > 2) initialize this instance variable SmalltalkImage current globals: Smalltalk > 3) implement SystemDictionary methods in use to SmalltalkImage, and > redirect them through globals > MessageSentToGlobalFinder testMessagesSentToSmalltalk may help > 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. > > PART II - Refactoring > 1) add a few messages in SmalltalkImage (vm ^self) > 2) refactor users of SmalltalkImage current -> Smalltalk vm (or > Smalltalk commandLine or...) > This is the compatibility layer which will enable cross fork compatibility > > PART III - Provide cross fork compatibility layers: > simple, Cuis and Pharo and Squeak3.8 and... just have to respond to > Smalltalk vm (and a few others) > either ^self or ^SmalltalkImage current or whatever they prefer > > PART IV - deeper refactorings > 1) split SmalltalkImage at will (no precipitation good Rationale SHALL > be provided). > 2) introduce other Smalltalk hooks for not so well known classes > (SystemNavigation / SourceFiles etc...) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010

Re: [Pharo-project] About danny help :)

by StÃ©phane Ducasse

>> > > > Hi! > Do you mean ProfStefBrowser (frontend fo ProfStef) or HelpSystem (initially > started by Torsten)? sorry I meant the HelpSystem I want ProfStefBrowser in Pharo but not the core :) Yes this is good for my ego :))) > I am not sure what you mean by modular. It has a Metacello configuration. my point is if you imagine that we want a small system with good packages where do we put the helpSystem. > With regard to automatic help, in HelpSystem API help on packages and > individual classes can already be generated automatically, and some very basic > support for tagging methods is implemented. Right now it generates a page with > documentation for all methods in a class, with methods tagged with <help> > reordered to appear at the top of the text. Ok excellent I was not aware of that. what about the tag for SUnit tests? > > A nice idea on squeak-dev was to add support for a simple structured markup > language like Markdown in class comments. We could use this to write "big- > picture" documentation directly in a class comment. I think this would > complement the method comments quite nicely. Do you have an example? > > Danny > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010