1.3 and scamper html package; unexpected emergency evaluator

Stef, all,

I am doing some well-intentioned reverse-engineering of a system (aka trying to read uncommented code) and have been looking at some html that it produces.  Scamper's parser was helpful some years back, so I looked on SqueakSource and found two HTML packages.  I had the validation package installed, so I decided to add the scamper parser package.

Weirdness #1: I was curious about what was going to happen when I installed a second HTML* package.  I did NOT expect the existing package(s) to be replaced :(  Didn't save that image.

I owe you guys some serious testing on 1.3, so I decided to use the one-click to run the scamper package.  My plan was to view source on a locally-produced page, select-all+copy and then pull the text from the clipboard to parse it.  I *should* have done this:

     HtmlParser parse:Clipboard default clipboardText string readStream.

Aside from every other item being an empty HtmlAttributes (probably very correct if a little odd looking), it does pretty much exactly what I had in mind.  I said I should have done the above.  What I in fact did was

     HtmlParser parse:Clipboard default clipboardText string readStream.

(the #string send is missing).  

Weirdness #2: It's interesting, because I get a vm error (text all over the main window with an offer to open an emergency evaluator) saying *** System error handling failed ***.

Hitting any key clears the error and displays a walkback that will open a debugger revealing that #replaceHtmlCharRefs is missing, or so that appears to be the problem.  Of course the real problem is that I evaluated the wrong expression, but I should simply get the walkback, not the callstack.  Is there something I can do to help unravel the cause of the problem?  I used the 1.3 one-click from the web site.

Bill

On Oct 14, 2011, at 10:28 PM, Schwab,Wilhelm K wrote:

> Stef, all,
>
> I am doing some well-intentioned reverse-engineering of a system (aka trying to read uncommented code) and have been looking at some html that it produces.  Scamper's parser was helpful some years back, so I looked on SqueakSource and found two HTML packages.  I had the validation package installed, so I decided to add the scamper parser package.
>
> Weirdness #1: I was curious about what was going to happen when I installed a second HTML* package.  I did NOT expect the existing package(s) to be replaced :(  Didn't save that image.

yes package as jst string conventions so ...

I do not know. Indeed it looks like the handler did not took place and we get the emergency something.
Would be good to get a simple way to reproduce the behavior.


>
> Bill
>
>
>
>

Stef,

Other than some simple customizations of the image, I used the one-click (on 32 bit Ubuntu 10.04), loaded the package and evaluated the incorrect line.

I'll see if I can trip it up with minimal steps.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Friday, October 14, 2011 4:38 PM
To: [hidden email]
Subject: Re: [Pharo-project] 1.3 and scamper html package;      unexpected emergency evaluator

On Oct 14, 2011, at 10:28 PM, Schwab,Wilhelm K wrote:

> Stef, all,
>
> I am doing some well-intentioned reverse-engineering of a system (aka trying to read uncommented code) and have been looking at some html that it produces.  Scamper's parser was helpful some years back, so I looked on SqueakSource and found two HTML packages.  I had the validation package installed, so I decided to add the scamper parser package.
>
> Weirdness #1: I was curious about what was going to happen when I installed a second HTML* package.  I did NOT expect the existing package(s) to be replaced :(  Didn't save that image.

yes package as jst string conventions so ...

I do not know. Indeed it looks like the handler did not took place and we get the emergency something.
Would be good to get a simple way to reproduce the behavior.


>
> Bill
>
>
>
>

Here is my proposed sequence of steps to reproduce the defect:

(1) get/unzip 1.3 one-click
(2) run it (perhaps on 32 bit Ubuntu Lucid)
(3) open a workspace
(4) paste the following text:

      HtmlParser parse:Clipboard default clipboardText  readStream.

(5) Select the above and Do-it.
Note the missing #string send - the code is not expected to work; it should cause a walkback w/o offering to open an emergency evaluator.

The above steps give me an error claiming "system error handling failed."  Can anyone reproduce it?

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Friday, October 14, 2011 4:38 PM
To: [hidden email]
Subject: Re: [Pharo-project] 1.3 and scamper html package;      unexpected emergency evaluator

On Oct 14, 2011, at 10:28 PM, Schwab,Wilhelm K wrote:

> Stef, all,
>
> I am doing some well-intentioned reverse-engineering of a system (aka trying to read uncommented code) and have been looking at some html that it produces.  Scamper's parser was helpful some years back, so I looked on SqueakSource and found two HTML packages.  I had the validation package installed, so I decided to add the scamper parser package.
>
> Weirdness #1: I was curious about what was going to happen when I installed a second HTML* package.  I did NOT expect the existing package(s) to be replaced :(  Didn't save that image.

yes package as jst string conventions so ...

I do not know. Indeed it looks like the handler did not took place and we get the emergency something.
Would be good to get a simple way to reproduce the behavior.


>
> Bill
>
>
>
>