- Pharo-users - lists.pharo.org

Re: [Pharo-users] Object>>#name deprecated in Pharo 6 -- what do I need to do?

by Norbert Hartl

> Am 11.09.2017 um 19:05 schrieb H. Hirzel <hannes.hirzel(a)gmail.com>: > > Hello all > > Thank you for the helpful answers. > > What I updated was > > PPCMNode>>#name > "protocol: accessing" > name > "hackity hack, this should not be used except for tests..." > ^ self printString > > > This is the root object of the document model [1] generated by the > PetitMarkDown parser, > a common markdown parser by Jan Kurs [2]. > > Now 488 out of 479 tests pass. > I would call that superb quality ð Norbert > Regards > Hannes > > > > > > [1] > > PPCMNode is the base class of the document node hierarchy of a > document described by markdown > > ProtoObject #() > Object #() > PPCMNode #() > PPCMDelegateNode #(#children) > PPCMBlockQuote #(#code #infoString) > PPCMContainer #() > PPCMDocument #() > PPCMEmphasize #() > PPCMFencedCode #(#infoString) > PPCMHeader #(#level #title) > PPCMHtmlBlock #() > PPCMIndentedCode #() > PPCMLine #() > PPCMList #(#type #start) > PPCMListItem #() > PPCMParagraph #() > PPCMStrong #() > PPCMHardBreak #() > PPCMHrule #(#rule) > PPCMHtml #(#text) > PPCMInlinedCode #(#code) > PPCMLink #(#label #destination #title) > PPCMLinkRef #(#label) > PPCMLinkRefDef #(#label #destination #title) > PPCMLinkRefDefPlaceholder #() > PPCMPlainLine #(#text) > PPCMPlainText #(#text) > PPCMSoftBreak #() > PPCMText #(#text) > > > > > [2] > Name: PetitMarkdown-JanKurs.7 > Author: JanKurs > Time: 24 August 2016, 12:25:40.146088 pm > UUID: a2256c36-fc35-48ad-936d-9fd7567488e1 > > http://smalltalkhub.com/mc/JanKurs/PetitParser/main > > >> On 8/26/17, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> Hannes >> >> >> >> You are certainly not required to eliminate #name altogether; all you have >> to do is to ensure that any object that receives the message #name knows how >> to answer its own name in an appropriate way. To rephrase Benâs second para >> in a more long-winded way: >> >> >> >> a. Run the code that generates the deprecation warning. >> b. In the warning pop-up, click on âDebugâ. >> c. Examine the debug stack in the top pane. It is probable that the first >> two lines will read: >> >> HannesClass(Object) deprecated:on:in >> >> HannesClass(Object) name >> >> where HannesClass is the name of some class in your domain >> model. >> >> d. You now know that some code you have written is sending the message #name >> to an instance of HannesClass, but the class does not have such a method. >> The solution is to decide how an instance of that class should answer its >> name, and implement that as a method on the instance side of that class. If >> nothing else is obvious, the usual default is ^self printString. >> e. If the top line of the debug stack does not refer to a class in your >> model, work your way down the stack until you find a class that is yours. >> >> >> >> Hope this helps >> >> >> >> Peter Kenny >> >> >> >> >> >> >> >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of >> Ben Coman >> Sent: 26 August 2017 13:08 >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> Subject: Re: [Pharo-users] Object>>#name deprecated in Pharo 6 -- what do I >> need to do? >> >> >> >> Just checking my presumption... is PPCMNode>>#gtTreeViewIn: >> >> you own application method? So where it sends #name, instead send >> #printString (or #asString). >> >> >> >> Alternatively, #name is being sent to some domain object that doesn't >> implement #name, so it falls back to the super one from Object. So >> implement YourDomainObject>>#name: so the one from Object is not executed. >> >> >> >> cheers -ben >> >> >> >> >> >> On Sat, Aug 26, 2017 at 4:38 PM, H. Hirzel <hannes.hirzel(a)gmail.com >> <mailto:hannes.hirzel@gmail.com> > wrote: >> >> OK, so #name should not be used at all [1] >> >> The error message I get is >> >> PPCommonMarkSpecTest class>>DoIt (blockVisitor is Undeclared) >> The method Object>>#name called from PPCMNode>>#gtTreeViewIn: has been >> deprecated. >> Implement your own domain representation of an object, or use >> #asString or #printString instead. >> >> >> I wonder how I can fix this without going to much into details. >> >> --Hannes >> >> >> ------------------------------------------------------------------------------------------------------------------------ >> [1] Pharo 6.1 source code: >> >> Object>>name >> "Answer a name for the receiver. This is used generically in the >> title of certain inspectors, such as the referred-to inspector, and >> specificially by various subsystems. By default, we let the object >> just print itself out.. " >> >> self >> deprecated: 'Implement your own domain representation of an >> object, >> or use #asString or #printString instead.' >> on: '27 May 2016' >> in: #Pharo6. >> ^ self printString >> >> >> On 8/25/17, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > >> wrote: >>> I don't have an Image to check, but I believe Object>>name >>> just does "^self printString", >>> so by default, in your application send #printString instead of #name. >>> >>> cheers -ben >>> >>> P.S. Perhaps this would be a good candidate for automated rewrite? >>> >>> >>> On Thu, Aug 24, 2017 at 8:49 PM, H. Hirzel <hannes.hirzel(a)gmail.com >>> <mailto:hannes.hirzel@gmail.com> > wrote: >>> >>>> Hello >>>> >>>> In the last days there was a discussion that >>>> >>>> Object>>#name >>>> >>>> >>>> should no longer be used. I did not follow the discussion in detail. >>>> What was decided how #name should be replaced? >>>> >>>> What do I need to do if I get a deprecation warning [1]? >>>> >>>> >>>> Thanks for the answer in advance >>>> >>>> Hannes >>>> >>>> >>>> >>>> >>>> [1] >>>> The method Object>>#name called from PPCMNode>>#gtTreeViewIn: has been >>>> deprecated. >>>> Implement your own domain representation of an object, or use >>>> #asString or #printString instead. >>>> >>>> Select Proceed to continue, or close this window to cancel the >>>> operation. >>>> >>>> >>> >> >> >> >>

