Re: Causeway JSON format doc? (attn Tyler Close and Terry Stanley)

Hi Kevin,

On Fri, Aug 1, 2008 at 9:11 AM, Kevin Reid <[email protected]> wrote:
> On Aug 1, 2008, at 10:46, Tyler Close wrote:
>> This format is intended to be language neutral and is currently being
>> used in both Java and E.
>
> Er, how is it being used in E? If you mean Causeway: that's a viewer,
> not a source of events, and I'm speaking of how it fits the model of
> the event-loop systems.

Mark mentioned at one of the friam meetings that Terry had implemented
the new log format for E-on-Java.

> So Causeway now labels events in its tree by the first entry in their
> trace?

I think the last version I used did so.

>>>  * How do I express Resolver#gettingCloser?
>
> I don't see an answer to this question. I suppose it can be done by
> having another event type similar to Resolved, though.

Could you give me a reference to the meaning of the gettingCloser message?

> My understanding is that each message identifier has at most one Sent
> and one Got, so the forwarded-from-a-promise messages get new
> identifiers. Assuming this:
>
> To have it behave the way you describe will require me to create
> virtual turns for the forwardings, as the buffered messages are all
> sent toward the new target in the same turn (the turn in which
> Resolver#resolve is invoked) in E-on-CL and E-on-Java.

That sounds feasible.

So if a promise with GUID p1 has 3 queued messages with GUIDS: m1, m2,
m3, resolving p1 to promise p2 produces the events:

Resolved(p1 in turn 27)
Got(m1 in turn 28)
SentIf(m1f on p2 in turn 28)
Got(m2 in turn 29)
SentIf(m2f on p2 in turn 29)
Got(m3 in turn 30)
SentIf(m3f on p2 in turn 30)

This way, the turn identifier can be used to match up the forwarded
message with the original message.

>>> * When is nonprimitive -- exactly what stage is expected to generate
>>> SentIf events?
>>
>> A SentIf is generated by execution of a when, or an eventual send on a
>> promise. A Resolved is generated when the promise is resolved. A Got
>> is generated when the when block is executed, or the eventual send is
>> delivered.
>
> Okay, so the logic of 'when' need do nothing, since a SentIf will be
> generated by sending __whenMoreResolved to the promise. The class
> documentation http://waterken.sourceforge.net/javadoc/org/ref_send/log/SentIf.html
>  is misleading, then, as it mentions only when and not promises.

Could you be more specific about how the documentation should be improved?

>>>  * Zero or one-based column numbers?
>>
>> one-based
>
> Forgot to ask further: are the ending column numbers inclusive or
> exclusive?
>
> That is, given the line
>   "foo bar baz"
> of which the relevant part is "bar", is the span [[1,5],[1,7]] or
> [[1,5],[1,8]]?
>
> Note that E's SourceSpans are zero-indexed and like the former:
>
>   ? "foo bar baz".asFrom("").run(4,7).getOptSpan()
>   # value: <#:span::1:4::1:6>

I think I was assuming inclusive, but don't have any good reasons for
doing so. What do other languages that support spans do?

>>>  * Is the column counting scalar values or grapheme clusters?
>>
>> Unicode code points.
>
> This is a bad idea. Code points include surrogates, and as such, the
> count of code points depends on whether you are considering UTF-16 or
> some other encoding.

I think I didn't use the terminology correctly. Basically, I want the
unit to be the same as what Java calls a char, as I believe that's the
most widely used unit. I think the terminology here is "Unicode code
unit".

The only goal here is to be able to tell an IDE what part of the code
to highlight when an event is selected. Are there any dominant
assumptions among IDEs for how a code span is defined? Thanks for
demanding more precision here.

>>> Comments:
>>>
>>> * Have you considered using a log format that doesn't require a
>>> termination at the end of the file, i.e. "]"? This requirement means
>>> that a log file is invalid if a vat's implementation is shut down
>>> abnormally, and there must be code to wrap up the file explicitly.
>>
>> So don't use a single file. Use a separate file for each burst of
>> output.
>
> 1. Does Causeway support this mode of operation? I haven't run the
> latest version, but the one with the old log format displayed a tab
> per log file in the UI. This would become impractical with this many
> files involved.

The version of Causeway I last used could read in an arbitrary number
of input files and made no distinctions in the UI based on the number
of files used. There was one tab for each event loop, regardless of
the number of files the events came from.

--Tyler