= a few hours of unbridled fun and printNl debugging :-)
<bla> So I'm running the most recent smalltalk and the most recent Iliad. And after I actually started doing something _with_ Iliad instead of _to_ it (what a willing victim for testing packaging Iliad is), I notice that sometimes my browser hangs waiting for a response... and always I manage to find a bug. Switching the application to deploymentMode displays the expected 500 message, so it must have something to do with the default verboseMode. Veni, vidi, and there are messages in ErrorHandler>>produceVerboseResponse that cannot be found in the docs ... if this ain't an invitation to mess around, I don't know what is. Removing the "weird" stuff and sprinkling it with "self error inspect" and "self error backtraceOn: Transcript" produces quite interesting information ... on the console. </bla> So gst has inspect with hardcoded Transcript references in it. And there are four definitions of inspect in the base classes to accomodate different types of objects. Well, my local gst now only has one inspect in Object but four inspectOn: aStream in the base classes ... and things still work. The good new is that I now can produce some really helpful debugging info in ErrorHandler.st produceVerboseResponse [ <category: 'responding'> |info| info := WriteStream on: String new. self error inspectOn: info. self error context backtraceOn: info. FileStream stderr nextPutAll: info contents. self respond: [:response || page | page := Page new. page bodyElement h1: 'Internal Error'; h2: self error description; h3: self error messageText; preformatted: info contents. page build printHtmlOn: response] ] So now I not only see _where_ the problem occurred, I also see with _what data_ it occurred.... sweeet. I'm attaching the two patches to this message for your consideration. s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Le vendredi 26 juin 2009 à 20:25 +0200, Stefan Schmiedl a écrit :
> = a few hours of unbridled fun and printNl debugging :-) > > <bla> > So I'm running the most recent smalltalk and the most recent Iliad. > And after I actually started doing something _with_ Iliad instead of > _to_ it (what a willing victim for testing packaging Iliad is), I > notice that sometimes my browser hangs waiting for a response... > and always I manage to find a bug. > > Switching the application to deploymentMode displays the expected 500 > message, so it must have something to do with the default verboseMode. > > Veni, vidi, and there are messages in ErrorHandler>>produceVerboseResponse > that cannot be found in the docs ... if this ain't an invitation to mess > around, I don't know what is. > > Removing the "weird" stuff and sprinkling it with "self error inspect" > and "self error backtraceOn: Transcript" produces quite interesting > information ... on the console. > </bla> > > So gst has inspect with hardcoded Transcript references in it. > And there are four definitions of inspect in the base classes to > accomodate different types of objects. > Well, my local gst now only has one inspect in Object but four > inspectOn: aStream in the base classes ... and things still work. > > The good new is that I now can produce some really helpful debugging > info in ErrorHandler.st > > produceVerboseResponse [ > <category: 'responding'> > |info| > info := WriteStream on: String new. > self error inspectOn: info. > self error context backtraceOn: info. > FileStream stderr nextPutAll: info contents. > self respond: [:response || page | > page := Page new. > page bodyElement h1: 'Internal Error'; > h2: self error description; > h3: self error messageText; > preformatted: info contents. > page build printHtmlOn: response] > ] > > So now I not only see _where_ the problem occurred, I also see > with _what data_ it occurred.... sweeet. sweet indeed! Paolo, could this patch be included in gst? Thanks Stefan! Nico > > I'm attaching the two patches to this message for your consideration. > > s. > _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (204 bytes) Download Attachment |
On Fri, 26 Jun 2009 21:21:13 +0200
Nicolas Petton <[hidden email]> wrote: > > So now I not only see _where_ the problem occurred, I also see > > with _what data_ it occurred.... sweeet. > Again, I spoke a bit too soon. When will I ever learn? When I evoke errors in the REPL the backtrace contains much more useful info than the one displayed after the error has been caught. There is work to be done yet. s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (205 bytes) Download Attachment |
Le vendredi 26 juin 2009 à 22:03 +0200, Stefan Schmiedl a écrit :
> On Fri, 26 Jun 2009 21:21:13 +0200 > Nicolas Petton <[hidden email]> wrote: > > > > So now I not only see _where_ the problem occurred, I also see > > > with _what data_ it occurred.... sweeet. > > > > Again, I spoke a bit too soon. When will I ever learn? > > When I evoke errors in the REPL the backtrace contains > much more useful info than the one displayed after the > error has been caught. There is work to be done yet. Does "self error resumeContext backtraceOn: ..." help? Cheers! Nico > > s. > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (204 bytes) Download Attachment |
On Fri, 26 Jun 2009 22:14:09 +0200
Nicolas Petton <[hidden email]> wrote: > Le vendredi 26 juin 2009 à 22:03 +0200, Stefan Schmiedl a écrit : > > On Fri, 26 Jun 2009 21:21:13 +0200 > > Nicolas Petton <[hidden email]> wrote: > > > > > > So now I not only see _where_ the problem occurred, I also see > > > > with _what data_ it occurred.... sweeet. > > > > > > > Again, I spoke a bit too soon. When will I ever learn? > > > > When I evoke errors in the REPL the backtrace contains > > much more useful info than the one displayed after the > > error has been caught. There is work to be done yet. > > I added Signal>>resumeContext from Seaside-GST.st. > > Does "self error resumeContext backtraceOn: ..." help? oooh yes. My error message now looks like this: Internal Error The program sent a message which was not understood by the receiver. did not understand #listItem: An instance of MessageNotUnderstood exception: a CoreException arguments: () tag: an Object messageText: 'did not understand #listItem:' resumeBlock: a BlockClosure onDoBlock: a BlockClosure handlerBlock: a BlockClosure context: BlockClosure>>on:do: (BlkClosure.st:192) isNested: nil previousState: 0 creator: a ListElement message: listItem: <'1'> receiver: a ListElement Backtrace: MessageNotUnderstood(Signal)>>activateHandler: (ExcHandling.st:708) MessageNotUnderstood(Exception)>>signal (AnsiExcept.st:216) Iliad.ListElement(Object)>>doesNotUnderstand: #listItem: (AnsiExcept.st:1556) [] in OnlineTester.OTTestWidget>>buildTabsOn: (OnlineTester.star#VFS.ZipFile/widgets/OTTestWidget.st:26) Interval>>do: (Interval.st:96) OnlineTester.OTTestWidget>>buildTabsOn: (OnlineTester.star#VFS.ZipFile/widgets/OTTestWidget.st:27) optimized [] in OnlineTester.OTTestWidget>>contents (OnlineTester.star#VFS.ZipFile/widgets/OTTestWidget.st:20) BlockClosure>>buildOn: (Iliad-Core.star#VFS.ZipFile/Buildables/Extensions.st:58) Iliad.DivElement(Iliad.Element)>>build: (Iliad-Core.star#VFS.ZipFile/Elements/Element.st:154) OnlineTester.OTTestWidget(Iliad.Widget)>>build (Iliad-Core.star#VFS.ZipFile/Buildables/Widget.st:121) OnlineTester.OTTestWidget(Iliad.Buildable)>>buildOn: (Iliad-Core.star#VFS.ZipFile/Buildables/Buildable.st:84) Iliad.DivElement(Iliad.Element)>>build: (Iliad-Core.star#VFS.ZipFile/Elements/Element.st:154) optimized [] in OnlineTester.OTApplication>>index (OnlineTester.star#VFS.ZipFile/application.st:17) now ... I'll go and fix that bug, I don't need it any more :-) s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (205 bytes) Download Attachment |
In reply to this post by Nicolas Petton
> Paolo, could this patch be included in gst?
Mostly. I just do not like #inspectOn: as a name, because with a GUI the inspector will be something else. It's not a problem if #inspect uses a different method than #inspectOn:. Let's just agree on a new name and I'll adjust the patch myself. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sat, 27 Jun 2009 08:26:19 +0200
Paolo Bonzini <[hidden email]> wrote: > > Paolo, could this patch be included in gst? > > Mostly. I just do not like #inspectOn: as a name, because with a GUI > the inspector will be something else. It's not a problem if #inspect > uses a different method than #inspectOn:. Let's just agree on a new > name and I'll adjust the patch myself. printInternalsOn: aStream is what it does. s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
>>> Paolo, could this patch be included in gst?
>> Mostly. I just do not like #inspectOn: as a name, because with a GUI >> the inspector will be something else. It's not a problem if #inspect >> uses a different method than #inspectOn:. Let's just agree on a new >> name and I'll adjust the patch myself. > > printInternalsOn: aStream is what it does. I had thought of #debugOn: (which conflicts with the "debug it" of traditional Smalltalk environments) or #dumpOn: (but this one would conflict with ObjectDumper)? Guys, please weigh in. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Le samedi 27 juin 2009 à 13:03 +0200, Paolo Bonzini a écrit :
> >>> Paolo, could this patch be included in gst? > >> Mostly. I just do not like #inspectOn: as a name, because with a GUI > >> the inspector will be something else. It's not a problem if #inspect > >> uses a different method than #inspectOn:. Let's just agree on a new > >> name and I'll adjust the patch myself. > > > > printInternalsOn: aStream is what it does. > > I had thought of #debugOn: (which conflicts with the "debug it" of > traditional Smalltalk environments) or #dumpOn: (but this one would > conflict with ObjectDumper)? Nico > > Guys, please weigh in. > > Paolo > > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (204 bytes) Download Attachment |
Nicolas Petton wrote:
> Le samedi 27 juin 2009 à 13:03 +0200, Paolo Bonzini a écrit : >>>>> Paolo, could this patch be included in gst? >>>> Mostly. I just do not like #inspectOn: as a name, because with a GUI >>>> the inspector will be something else. It's not a problem if #inspect >>>> uses a different method than #inspectOn:. Let's just agree on a new >>>> name and I'll adjust the patch myself. >>> printInternalsOn: aStream is what it does. >> I had thought of #debugOn: (which conflicts with the "debug it" of >> traditional Smalltalk environments) or #dumpOn: (but this one would >> conflict with ObjectDumper)? > > What about #exploreOn: ? Explore was used for some inspectors in VW, but that's a possibility. I guess every other verb has been used in an IDE so... Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Le samedi 27 juin 2009 à 14:05 +0200, Paolo Bonzini a écrit :
> Nicolas Petton wrote: > > Le samedi 27 juin 2009 à 13:03 +0200, Paolo Bonzini a écrit : > >>>>> Paolo, could this patch be included in gst? > >>>> Mostly. I just do not like #inspectOn: as a name, because with a GUI > >>>> the inspector will be something else. It's not a problem if #inspect > >>>> uses a different method than #inspectOn:. Let's just agree on a new > >>>> name and I'll adjust the patch myself. > >>> printInternalsOn: aStream is what it does. > >> I had thought of #debugOn: (which conflicts with the "debug it" of > >> traditional Smalltalk environments) or #dumpOn: (but this one would > >> conflict with ObjectDumper)? > > > > What about #exploreOn: ? > > Explore was used for some inspectors in VW, but that's a possibility. I > guess every other verb has been used in an IDE so... > > Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (204 bytes) Download Attachment |
On Sat, 27 Jun 2009 14:14:13 +0200
Nicolas Petton <[hidden email]> wrote: > Le samedi 27 juin 2009 à 14:05 +0200, Paolo Bonzini a écrit : > > Nicolas Petton wrote: > > > Le samedi 27 juin 2009 à 13:03 +0200, Paolo Bonzini a écrit : > > >>>>> Paolo, could this patch be included in gst? > > >>>> Mostly. I just do not like #inspectOn: as a name, because > > >>>> with a GUI the inspector will be something else. It's not a > > >>>> problem if #inspect uses a different method than > > >>>> #inspectOn:. Let's just agree on a new name and I'll adjust > > >>>> the patch myself. > > >>> printInternalsOn: aStream is what it does. > > >> I had thought of #debugOn: (which conflicts with the "debug it" > > >> of traditional Smalltalk environments) or #dumpOn: (but this one > > >> would conflict with ObjectDumper)? > > > > > > What about #exploreOn: ? > > > > Explore was used for some inspectors in VW, but that's a > > possibility. I guess every other verb has been used in an IDE so... > > Else, something funny like #peelOn: or something. debugOn: exploreOn: sound too interactive dumpOn: yes, dumping is used for serializing too often nowadays. If you want something short: listOn: ? s. _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk signature.asc (205 bytes) Download Attachment |
In reply to this post by Paolo Bonzini-3
CONTENTS DELETED
The author has deleted this message.
|
> another that I can think of is #examineOn: I'm going with this. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |