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

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

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

by Danny Chan

Am Dienstag, 2. MÃ¤rz 2010 21:36:07 schrieb StÃ©phane Ducasse: > Hi danny > > I would like to integrate your help system in pharo so we will have see how > we can proceed. I would like to add it in a modular way. Does anybody has > a nice idea? Now I would really like to see how we can produce some help > automatically like by tagging and commenting some cool SUnit tests. > At least we should have it in pharo-dev. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Hi! Do you mean ProfStefBrowser (frontend fo ProfStef) or HelpSystem (initially started by Torsten)? I am not sure what you mean by modular. It has a Metacello configuration. 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. 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. Danny

March 4, 2010

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

by Andreas Raab

On 3/3/2010 3:30 PM, 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. Just to be clear: My option #2 only goes until here. I'd like to make some actual progress in the near term and your proposal is quite a bit of mid- or long-term stuff. > 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 Unfortunately that's all pretty much conjecture or even plain wrong. Cleaner separation of concerns is a claim. It's actually *just* the claim that was made about SmalltalkImage current and see where that has gotten us. So let's try to be careful claiming victory before things have even started. Less vulnerability to refactoring won't be happening this way either - it's no less vulnerable to get a DNU than it is to get an Undeclared. The same goes for the compatibility claim. The *real* gain regarding refactoring and compatibility will be by restoring Smalltalk as the facade that receives those various messages and then passes them on to whatever the actual implementation site is. Basically we need to be promising that we'll support Smalltalk as a facade for all the stuff that SystemDictionary/SmalltalkImage support today, but that we won't promise where it'll be implemented in the backend. This way we have room to experiment with various locations and anyone who needs the compatibility knows there is a safe, idiomatic way of doing all this stuff via Smalltalk. The people who want to experiment can do that and we can see what we like and dislike. In other words, there needs to be a very clearly cut line: If you need compatibility, you use e.g., Smalltalk allClasses, Smalltalk vmParameters, Smalltalk garbageCollect. If you don't, you're free to use Namespace default allClasses or VirtualMachine current parameters or System soleInstance garbageCollect or Smalltalk vm parameters or Smalltalk namespace allClasses. All of these can be delegated trivially to from the Smalltalk facade making it very easy to provide the necessary level of compatibility while leaving room for innovation. Cheers, - Andreas

March 4, 2010