January 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by horrido

It depends on how one interprets the last paragraph. Yours is one interpretation, and one that never occurred to me. I didn't see it as "demoting" other languages. The paragraph in no way criticizes other languages. It simply suggests that Smalltalk offers many more resources for evangelism. It's all relative. I happen to like Dart, Elixir, Golang, Julia, and Rust. But be honest: do these languages provide nearly as many reasons to choose them? I'm not being deprecatory. Esteban A. Maringolo wrote > Hi Richard, > > Regardless of the reasoning behind the title of the article, I don't > like the tone of the last paragraph, it is not necessary, and probably > not recommended either, to demote other languages in order to promote > yours. In particular languages that have their own merits and > capabilities to which Smalltalk/Pharo can't fulfill today, and by > design won't neither. > > Regards, > > > Esteban A. Maringolo > > On Thu, Jan 9, 2020 at 1:07 PM Richard Kenneth Eng > < > horrido.hobbies@ > > wrote: >> >> https://itnext.io/why-smalltalk-is-so-easy-to-evangelize-2b88b4d4605c >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 9, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Esteban Maringolo

Hi Richard, Regardless of the reasoning behind the title of the article, I don't like the tone of the last paragraph, it is not necessary, and probably not recommended either, to demote other languages in order to promote yours. In particular languages that have their own merits and capabilities to which Smalltalk/Pharo can't fulfill today, and by design won't neither. Regards, Esteban A. Maringolo On Thu, Jan 9, 2020 at 1:07 PM Richard Kenneth Eng <horrido.hobbies(a)gmail.com> wrote: > > https://itnext.io/why-smalltalk-is-so-easy-to-evangelize-2b88b4d4605c > >

Jan. 9, 2020

Why Smalltalk is so easy to evangelize

by Richard Kenneth Eng

https://itnext.io/why-smalltalk-is-so-easy-to-evangelize-2b88b4d4605c

Jan. 9, 2020

Re: [Pharo-users] is this better regarding naming thigs

by tbrunz

Richard O'Keefe wrote > Seriously, sometimes it's worth it to write good code and then write > glue code to the required interface. Maybe "most of the time". Or "It's almost always worth it". Why practice bad habits? We should reinforce writing good code -- there's not enough of it out there. There's another advantage to this advice: It would be good practice with the techniques needed to extend or interface to existing codebases. We aren't going to rewrite such existing code, and we generally can't rewrite its interfaces either. So, write good code and then write glue code to the required interface. Seems to me this should be standard practice. And the exercism.io mentors might take this into account... -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 8, 2020

JOB: Smalltalkers in Barcelona

by Esteban Lorenzano

Hello Pharoers Please distribute aroundâ¦. Lifeware is looking for smart people and Smalltalkers for positions at Barcelona. If you are interested please contact Massimo Arnoldi <massimo.arnoldi(a)lifeware.ch <mailto:massimo.arnoldi@lifeware.ch>> Esteban

Jan. 8, 2020

Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub

by Ben Coman

