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

On Aug 1, 2008, at 10:46, Tyler Close wrote:
> On Fri, Aug 1, 2008 at 5:43 AM, Kevin Reid <[email protected]> wrote:
>> * Is this format intended to be usable by systems other than  
>> ref_send?
>> I had understood that the new Causeway format was, but this system
>> appears to be not very flexible in the matter of what information  
>> must
>> be available.
>
> 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.

> I don't understand your comment above. What flexibility has been lost?

I retract this claim.

>
>
>> * Where do I (as a log generator) put the *content* of the messages
>> (what object they are delivered to, what the verb and arguments are)?
>
> The verb is included in the stack trace. The other information is not
> used by the Causeway viewer. If you came up with a use for this
> information, you could add it to the format by extending the Sent
> class.

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

(Regarding extension: the current version of Causeway appears to be  
very strict about the content of the records it expects, not accepting  
extra fields or even ordering differences. I assume this is merely an  
incomplete implementation.)

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

>>  * How do I express the N causes of a buffered message? That is,
>> when a promise is resolved, each message delivered to its target has
>> at least two causes (in the original log format): the event(s) of the
>> original send, and the event of the resolution. I get the impression
>> that this is handled by SentIf and Resolved, but I don't see how this
>> can express the case of a promise resolved to another promise, in  
>> that
>> the Resolved event does not identify the new "condition".
>
> A message queued on a promise is represented as a SentIf, followed by
> a Resolved, followed by a Got.
>
> In ref_send, I am representing a promise resolved to another promise
> by a separate turn for each queued message on the resolved promise
> that does a SentIf on the resolved to promise. I suggest you do the
> same.

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.

Changing this to use a real queued turn per forwarded message would  
change the visible semantics of the event loop, as messages resulting  
from a promise resolution would be delayed by one cycle.


> Again, the Causeway viewer doesn't use any representation of object
> identity, which I suspect is causing you more confusion here.

No, I understand that; I'm trying to understand how this format  
manages *message* identities.


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

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

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

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

2. I ran my EoCL-with-causeway-tracing (which so far only generates an  
event per turn queued, and not separate Sent/Got events), on a simple  
updoc test case with two vats and six steps, which does hardly  
anything interesting. There are 90 events in the log. It seems to me  
that any nontrivial application to debug will have even more, to the  
point where storing each one separately in the filesystem is unwieldy  
(e.g. overflowing command-line length limitations, unnecessary time  
and space costs).

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>