[e-lang] Causeway JSON format doc? (attn Tyler Close and Terry Stanley)

[Kevin Reid]

On Aug 1, 2008, at 0:54, Tyler Close wrote:

> Hi Kevin,
>
> On Wed, Jul 30, 2008 at 7:07 PM, Kevin Reid <kpreid at mac.com> wrote:
>> Is there any specification of the latest Causeway JSON trace file
>> format? I've only found <http://waterken.sourceforge.net/debug/>,
>> which is non-exhaustive, and an older JSON format document sent to me
>> in e-mail.
>
> The log format is defined by the set of "data" classes at:
>
> <http://waterken.sourceforge.net/javadoc/org/ref_send/log/package-summary.html 
> >
>
> The org.waterken.syntax.json package defines a serialization from Java
> record classes to JSON. So the Causeway JSON trace file format is the
> serialization of any object tree you can compose from the classes
> linked to above.


OK. My further questions then are:

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

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

* I now see that the anchor.turn.number field is not the causing  
event, as I had assumed it was. Where do I put cause information, then?

I get the impression that it is constructed out of the association of  
Sent and Got events -- that is, Sent has the event in which the  
message was sent and Got is the event of its delivery -- but then:
   * How do I express Resolver#gettingCloser?
   * 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".

* When is nonprimitive -- exactly what stage is expected to generate  
SentIf events?

* Which promises are expected to generate Resolved events?

(I'm a little bit bothered by these last three questions -- it seems  
to me that the new log format requires a lot more information to be  
tracked by the implementation to fit its structure, while not  
providing much benefit in amount of useful information available to  
the debugger. I may well be just not seeing it yet.)

* http://waterken.sourceforge.net/javadoc/org/ref_send/log/ 
CallSite.html does not state how lines and columns are counted:
   * Zero or one-based column numbers?
   * Is the column counting scalar values or grapheme clusters?
   * What are considered line breaks?

* What is expected to be in the "name" field in a CallSite?

* What is the benefit of the Anchor.number field -- is it not implicit  
in the ordering of items in the log?

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.  
(For example, you could say that the log format is "{...}, {...}, ..."  
-- then it can be turned into JSON by wrapping it in "[" "null]".)

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