On Wed, 8 Jan 2020 at 06:32, LawsonEnglish <LEnglish5(a)cox.net> wrote: > âSimple inspectâ works fine. > > THe trace is: > > UndefinedObject(Object)>>doesNotUnderstand: #new > Message>>sentTo: > UndefinedObject(Object)>>doesNotUnderstand: #new > XMLDocumentHighlightDefaults class(XMLHighlightDefaults > class)>>textColorForShoutProperty: > XMLDocumentHighlightDefaults class(XMLHighlightDefaults > class)>>defaultDefaultColor > XMLDocumentHighlightDefaults(XMLHighlightDefaults)>>defaultColor > XMLDocumentHighlighter(XMLHighlighter)>>initializeColorsWithDefaults: > XMLDocumentHighlighter>>initializeColorsWithDefaults: > XMLDocumentHighlighter(XMLHighlighter)>>initialize > XMLDocumentHighlighter class(Behavior)>>new > XMLHighlightingWriter>>on: > XMLHighlightingWriter class(XMLWriter class)>>on: > XMLHighlightingWriter class(XMLWriter class)>>new > XMLDocument(XMLNode)>>asHighlightedTextWrittenWith: > XMLDocument(XMLNode)>>treeViewLabelText > [ :each | each treeViewLabelText ] in > XMLDocument(XMLNode)>>gtInspectorTreeIn:inContext: in Block: [ :each | each > treeViewLabelText ] > BlockClosure>>glamourValueWithArgs: > BlockClosure(ProtoObject)>>glamourValue: > GLMTreePresentation(GLMFormatedPresentation)>>formatedDisplayValueOf: > GLMTreeMorphNodeModel>>displayText > GLMTreeMorphNodeModel>>elementColumn > [ :node :cont | node perform: self rowMorphGetSelector ] in > MorphTreeColumn>>rowMorphGetterBlock in Block: [ :node :cont | node > perform: self rowMorphGetSele...etc... > MorphTreeColumn>>rowMorphFor: > [ :col | > | v | > v := col rowMorphFor: complexContents. > controls add: v. > col -> v ] in MorphTreeNodeMorph>>buildRowMorph in Block: [ :col | ... > OrderedCollection>>collect: > MorphTreeNodeMorph>>buildRowMorph > MorphTreeNodeMorph>>initRow > MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: > [ :item :idx | > priorMorph := self indentingItemClass new > initWithContents: item > prior: priorMorph > forList: self > indentLevel: newIndent. > firstAddition ifNil: [ firstAddition := priorMorph ]. > morphList add: priorMorph. > "Was this row expanded ? if true -> expand it > again " > ((item hasEquivalentIn: expandedItems) or: [ priorMorph isExpanded ]) > ifTrue: [ priorMorph isExpanded: true. > priorMorph > addChildrenForList: self > addingTo: morphList > withExpandedItems: expandedItems ] ] in > GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>addMorphsTo:from:withExpandedItems:atLevel: > in Block: [ :item :idx | ... > OrderedCollection(SequenceableCollection)>>withIndexDo: > > > > . > > If it isnât obvious what is going wrong from the above, I gues the thing > to do is reinstall Pharo, and go through the steps of installing the > various packages while recording them. If I get the same error, Iâll post > the video of what I did on youtube. If I donât an error, then it was > operator error from the start, obviously. > When it works for others but not yourself, then it seems something is different in the environment. One part of that environment is saved "Settings" so try the following experiment.... Presuming you are using Pharo Launcher... 1. Right click Pharo 7.0 64bit (stable), then > Create Image 2. Right-click that new image, then > LAUNCH WITHOUT SETTING 3. In Playground, evaluate the following all together... Metacello new baseline: 'XMLParserHTML'; repository: 'github://pharo-contributions/XML-XMLParserHTML/src'; load. (#XMLHTMLParser asClass parseURL: ' https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference') inspect. 4. Report whether the error still occurs. ============= That said, reviewing the method near top of your stack... XMLHighlightDefaults >> textColorForShoutProperty: aShoutProperty self haltOnce. ^ TextColor color: (((SHTextStylerST80 new attributesFor: aShoutProperty) detect: [:each | each respondsTo: #color] ifNone: [^ nil]) color) the syntax highlighter indicates that "SHTextStylerST80" is an unknown class, in which scenario your DNU error message is expected when #new is sent to it. I notice there is a "SHTextStyler" class. I'm not sure how this relates to "SHTextStylerST80" but have a go at changing #textColorForShoutProperty: to use it, then again evaluate... (#XMLHTMLParser asClass parseURL: ' https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference') inspect. cheers -ben

Jan. 8, 2020

Re: [Pharo-users] R: Smalltalk: Itâs Not Your Grandfatherâs Programming Language

by Richard O'Keefe