Sept. 11, 2017

Re: [Pharo-users] New chapter for coming book: Messages

by Stephane Ducasse

tx for the feedback! On Mon, Sep 11, 2017 at 1:18 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > Hello Stephane > > I like the emphasis of the chapter that implementing same selector > several times at the proper place in a couple of classes is more > important than to rely on inheritance. > > In particular the conclusion > > <citation> > What is important to realise is that classes are cheap. It is better > to write 5 little classes than a huge one. Some (even smart) people > got confused by measuring complexity of a system using number of > classes. Having many classes representing good abstractions with a > single responsibility is much much better than having a single class > exhibiting multiple responsibilities. > </citation> > > Suggestion: put it into a 'Note' box. > > > > > > And replace > > 'got confused' > > with: > > 'get confused' > > > > > > > > Replace: > > Now the choices can be made over multiple tenth of classes. > > 'multiple tenth' is an uncommon expression > > Suggestion: > Now the choices can be made over dozens of classes. > > > > > > > However > 'Sending a message is making a choice!' > takes the view point of the mechanism which does the late binding. > > If I write > > aNode emitHTML: aStream > > I do not make the choice. There are different types of nodes and they > all do the same in the sense that they produce HTML code. > > In any case to drive the point home more examples are needed. > > The Boolean example is the minimal example and as such is interesting. > But it is a borderline case which just illustrates that Smalltalk goes > a long way to implement the object and message pattern consistently. > > The Pillar example is fine but too terse. > For people who already understand the issue just a reference is fine. > But for people new to the concept of replacing a case statement with a > class hierarchy it is too short. > > Elaborate! > > > E.g. have a diagram for a subset of the hierarchy > > PRObject #(''properties'') > PRDocumentItem #(''counter'') > PRDocumentGroup #(''children'') > PRDocument #() > PRHeader #(''level'') > PRList #() > PROrderedList #() > PRUnorderedList #() > PRParagraph #() > PRReference #(''reference'' ''parameters'') > PRFigure #() > PRSlide #(''title'' ''label'') > PRText #(''text'')' > > And show all the emitHTML: messages. > > > And go for a third example, e.g. from Morphic or Bloc > > > position: > extent: > color: > owner: > submorphs: > drawOn: aCanvas > > > Meaning of last sentence is not clear. > > <citation> > Remember that when we execute a method (and also write it), one key > information we get is that the receiver from this class or one of its > subclasses as we will later. > <citation> > > > Regards > > Hannes > > On 9/11/17, Ricardo Pacheco <ricardo.pacheco.roldan(a)gmail.com> wrote: >> Looks Great, congratulations!! I just read it and has a couple of mistakes >> in the first figures. The return value of the false (2.3, 2.4). >> >> Regards >> Ricardo >> >> El sept. 11, 2017 12:12 AM, "Stephane Ducasse" <stepharo.self(a)gmail.com> >> escribiÃ³: >> >> Hi >> >> after this crazy esug I took a long bus and I wrote one missing >> chapter for the forhtcoming bus. >> I plan to have a first full version for 1 of October :) >> >> I reorganised and massively clean the book contents. >> >> Comments are welcome in any form. >> >> Stef >> >> https://github.com/SquareBracketAssociates/LearningOOPWithPharo >> >

