“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 <
[hidden email]> 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 <
[hidden email]> 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 <
[hidden email]> 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" <
[hidden email]>
>>>> An: "'Any question about pharo is welcome'" <
[hidden email]>
>>>> 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 <
[hidden email]> On Behalf Of Torsten Bergmann
>>>> Sent: 07 January 2020 07:47
>>>> To:
[hidden email]
>>>> Cc:
[hidden email]
>>>> 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" <
[hidden email]>
>>>>> An:
[hidden email]
>>>>> 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>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Locked
