September 2017 - Pharo-users

Who is maintaining of Artefact?

by Alejandro Infante

Hi! I would like to explore having support for Unicode characters. I want to help for it. Who is the right person to talk about it? Cheers! Alejandro

Sept. 11, 2017

Re: [Pharo-users] Standalone HTML Model

by Herby VojÄÃk

Stephane Ducasse wrote: > Hi Pierce Ng > > How different is the API from Seaside? > Because I would like to use it. > I like to think modularly :) > > Stef Maybe porting Silk and let it write to some simulated DOM could be interesting as well... :-) https://lolg.it/herby/silk Herby > 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

help needed regarding conversion of hex to binary

by Casimiro de Almeida Barreto

Is there a (easy and ready) way to convert hexa to binary. I mean, convert data that was transformed Â Â Â x := myData asByteArray hex. back to binary?

Sept. 11, 2017

Re: [Pharo-users] PlotMorph on Pharo 6.1

by stephan

On 11-09-17 19:20, Stephane Ducasse wrote: > Stefan > > (Did you publish the configuration in the PlotMorph repo?) > ifTrue: [ Stefan isPerfect ] PlotMorph, MetaRepos for Pharo 5 and 6 :)

Sept. 11, 2017

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

by Esteban A. Maringolo

2017-09-11 14:44 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> Am 11.09.2017 um 19:05 schrieb H. Hirzel <hannes.hirzel(a)gmail.com>: >> Now 488 out of 479 tests pass. > I would call that superb quality ð It's a 10+taxes as we say :) Esteban A. Maringolo

Sept. 11, 2017

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