Sept. 11, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by Stephane Ducasse

Stefan (Did you publish the configuration in the PlotMorph repo?) ifTrue: [ Stefan isPerfect ] On Mon, Sep 11, 2017 at 7:19 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks Stefan > > > On Mon, Sep 11, 2017 at 2:00 PM, stephan <stephan(a)stack.nl> wrote: >> Oops >> >> On 11-09-17 12:11, stephan wrote: >>> >>> Yep, there is the missing information. >>> So let's fix the version10. We can do it in place, as this can not have >>> worked. Otherwise we would have had to add a new version, and updated the >>> #stable. >> >> >> version10: spec >> <version: '1.0' imports: #('1.0-baseline' )> >> >> spec >> for: #pharo do: [ >> spec blessing: #release. >> spec package: 'PlotMorph' with: >> 'PlotMorph-StephaneDucasse.7'] >> >> >> >>

Sept. 11, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by Stephane Ducasse

Thanks Stefan On Mon, Sep 11, 2017 at 2:00 PM, stephan <stephan(a)stack.nl> wrote: > Oops > > On 11-09-17 12:11, stephan wrote: >> >> Yep, there is the missing information. >> So let's fix the version10. We can do it in place, as this can not have >> worked. Otherwise we would have had to add a new version, and updated the >> #stable. > > > version10: spec > <version: '1.0' imports: #('1.0-baseline' )> > > spec > for: #pharo do: [ > spec blessing: #release. > spec package: 'PlotMorph' with: > 'PlotMorph-StephaneDucasse.7'] > > > >

Sept. 11, 2017

Re: [Pharo-users] Object>>#name deprecated in Pharo 6 -- what do I need to do?

by H. Hirzel

