Trouble getting slate gui started from instructions

[Brian Rice]

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!

> 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).

> 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).

> 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?

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060411/dac460ac/PGP.pgp