[e-lang] Causeway JSON format doc? (attn Tyler Close and Terry Stanley)
kpreid at mac.com
Fri Aug 1 11:11:12 CDT 2008
On Aug 1, 2008, at 10:46, Tyler Close wrote:
> On Fri, Aug 1, 2008 at 5:43 AM, Kevin Reid <kpreid at mac.com> wrote:
>> * Is this format intended to be usable by systems other than
>> I had understood that the new Causeway format was, but this system
>> appears to be not very flexible in the matter of what information
>> 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
So Causeway now labels events in its tree by the first entry in their
(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
>> * 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
>> 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
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
Okay, so the logic of 'when' need do nothing, since a SentIf will be
generated by sending __whenMoreResolved to the promise. The class
is misleading, then, as it mentions only when and not promises.
>> * Zero or one-based column numbers?
Forgot to ask further: are the ending column numbers inclusive or
That is, given the line
"foo bar baz"
of which the relevant part is "bar", is the span [[1,5],[1,7]] or
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.
>> * 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
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
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/>
More information about the e-lang