Hello all Thank you for the helpful answers. What I updated was PPCMNode>>#name "protocol: accessing" name "hackity hack, this should not be used except for tests..." ^ self printString This is the root object of the document model [1] generated by the PetitMarkDown parser, a common markdown parser by Jan Kurs [2]. Now 488 out of 479 tests pass. Regards Hannes [1] PPCMNode is the base class of the document node hierarchy of a document described by markdown ProtoObject #() Object #() PPCMNode #() PPCMDelegateNode #(#children) PPCMBlockQuote #(#code #infoString) PPCMContainer #() PPCMDocument #() PPCMEmphasize #() PPCMFencedCode #(#infoString) PPCMHeader #(#level #title) PPCMHtmlBlock #() PPCMIndentedCode #() PPCMLine #() PPCMList #(#type #start) PPCMListItem #() PPCMParagraph #() PPCMStrong #() PPCMHardBreak #() PPCMHrule #(#rule) PPCMHtml #(#text) PPCMInlinedCode #(#code) PPCMLink #(#label #destination #title) PPCMLinkRef #(#label) PPCMLinkRefDef #(#label #destination #title) PPCMLinkRefDefPlaceholder #() PPCMPlainLine #(#text) PPCMPlainText #(#text) PPCMSoftBreak #() PPCMText #(#text) [2] Name: PetitMarkdown-JanKurs.7 Author: JanKurs Time: 24 August 2016, 12:25:40.146088 pm UUID: a2256c36-fc35-48ad-936d-9fd7567488e1 http://smalltalkhub.com/mc/JanKurs/PetitParser/main On 8/26/17, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Hannes > > > > You are certainly not required to eliminate #name altogether; all you have > to do is to ensure that any object that receives the message #name knows how > to answer its own name in an appropriate way. To rephrase Benâs second para > in a more long-winded way: > > > > a. Run the code that generates the deprecation warning. > b. In the warning pop-up, click on âDebugâ. > c. Examine the debug stack in the top pane. It is probable that the first > two lines will read: > > HannesClass(Object) deprecated:on:in > > HannesClass(Object) name > > where HannesClass is the name of some class in your domain > model. > > d. You now know that some code you have written is sending the message #name > to an instance of HannesClass, but the class does not have such a method. > The solution is to decide how an instance of that class should answer its > name, and implement that as a method on the instance side of that class. If > nothing else is obvious, the usual default is ^self printString. > e. If the top line of the debug stack does not refer to a class in your > model, work your way down the stack until you find a class that is yours. > > > > Hope this helps > > > > Peter Kenny > > > > > > > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of > Ben Coman > Sent: 26 August 2017 13:08 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] Object>>#name deprecated in Pharo 6 -- what do I > need to do? > > > > Just checking my presumption... is PPCMNode>>#gtTreeViewIn: > > you own application method? So where it sends #name, instead send > #printString (or #asString). > > > > Alternatively, #name is being sent to some domain object that doesn't > implement #name, so it falls back to the super one from Object. So > implement YourDomainObject>>#name: so the one from Object is not executed. > > > > cheers -ben > > > > > > On Sat, Aug 26, 2017 at 4:38 PM, H. Hirzel <hannes.hirzel(a)gmail.com > <mailto:hannes.hirzel@gmail.com> > wrote: > > OK, so #name should not be used at all [1] > > The error message I get is > > PPCommonMarkSpecTest class>>DoIt (blockVisitor is Undeclared) > The method Object>>#name called from PPCMNode>>#gtTreeViewIn: has been > deprecated. > Implement your own domain representation of an object, or use > #asString or #printString instead. > > > I wonder how I can fix this without going to much into details. > > --Hannes > > > ------------------------------------------------------------------------------------------------------------------------ > [1] Pharo 6.1 source code: > > Object>>name > "Answer a name for the receiver. This is used generically in the > title of certain inspectors, such as the referred-to inspector, and > specificially by various subsystems. By default, we let the object > just print itself out.. " > > self > deprecated: 'Implement your own domain representation of an > object, > or use #asString or #printString instead.' > on: '27 May 2016' > in: #Pharo6. > ^ self printString > > > On 8/25/17, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > > wrote: >> I don't have an Image to check, but I believe Object>>name >> just does "^self printString", >> so by default, in your application send #printString instead of #name. >> >> cheers -ben >> >> P.S. Perhaps this would be a good candidate for automated rewrite? >> >> >> On Thu, Aug 24, 2017 at 8:49 PM, H. Hirzel <hannes.hirzel(a)gmail.com >> <mailto:hannes.hirzel@gmail.com> > wrote: >> >>> Hello >>> >>> In the last days there was a discussion that >>> >>> Object>>#name >>> >>> >>> should no longer be used. I did not follow the discussion in detail. >>> What was decided how #name should be replaced? >>> >>> What do I need to do if I get a deprecation warning [1]? >>> >>> >>> Thanks for the answer in advance >>> >>> Hannes >>> >>> >>> >>> >>> [1] >>> The method Object>>#name called from PPCMNode>>#gtTreeViewIn: has been >>> deprecated. >>> Implement your own domain representation of an object, or use >>> #asString or #printString instead. >>> >>> Select Proceed to continue, or close this window to cancel the >>> operation. >>> >>> >> > > > >

Sept. 11, 2017

Re: [Pharo-users] Standalone HTML Model

by H. Hirzel

Interestingly the Seaside team has realized this as well https://github.com/SeasideSt/Seaside/issues/976 .... On 9/11/17, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Pierce Ng > > How different is the API from Seaside? > Because I would like to use it. > I like to think modularly :) > > Stef > > On Mon, Sep 11, 2017 at 12:31 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: >> On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote: >>> I'd like to create HTML via a DSL, like Seaside's canvas builder, but >>> without >>> loading a whole web framework. Any ideas? >> >> I wrote this but subsequently decided that loading the whole of Seaside >> into my >> image just for this functionality is ok and stopped. >> >> http://smalltalkhub.com/#!/~PierceNg/WaterMint-HTML >> >> Pierce >> >> > >

