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

Kevin Reid kpreid at mac.com
Fri Aug 1 18:17:29 CDT 2008

On Aug 1, 2008, at 18:17, Tyler Close wrote:
> On Fri, Aug 1, 2008 at 9:11 AM, Kevin Reid <kpreid at mac.com> 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.

If so, it hasn't gotten into the repository trunk, though the new  
Causeway has. I searched for "org.ref_send" and found nothing outside  
of Causeway.

>> So Causeway now labels events in its tree by the first entry in their
>> trace?
> I think the last version I used did so.

I'm not sure this is a good idea.

It seems to me that, unless I explicitly twiddle the trace to support  
this usage, the top-of-stack on a Send is going to be message-queuing  
internals, and the top-of-stack on a Got is going to be generic  
message handling code (since the target hasn't been invoked yet),  
neither of which is going to be especially informative in an event list.

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

Only incomplete ones. MarkM?

"gettingCloser() promotes certain events from process order to virtual  
activation order. Virtual activation order is a DAG. "
-- http://www.erights.org/elang/tools/causeway/causeway-paper.pdf

"if ((countDown -= 1) <= 0) {
} else {
-- http://www.erights.org/elang/concurrency/race.html

"Has no visible effect; used by causality tracing. Claims that  
something happened such that this resolver is closer to getting  
-- docstring I just wrote for E-on-CL

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

Yes, this makes sense and I'm working on implementing it.

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

"This kind of event is produced for a when block. The Sent.message  
identifies the when block itself, and the condition identifies the  
promise the when block is queued on."

"This kind of event is produced for a send to a promise. The  
Sent.message identifies the queued message, and the condition  
identifies the promise the when block is queued on."

If, in ref_send, when is not implemented with promises, then use  
wording which covers both.

>> Forgot to ask further: are the ending column numbers inclusive or  
>> exclusive?
> I think I was assuming inclusive, but don't have any good reasons for
> doing so. What do other languages that support spans do?

In my experience, most languages, or compilers, only work with  
(single) line numbers; no column numbers or spans. Therefore you need  
to ask someone else.

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

According to <http://unicode.org/glossary/>, a "code unit" is "The  
minimal bit combination that can represent a unit of encoded text for  
processing or interchange. The Unicode Standard uses 8-bit code units  
in the UTF-8 encoding form, 16-bit code units in the UTF-16 encoding  
form, and 32-bit code units in the UTF-32 encoding form."

Therefore a code unit is encoding-dependent, and not something you  
should use for working with abstracted-from-encoding text.

Note that Java Strings and 'char's are in UTF-16 (because Java was  
designed before Unicode got wider than that); String#length() actually  
returns the length in UTF-16 code units. This is generally considered  
a flaw in Java, I believe.

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

I don't know. I would *expect* to find that, if they support Unicode  
enough that this distinction exists, they would count columns in terms  
of grapheme clusters, since that's what the cursor will move over and,  
insofar as monospace is possible, what fits in one monospaced column.


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

More information about the e-lang mailing list