If you were coining a new phrase, the charge of sexism might have some dubious merit. (Since it implies that your grandfather is still using outdated stuff, it is derogatory to males.) However, the phrase "not your grandfather's <whatever>" is widely used to mean "this is not at all an old-fashioned <whatever>", whereas no such phrase with "grandmother" or "grandparent" exists. Accordingly, "not your grandparents' <whatever>" would - fail to connect with the popular phrase - and therefore sound significantly worse, - make you look pretentious when the penny finally dropped, and - detract from your message by focussing attention on the phrase instead of your meaning. Tell your critic to stop bothering you and go volunteer to help defend Iran. "There is no grammatical gender in Persian, and pronouns are not marked for natural gender." (Wikipedia article on the Persian languages.) Rather than pandering to your critic's attempt to exercise linguistic hegemony over you, you might like to find another way to say "40 years later, other programming languages haven't caught up yet." There *were* electric vehicles in my grandfathers' day. Maseratis back then look very primitive now. https://it.wikipedia.org/wiki/Maserati_Tipo_26#/media/File:Maserati_Tipo_26… And people *do* dream of owning a Tesla. At more than my annual pay before I retired, I can only dream. Heck, I bought a *house* for less than a Tesla. The last car I personally bought, I could buy *SEVENTY* of them for the price of a new Tesla. If you can buy a Tesla, you've arrived, Clive. You're eco-pure, Muir. No longer a schlub, Bub. You *sneer* at Maserati owners; they may have more money, but you're *better* than them. I would also suggest that you are in the least concerned about sexism, using expensive cars might just be more provocative than the word "grandfather". Hot-air balloons are old. They are also a modern sport and quite technical. Oh, wait. "The incidence of morbidity and mortality is high among hot-air balloon tour crashes, and the proportion of balloon crashes attributed to paid rides appears to have increased over time." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4888601/ Look, you *can't* please everybody. Do work you're proud of, run it up the flagpole, and maybe you'll get a home run. On Tue, 7 Jan 2020 at 09:18, horrido <horrido.hobbies(a)gmail.com> wrote: > > Thanks! > > I have a question for everyone. Someone has taken me to task for being > "sexist". He says I should refer to "grandparent" instead of "grandfather". > > I'd like to ask for your opinion. Would "grandparent" sound better in my > article? Imagine replacing all instances of "grandfather" with > "grandparent". Would it have the same impact? > > Thanks. > > > > Lorenzo wrote > > Great work Rich!!!! > > > > > > > > My best compliments. > > > > > > > > Lorenzo > > > > > > > > Da: Pharo-users [mailto: > > > pharo-users-bounces@.pharo > > > ] Per conto di Richard Kenneth Eng > > Inviato: lunedÃ¬ 6 gennaio 2020 19:07 > > A: > > > pharo-users@.pharo > > > Oggetto: [Pharo-users] Smalltalk: Itâs Not Your Grandfatherâs Programming > > Language > > > > > > > > https://levelup.gitconnected.com/smalltalk-its-not-your-grandfather-s-progr… > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 8, 2020

Re: [Pharo-users] is this better regarding naming thigs

by Richard O'Keefe

I should have remembered that, seeing that I've done 41/42 of the Pharo exercisms, and am currently doing the F# ones in my spare time, which I have had very little of lately. I have started using the <BADNAME[: 'reason']> annotation in such cases to remind me not to fix the code. Looking back at my solution, I see that my irritation at yet another "Pharo" exercism that had no significant connection with *OOP* as such masked the irritation I should have felt at the bad name. I also recall now my annoyance at exercism.io's frequent practice of omitting key parts of specifications but including tests for them. Seriously, sometimes it's worth it to write good code and then write glue code to the required interface. On Tue, 7 Jan 2020 at 18:50, xap <xap(a)router.33mail.com> wrote: > > richard, fwiw Roeloff mentioned earlier that the message-name was provided by > the exercise set he's following, and isn't of his invention: > http://forum.world.st/is-this-better-regarding-naming-thigs-tp5109389p51094… > . he sh/could fwd your note/s to the course-author ;) > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Jan. 8, 2020

Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub

by Sven Van Caekenberghe