Sept. 11, 2017

Re: [Pharo-users] Standalone HTML Model

by Stephane Ducasse

Hi Pierce Ng How different is the API from Seaside? Because I would like to use it. I like to think modularly :) Stef On Mon, Sep 11, 2017 at 12:31 PM, Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Fri, Sep 08, 2017 at 03:15:56PM -0700, Sean P. DeNigris wrote: >> I'd like to create HTML via a DSL, like Seaside's canvas builder, but without >> loading a whole web framework. Any ideas? > > I wrote this but subsequently decided that loading the whole of Seaside into my > image just for this functionality is ok and stopped. > > http://smalltalkhub.com/#!/~PierceNg/WaterMint-HTML > > Pierce > >

Sept. 11, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by st＠bestley.co.uk

stephan <stephan(a)stack.nl> wrote: > On 10-09-17 23:04, Mark Bestley wrote: > > I downloaded 64bit Pharo from > > <http://files.pharo.org/platform/Pharo6.1-64-mac.zip> > > > > Started it and first thing opend Catalog Browser. > > I searched for plot > > Chose pLotMorph and chose Install Stable Version > > > > I got an Information window saying There was an error trying to install > > PlotMorph. Installation was cancelled. > > To debug this: > > Instead of installing the stable version, load the configuration. > > Type shift-enter to open Spotter. > Type Plot and enter to find ConfigurationOfPlotMorph and browse it. > First take a look at method #stable to see what is defined there > > Yep, there is the missing information. > So let's fix the version10. We can do it in place, as this can not have > worked. Otherwise we would have had to add a new version, and updated > the #stable. > > > Name: ConfigurationOfPlotMorph-StephanEggermont.4 > Author: StephanEggermont > Time: 11 September 2017, 12:09:08.46706 pm > UUID: d297b6da-4815-0d00-8219-91680d9ac81c > Ancestors: ConfigurationOfPlotMorph-StephaneDucasse.3 > > Fixed version10, added pharo 7 > Ok thgat now loads but on loading. I get a large spew of code in the transcript including several OCStoreIntoReadOnlyVariableError: Cannot store into -- Mark

Sept. 11, 2017

Re: [Pharo-users] Let's prepare for Google Code-In 2017 with Pharo Consortium

by Guillermo Polito

Yes this is cool. We need to get a decent set of tasks. On Sat, Sep 9, 2017 at 5:24 PM, Jigyasa Grover <grover.jigyasa1(a)gmail.com> wrote: > Thanks Stef for your support. > > I have already added you in the private repository "GCI-2017-with-Pharo", > as > we need to keep prospective students away from the task list before the > program begins ð > > Looking forward to more ideas on the task list. > > Thanks a lot. > > Best > Jigyasa Grover > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 11, 2017

Re: [Pharo-users] Usability issues with Calypso

by Denis Kudriashov

2017-09-08 14:37 GMT+02:00 kmo <voxkmp(a)gmail.com>: > If Tim had not posted this comment - "I love the fact you can move to a new > method with unsaved changes and no nag prompt".- I would never have known > that it was possible to do this. Since I always save my methods before > moving on I had never experienced this behaviour. > > I think this is an another instance of Calypso violating "the law of least > surprise". Just like the appearance/disappearance of the "new object" tab, > this behaviour was totally unexpected by me. > > I think it is wonderful that you can move on to a new method before you > save > the one you are editing - but surely the natural way of achieving this is > to > make the tabs work more like tabs ina standard text editor. You should be > able to have as many methods opened in tabs - saved or unsaved - as you > want. Why not have a system where if you CTRL or SHIFT click on a method it > adds that method to the set of tabs in the editing area? > > That's what I would have expected all along. When you see a set of tabs in > a > row you assume that you can add to them. > Manual tabs are in todo. How you would avoid auto tabs behaviour? Do you want always manually open/close tabs? In that case for example switching from one class to another class will open six tabs if nobody close old ones. The current behaviour is trying to be close to single source pane behaviour of old browsers. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Sept. 11, 2017