<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>That awkward moment when one realizes that the murky road less travelled by was once the only thoroughfare in the world.</div><div><br></div><div>Casey</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 15, 2014 at 2:33 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">UI code can be notoriously difficult to debug, eh? One primitive tool<br>
I sometimes use is a good ol'e Smalltalk global, say #X. I make it an<br>
OrderedCollection and then, in #setUpdatablePanesFrom:, just before it<br>
prints to the Transcript, add in this line:<br>
<br>
X add: thisContext longStack.<br>
<br>
Or,<br>
<br>
X add: { thisContext longStack. subViews copy }<br>
<br>
can sometimes give some clues.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Sat, Sep 13, 2014 at 11:35 PM, Casey Ransberger<br>
<<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>> wrote:<br>
> I've been using MVC. It's still buggy, but mostly usable. I thought that if<br>
> someone just used it for a little while, we'd know where most of the worst<br>
> bugs are.<br>
><br>
> Currently tracking two issues, one with errors occurring after bringing up<br>
> context menus (haven't started really digging on that one yet,) and a<br>
> warning which appears for reasons unknown in the Transcript. This is about<br>
> the latter.<br>
><br>
> Warning: view contents not found.<br>
><br>
> I spent probably ten minutes sifting through all of the methods containing<br>
> the string 'Warning:' when the whole string didn't turn up any hits, and I<br>
> do think I have a lead.<br>
><br>
> It looks like the latter issue is occurring in<br>
> StandardSystemView>>setUpdatablePanesFrom:, but I'm not sure why yet. The<br>
> method itself seems pretty straightforward, but for some reason, the block<br>
> temp aPane is ending up nil.<br>
><br>
> If I'm reading this right, aPane is assigned the value of sending<br>
> #subViewSatisfying: to a StandardSystemView (in this case, self,) and the<br>
> argument seems to be a block specifying a constraint, and I may as well<br>
> paste in the send.<br>
><br>
> aPane := self subViewSatisfying:<br>
> [:pane | (pane isKindOf: PluggableListView) and: [pane getListSelector ==<br>
> sel]].<br>
><br>
> This happens right before the nil check, which probably means that the<br>
> constraint doesn't match whatever #subViewSatisfying: searches (or<br>
> #subViewSatisfying: is just borked.)<br>
><br>
> View>>#subViewSatisfying: is trivial, and indeed returns nil on no-match.<br>
> The variable subViews just doesn't have what the method is looking for. I<br>
> set a breakpoint in order to learn what was actually in there, but alas: it<br>
> doesn't repro when I'm looking, which is more or less an "all stop" for me<br>
> on this one.<br>
><br>
> Does anyone know this code well?<br>
><br>
> TIA,<br>
><br>
> Casey<br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>