[Pharo-project] 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 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.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, October 14, 2011 4:38 PM To: Pharo-project@lists.gforge.inria.fr 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 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.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, October 14, 2011 4:38 PM To: Pharo-project@lists.gforge.inria.fr 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 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.
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
participants (2)
-
Schwab,Wilhelm K -
Stéphane Ducasse