Thanks for the tip. I didn't know I could get the stack by sending a
message to thisContext, but it makes perfect sense. That'll be useful all
over the place.

As for debugging in UIs: when I started playing around with the idea of
"desktop themes" in Cuis, I definitely saw the precarious relationship
between the debugger and the graphics system that renders it. When you're
changing the behavior of (say) SystemWindow, and you botch something, you
get… a debugger, attempting to render itself, encountering the bug you've
introduced, popping a new debugger, rinse-repeat until the screen is
completely full of broken debuggers and you force-quit the VM in defeat!
Which in Cuis happened *crazy* fast, even on the interpreter.

Of course, the benefits of system-implemented-in-itself generally dwarf the
drawbacks. One learns new ways of working and gets used to the sticky
parts. I remember when I first got started, and I wanted to rename a class
variable in the UI, I was like "how in the hell do I do this without
breaking stuff?" It wasn't hard to realize that I could just create a new
variable, stick the value in it, point everything that uses it at the new
variable, and fire torpedoes into the old one, but growing up with mostly
write-compile-coffee-lunch-debug had hobbled my thinking.

Anyway MVC beats the pants off of Squeak's Morphic implementation at the
track, so I think it makes sense to use it for web heads, databases, stuff
like that where generally no-one is actually using the UI most of the time.
It seems like the most sensible tool to use in making Morphic
re/unloadable, at least for now (though I've thought a bit about eventually
getting rid of both and using the telnet-thingy in OSProcess, or possibly
remote messaging/debugging.)

That awkward moment when one realizes that the murky road less travelled by
was once the only thoroughfare in the world.

Casey


On Mon, Sep 15, 2014 at 2:33 PM, Chris Muller <asqueaker at gmail.com> wrote:

> UI code can be notoriously difficult to debug, eh?  One primitive tool
> I sometimes use is a good ol'e Smalltalk global, say #X.  I make it an
> OrderedCollection and then, in #setUpdatablePanesFrom:, just before it
> prints to the Transcript, add in this line:
>
>   X add: thisContext longStack.
>
> Or,
>
>   X add: { thisContext longStack. subViews copy }
>
> can sometimes give some clues.
>
>
> On Sat, Sep 13, 2014 at 11:35 PM, Casey Ransberger
> <casey.obrien.r at gmail.com> wrote:
> > I've been using MVC. It's still buggy, but mostly usable. I thought that
> if
> > someone just used it for a little while, we'd know where most of the
> worst
> > bugs are.
> >
> > Currently tracking two issues, one with errors occurring after bringing
> up
> > context menus (haven't started really digging on that one yet,) and a
> > warning which appears for reasons unknown in the Transcript. This is
> about
> > the latter.
> >
> > Warning: view contents not found.
> >
> > I spent probably ten minutes sifting through all of the methods
> containing
> > the string 'Warning:' when the whole string didn't turn up any hits, and
> I
> > do think I have a lead.
> >
> > It looks like the latter issue is occurring in
> > StandardSystemView>>setUpdatablePanesFrom:, but I'm not sure why yet. The
> > method itself seems pretty straightforward, but for some reason, the
> block
> > temp aPane is ending up nil.
> >
> > If I'm reading this right, aPane is assigned the value of sending
> > #subViewSatisfying: to a StandardSystemView (in this case, self,) and the
> > argument seems to be a block specifying a constraint, and I may as well
> > paste in the send.
> >
> > aPane := self subViewSatisfying:
> > [:pane | (pane isKindOf: PluggableListView) and: [pane getListSelector ==
> > sel]].
> >
> > This happens right before the nil check, which probably means that the
> > constraint doesn't match whatever #subViewSatisfying: searches (or
> > #subViewSatisfying: is just borked.)
> >
> > View>>#subViewSatisfying: is trivial, and indeed returns nil on no-match.
> > The variable subViews just doesn't have what the method is looking for. I
> > set a breakpoint in order to learn what was actually in there, but alas:
> it
> > doesn't repro when I'm looking, which is more or less an "all stop" for
> me
> > on this one.
> >
> > Does anyone know this code well?
> >
> > TIA,
> >
> > Casey
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140915/bbaed909/attachment.htm