I just tried it in a relatively fresh 7.0.4 image on macOS and it worked as advertised. (The syntax colouring of the XML is off in dark look though). Here is a screenshot: All I did was: Metacello new baseline: 'XMLParserHTML'; repository: 'github://pharo-contributions/XML-XMLParserHTML/src'; load. XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. Good luck. Sven > On 7 Jan 2020, at 23:31, LawsonEnglish <LEnglish5(a)cox.net> wrote: > > âSimple inspectâ works fine. > > THe trace is: > > UndefinedObject(Object)>>doesNotUnderstand: #new > Message>>sentTo: > UndefinedObject(Object)>>doesNotUnderstand: #new > XMLDocumentHighlightDefaults class(XMLHighlightDefaults class)>>textColorForShoutProperty: > XMLDocumentHighlightDefaults class(XMLHighlightDefaults class)>>defaultDefaultColor > XMLDocumentHighlightDefaults(XMLHighlightDefaults)>>defaultColor > XMLDocumentHighlighter(XMLHighlighter)>>initializeColorsWithDefaults: > XMLDocumentHighlighter>>initializeColorsWithDefaults: > XMLDocumentHighlighter(XMLHighlighter)>>initialize > XMLDocumentHighlighter class(Behavior)>>new > XMLHighlightingWriter>>on: > XMLHighlightingWriter class(XMLWriter class)>>on: > XMLHighlightingWriter class(XMLWriter class)>>new > XMLDocument(XMLNode)>>asHighlightedTextWrittenWith: > XMLDocument(XMLNode)>>treeViewLabelText > [ :each | each treeViewLabelText ] in XMLDocument(XMLNode)>>gtInspectorTreeIn:inContext: in Block: [ :each | each treeViewLabelText ] > BlockClosure>>glamourValueWithArgs: > BlockClosure(ProtoObject)>>glamourValue: > GLMTreePresentation(GLMFormatedPresentation)>>formatedDisplayValueOf: > GLMTreeMorphNodeModel>>displayText > GLMTreeMorphNodeModel>>elementColumn > [ :node :cont | node perform: self rowMorphGetSelector ] in MorphTreeColumn>>rowMorphGetterBlock in Block: [ :node :cont | node perform: self rowMorphGetSele...etc... > MorphTreeColumn>>rowMorphFor: > [ :col | > | v | > v := col rowMorphFor: complexContents. > controls add: v. > col -> v ] in MorphTreeNodeMorph>>buildRowMorph in Block: [ :col | ... > OrderedCollection>>collect: > MorphTreeNodeMorph>>buildRowMorph > MorphTreeNodeMorph>>initRow > MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: > [ :item :idx | > priorMorph := self indentingItemClass new > initWithContents: item > prior: priorMorph > forList: self > indentLevel: newIndent. > firstAddition ifNil: [ firstAddition := priorMorph ]. > morphList add: priorMorph. > "Was this row expanded ? if true -> expand it > again " > ((item hasEquivalentIn: expandedItems) or: [ priorMorph isExpanded ]) > ifTrue: [ priorMorph isExpanded: true. > priorMorph > addChildrenForList: self > addingTo: morphList > withExpandedItems: expandedItems ] ] in GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [ :item :idx | ... > OrderedCollection(SequenceableCollection)>>withIndexDo: > > > > . > > If it isnât obvious what is going wrong from the above, I gues the thing to do is reinstall Pharo, and go through the steps of installing the various packages while recording them. If I get the same error, Iâll post the video of what I did on youtube. If I donât an error, then it was operator error from the start, obviously. > > Thanks for your help. > > > L > >> On Jan 7, 2020, at 3:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Something is wrong in your image. >> The XML package adds special GT inspector views, the error is probably there. >> This has nothing to do with the platform. >> >> BTW, a stack trace would be much appreciated, like: >> >> ZeroDivide when doing: 1/0 >> >> SmallInteger>>/ >> UndefinedObject>>DoIt >> OpalCompiler>>evaluate >> RubSmalltalkEditor>>evaluate:andDo: >> RubSmalltalkEditor>>highlightEvaluateAndDo: >> [ textMorph textArea editor highlightEvaluateAndDo: ann action. >> textMorph shoutStyler style: textMorph text ] in [ textMorph textArea >> handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. >> textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc... >> RubEditingArea(RubAbstractTextArea)>>handleEdit: >> [ textMorph textArea >> handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. >> textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea... >> WorldState>>runStepMethodsIn: >> WorldMorph>>runStepMethods >> WorldState>>doOneCycleNowFor: >> WorldState>>doOneCycleFor: >> WorldMorph>>doOneCycle >> WorldMorph class>>doOneCycle >> [ [ WorldMorph doOneCycle. >> Processor yield. >> false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ WorldMorph doOneCycle.... >> [ self value. >> Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value.... >> >> You can copy that from the debugger extra menu (top right). >> >> Try 'Basic Inspect It' instead of 'Inspect It', this will use an older less complex inspector, that will probably work. >> >>> On 7 Jan 2020, at 23:06, LawsonEnglish <LEnglish5(a)cox.net> wrote: >>> >>> Well, as you can see in my response elsewhere, none of that actually works as you describe. >>> >>>> ingredientsXML := XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>> >>> Doesnât raise any errors, with or without the local variable declaration. >>> >>>> ingredientsXML = nil returns false >>> >>>> ingredientsXML inspect >>> >>> Raises the message â#new on nil >>> >>> I âdo itâ on the entire text or on each line in the order entered. It doesnât matter. >>> >>> Iâm using a Mac with Mac OS X Catalina, using Pharo 7. >>> >>> >>> L >>> >>> >>>> On Jan 7, 2020, at 5:31 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> >>>> Agree with Peter - but "screw things up" means then the users screws up. >>>> >>>> Pharo and the Playground is working fine on them. But one has to know the difference when >>>> working with the Playground: >>>> >>>> 1. If you evaluate with an explicit variable declaration than the variable is freshly defined and used like a temporary variable in a method: >>>> >>>> | ingredientsXML | >>>> ingredientsXML := XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>>> ingredientsXML inspect >>>> >>>> You have to selected the full text and evaluate it (either with "do It" or "print it" to get the result. >>>> >>>> If you only select "ingredientsXML inspect" part first and evaluate then the variable "ingredientsXML" is not known, undefined >>>> and uninitialized and therefore results in a nil. >>>> >>>> 2. If in the playground you do not give an explicit variable declaration at the beginning line like for example in >>>> >>>> ingredientsXML := XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>>> ingredientsXML inspect >>>> >>>> then a "workspace local variable" is implicitly created by the playground as soon as you evaluate which means >>>> >>>> - "ingredientsXML" is defined as a workspace variable as soon as you evaluate >>>> - the contents of "ingredientsXML" is preserved over different evaluations within the workspace / playground >>>> - you can use only "ingredientsXML" within this playground (not in another plaground) >>>> >>>> So you can evaluate the first line doing the assignment (this initializes the workspace variable "ingredientsXML" for the current playground) >>>> and when you later want to use it again you can just inspect it or evaluate the second line in the same playground. >>>> >>>> If you like you can open a second playground which can have its own "ingredientsXML" workspace variable. >>>> >>>> Workspace variables (or "playground variables") are convenient for experimenting - as they are preserved - but >>>> yes they might confuse you when you cant remember what was done with them last. >>>> >>>> Bye >>>> T. >>>> >>>>> Gesendet: Dienstag, 07. Januar 2020 um 09:55 Uhr >>>>> Von: "PBKResearch" <peter(a)pbkresearch.co.uk> >>>>> An: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> >>>>> Betreff: Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub >>>>> >>>>> It may be a quirk of how Pharo Playground works. It doesn't need local variable declarations - which is convenient - but putting them in can screw things up. Try your snippet again without the first line. Compare Torsten's code. >>>>> >>>>> HTH >>>>> >>>>> Peter Kenny >>>>> >>>>> -----Original Message----- >>>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Torsten Bergmann >>>>> Sent: 07 January 2020 07:47 >>>>> To: pharo-users(a)lists.pharo.org >>>>> Cc: pharo-users(a)lists.pharo.org >>>>> Subject: Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub >>>>> >>>>> Works without a problem (Pharo 8 on Windows), see attached. So it looks like a local problem. >>>>> >>>>> Just check the debugger and compare to the squeak version where you run in trouble. >>>>> Maybe the document could not be retrieved on your machine. >>>>> >>>>> Bye >>>>> T. >>>>> >>>>>> Gesendet: Dienstag, 07. Januar 2020 um 04:42 Uhr >>>>>> Von: "LawsonEnglish" <lenglish5(a)cox.net> >>>>>> An: pharo-users(a)lists.pharo.org >>>>>> Betreff: Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub >>>>>> >>>>>> Torsten Bergmann wrote >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> You can load using >>>>>>> >>>>>>> Metacello new >>>>>>> baseline: 'XMLParserHTML'; >>>>>>> repository: 'github://pharo-contributions/XML-XMLParserHTML/src'; >>>>>>> load. >>>>>>> >>>>>>> >>>>>>> Bye >>>>>>> T. >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm trying to use the sample code in the pharo screen scraping booklet >>>>>> â >>>>>> http://books.pharo.org/booklet-Scraping/pdf/2018-09-02-scrapingbook.pdf â but while everything appears to load, I'm getting an odd behavior from: >>>>>> >>>>>> /| ingredientsXML | >>>>>> ingredientsXML := XMLHTMLParser parseURL: >>>>>> 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>>>>> ingredientsXML inspect/ >>>>>> >>>>>> "#new was sent to nil" >>>>>> >>>>>> No matter what URL I use, I get the same message. >>>>>> >>>>>> I'm using Mac OS Catalina so I thought I might have some strange Mac >>>>>> OS security issue (like it was quietly refusing to allow Pharo to >>>>>> access the internet), but I tested with squeak and the old >>>>>> >>>>>> /html :=(HtmlParser parse: >>>>>> 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference' >>>>>> asUrl retrieveContents content)/ >>>>>> >>>>>> and that returns actual html without any problems. >>>>>> >>>>>> >>>>>> Suggestions? >>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> L >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >

Jan. 7, 2020

Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub

by LawsonEnglish

âSimple inspectâ works fine. THe trace is: UndefinedObject(Object)>>doesNotUnderstand: #new Message>>sentTo: UndefinedObject(Object)>>doesNotUnderstand: #new XMLDocumentHighlightDefaults class(XMLHighlightDefaults class)>>textColorForShoutProperty: XMLDocumentHighlightDefaults class(XMLHighlightDefaults class)>>defaultDefaultColor XMLDocumentHighlightDefaults(XMLHighlightDefaults)>>defaultColor XMLDocumentHighlighter(XMLHighlighter)>>initializeColorsWithDefaults: XMLDocumentHighlighter>>initializeColorsWithDefaults: XMLDocumentHighlighter(XMLHighlighter)>>initialize XMLDocumentHighlighter class(Behavior)>>new XMLHighlightingWriter>>on: XMLHighlightingWriter class(XMLWriter class)>>on: XMLHighlightingWriter class(XMLWriter class)>>new XMLDocument(XMLNode)>>asHighlightedTextWrittenWith: XMLDocument(XMLNode)>>treeViewLabelText [ :each | each treeViewLabelText ] in XMLDocument(XMLNode)>>gtInspectorTreeIn:inContext: in Block: [ :each | each treeViewLabelText ] BlockClosure>>glamourValueWithArgs: BlockClosure(ProtoObject)>>glamourValue: GLMTreePresentation(GLMFormatedPresentation)>>formatedDisplayValueOf: GLMTreeMorphNodeModel>>displayText GLMTreeMorphNodeModel>>elementColumn [ :node :cont | node perform: self rowMorphGetSelector ] in MorphTreeColumn>>rowMorphGetterBlock in Block: [ :node :cont | node perform: self rowMorphGetSele...etc... MorphTreeColumn>>rowMorphFor: [ :col | | v | v := col rowMorphFor: complexContents. controls add: v. col -> v ] in MorphTreeNodeMorph>>buildRowMorph in Block: [ :col | ... OrderedCollection>>collect: MorphTreeNodeMorph>>buildRowMorph MorphTreeNodeMorph>>initRow MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: [ :item :idx | priorMorph := self indentingItemClass new initWithContents: item prior: priorMorph forList: self indentLevel: newIndent. firstAddition ifNil: [ firstAddition := priorMorph ]. morphList add: priorMorph. "Was this row expanded ? if true -> expand it again " ((item hasEquivalentIn: expandedItems) or: [ priorMorph isExpanded ]) ifTrue: [ priorMorph isExpanded: true. priorMorph addChildrenForList: self addingTo: morphList withExpandedItems: expandedItems ] ] in GLMPaginatedMorphTreeMorph(MorphTreeMorph)>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [ :item :idx | ... OrderedCollection(SequenceableCollection)>>withIndexDo: . If it isnât obvious what is going wrong from the above, I gues the thing to do is reinstall Pharo, and go through the steps of installing the various packages while recording them. If I get the same error, Iâll post the video of what I did on youtube. If I donât an error, then it was operator error from the start, obviously. Thanks for your help. L > On Jan 7, 2020, at 3:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Something is wrong in your image. > The XML package adds special GT inspector views, the error is probably there. > This has nothing to do with the platform. > > BTW, a stack trace would be much appreciated, like: > > ZeroDivide when doing: 1/0 > > SmallInteger>>/ > UndefinedObject>>DoIt > OpalCompiler>>evaluate > RubSmalltalkEditor>>evaluate:andDo: > RubSmalltalkEditor>>highlightEvaluateAndDo: > [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] in [ textMorph textArea > handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc... > RubEditingArea(RubAbstractTextArea)>>handleEdit: > [ textMorph textArea > handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. > textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea... > WorldState>>runStepMethodsIn: > WorldMorph>>runStepMethods > WorldState>>doOneCycleNowFor: > WorldState>>doOneCycleFor: > WorldMorph>>doOneCycle > WorldMorph class>>doOneCycle > [ [ WorldMorph doOneCycle. > Processor yield. > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ WorldMorph doOneCycle.... > [ self value. > Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value.... > > You can copy that from the debugger extra menu (top right). > > Try 'Basic Inspect It' instead of 'Inspect It', this will use an older less complex inspector, that will probably work. > >> On 7 Jan 2020, at 23:06, LawsonEnglish <LEnglish5(a)cox.net> wrote: >> >> Well, as you can see in my response elsewhere, none of that actually works as you describe. >> >>> ingredientsXML := XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >> >> Doesnât raise any errors, with or without the local variable declaration. >> >>> ingredientsXML = nil returns false >> >>> ingredientsXML inspect >> >> Raises the message â#new on nil >> >> I âdo itâ on the entire text or on each line in the order entered. It doesnât matter. >> >> Iâm using a Mac with Mac OS X Catalina, using Pharo 7. >> >> >> L >> >> >>> On Jan 7, 2020, at 5:31 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Agree with Peter - but "screw things up" means then the users screws up. >>> >>> Pharo and the Playground is working fine on them. But one has to know the difference when >>> working with the Playground: >>> >>> 1. If you evaluate with an explicit variable declaration than the variable is freshly defined and used like a temporary variable in a method: >>> >>> | ingredientsXML | >>> ingredientsXML := XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>> ingredientsXML inspect >>> >>> You have to selected the full text and evaluate it (either with "do It" or "print it" to get the result. >>> >>> If you only select "ingredientsXML inspect" part first and evaluate then the variable "ingredientsXML" is not known, undefined >>> and uninitialized and therefore results in a nil. >>> >>> 2. If in the playground you do not give an explicit variable declaration at the beginning line like for example in >>> >>> ingredientsXML := XMLHTMLParser parseURL: 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>> ingredientsXML inspect >>> >>> then a "workspace local variable" is implicitly created by the playground as soon as you evaluate which means >>> >>> - "ingredientsXML" is defined as a workspace variable as soon as you evaluate >>> - the contents of "ingredientsXML" is preserved over different evaluations within the workspace / playground >>> - you can use only "ingredientsXML" within this playground (not in another plaground) >>> >>> So you can evaluate the first line doing the assignment (this initializes the workspace variable "ingredientsXML" for the current playground) >>> and when you later want to use it again you can just inspect it or evaluate the second line in the same playground. >>> >>> If you like you can open a second playground which can have its own "ingredientsXML" workspace variable. >>> >>> Workspace variables (or "playground variables") are convenient for experimenting - as they are preserved - but >>> yes they might confuse you when you cant remember what was done with them last. >>> >>> Bye >>> T. >>> >>>> Gesendet: Dienstag, 07. Januar 2020 um 09:55 Uhr >>>> Von: "PBKResearch" <peter(a)pbkresearch.co.uk> >>>> An: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> >>>> Betreff: Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub >>>> >>>> It may be a quirk of how Pharo Playground works. It doesn't need local variable declarations - which is convenient - but putting them in can screw things up. Try your snippet again without the first line. Compare Torsten's code. >>>> >>>> HTH >>>> >>>> Peter Kenny >>>> >>>> -----Original Message----- >>>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Torsten Bergmann >>>> Sent: 07 January 2020 07:47 >>>> To: pharo-users(a)lists.pharo.org >>>> Cc: pharo-users(a)lists.pharo.org >>>> Subject: Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub >>>> >>>> Works without a problem (Pharo 8 on Windows), see attached. So it looks like a local problem. >>>> >>>> Just check the debugger and compare to the squeak version where you run in trouble. >>>> Maybe the document could not be retrieved on your machine. >>>> >>>> Bye >>>> T. >>>> >>>>> Gesendet: Dienstag, 07. Januar 2020 um 04:42 Uhr >>>>> Von: "LawsonEnglish" <lenglish5(a)cox.net> >>>>> An: pharo-users(a)lists.pharo.org >>>>> Betreff: Re: [Pharo-users] [ANN] XMLParserHTML moved to GitHub >>>>> >>>>> Torsten Bergmann wrote >>>>>> Hi, >>>>>> >>>>>> >>>>>> You can load using >>>>>> >>>>>> Metacello new >>>>>> baseline: 'XMLParserHTML'; >>>>>> repository: 'github://pharo-contributions/XML-XMLParserHTML/src'; >>>>>> load. >>>>>> >>>>>> >>>>>> Bye >>>>>> T. >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to use the sample code in the pharo screen scraping booklet >>>>> â >>>>> http://books.pharo.org/booklet-Scraping/pdf/2018-09-02-scrapingbook.pdf â but while everything appears to load, I'm getting an odd behavior from: >>>>> >>>>> /| ingredientsXML | >>>>> ingredientsXML := XMLHTMLParser parseURL: >>>>> 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference'. >>>>> ingredientsXML inspect/ >>>>> >>>>> "#new was sent to nil" >>>>> >>>>> No matter what URL I use, I get the same message. >>>>> >>>>> I'm using Mac OS Catalina so I thought I might have some strange Mac >>>>> OS security issue (like it was quietly refusing to allow Pharo to >>>>> access the internet), but I tested with squeak and the old >>>>> >>>>> /html :=(HtmlParser parse: >>>>> 'https://ndb.nal.usda.gov/ndb/search/list?sort=ndb&ds=Standard+Reference' >>>>> asUrl retrieveContents content)/ >>>>> >>>>> and that returns actual html without any problems. >>>>> >>>>> >>>>> Suggestions? >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> L >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > >

Jan. 7, 2020