Trouble getting slate gui started from instructions

[Timmy Douglas]

Brian Rice <water at tunes.org> writes:

> On Apr 10, 2006, at 6:53 PM, Timmy Douglas wrote:
>
>> Brian Rice <water at tunes.org> writes:
>>
>>> On Apr 8, 2006, at 11:54 AM, Timmy Douglas wrote:
>> I got a little displaying but it 'crashes' into the debugger after
>> less than a second:
>>
>> from windows.slate:
>>
>> entry@(Windows EventTableEntry traits) construct
>> [| event |
>>   event: entry prototype copy.
>>   entry constructors do: [| :name | event construct: name].
>>   event
>> ]
>>
>> entry constructors do: [| :name | event construct: name]
>>
>> entry: ("EventTableEntry" prototype: ("MouseMotionEvent" ...).
>> constructors: #MouseMotionEvent)
>> event: ("MouseMotionEvent" timeStamp: Nil. source: Nil. pointer:
>> Nil. position: Nil)
>
> Ouch!

well it doesn't seem like a huge ouch here. I guess MouseMotionEvent
should have been more initialized though. It did take me a while to
figure out what was going on though because I didn't realize that the
'do:' would behave on symbols.


>> First of all, it'd be nice if the debugger would put an arrow or
>> something before that single line with "entry constructors  do:
>> ...". I think it'd make it easier to read since I keep
>> (incorrectly) thinking it is separate code that comes after the
>> block.
>
> Agreed. I'll take a look. Anyone can see where the source tree is  
> printed in src/lib/debugger.slate under the method framePrint which  
> starts at line 223.
>
> The revealing part is that "method sourceTreeOf: ..." is the  
> CompiledMethod code to look at its debugMap for the sourceTree sub- 
> node corresponding to the instruction pointer. The problem is that  
> the sub-node might have too much underneath it; so either some smarts  
> need to be built in there, or the code in vm/interp/compiler.slate  
> that builds the debugMap needs to do more work to make it more  
> precise. In any case, each node usually has its line number, so there  
> may at least be a way of printing that out (line number relative,  
> say, to the line number of the top-most method it's in).

ok, maybe I'll try to think of another way to print it later if no one
else does. thanks for the pointer.



>> The problem is that "entry constructors" = #MouseMotionEvent or
>> something. This actually works with the do loop (which I think is a
>> little bizzare... I think "#blah is: Collection" should return false.)
>
> You're right, but the idea is that a Symbol is an interned object  
> with the payload built in (yes I know about the big idea behind  
> Common Lisp symbols and prefer it, but there's not much payoff for us  
> there yet).

I'm not sure I understand what you mean here.


>> Anyways, I think since the symbol is a collection, the following code
>> results:
>>
>> "event construct: $M"
>>
>> and obviously, the method lookup fails there. It might even fail if it
>> had worked since I think this is more broken later on. But anyways,
>> I'm not sure what approach I should take to fixing this since I think
>> this symbol-as-collection is a little quirky (if you want that
>> behavior you should probably convert it to a string, imo. what's your
>> view?) and I wasn't sure if I should just change constructors to be a
>> list when it is created, like this:
>>
>> {
>>  snip snip snip
>>
>>     151 -> #(MouseEnterEvent                    (osWindow
>> mouseMotionPosition)).
>>     152 -> #(MouseLeaveEvent                    (osWindow
>> mouseMotionPosition)).
>> } do: [|:each|
>>     Windows eventTable at: each key put:
>>       (Windows EventTableEntry
>>          newPrototype: (events atSlotNamed: each value first)
>>          constructors: {each value first.})].
>
> Hrm. I'm not sure what the intended way for this to work is. If
> there's a place where an extra method override can be done for
> Symbol vs. Collection, that'd be a decent work-around. As it is,
> I'll bet that "entry constructors" should be {#theSymbol} rather
> than just #theSymbol. Any idea how it got to be the latter?

Yeah I'm clueless right now to how this code was supposed to work in
the beginning since I've only really seen it in it's broken state. The
"newPrototype:constructors:" method is only used in this location, so
I can't really look anywhere else for it. Since "constructors:" is
plural, I added the curly braces there but it seems weird that the list
would always have only one element in it.

It looks like prototype is just the name of the class to copy for the
event and constructors are a list of symbols that are applied after it
is copied through the 'construct:' message. I'm guessing if you had a
move event, suppose you would fill the moveEvent's slots with the x
position and y position. If the ExternalLib interface to get the x and
y coordinate required two calls, you could have each call in a
separate construct: message. You could mix and match depending on what
slots the object has. At least that's what I'm guessing. I guess it's
slowly staring to make sense to me but it seems like it could be
overkill. The whole right column of (osWindow blah) is unused.

Also it looks like there is a case issue. They use #(MouseLeaveEvent
...) up there but then in the methods there is: 

event@(Event traits) construct: _@#mouseMotionPosition [...]

I can't find a _ at mouseLeaveEvent or _ at MouseLeaveEvent though.


maybe this whole file needs a makeover. I'll see if I have time to
come up with something now.