Re: Causeway JSON format doc? (attn Tyler Close and Terry Stanley)
"Tyler Close" <[email protected]>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 1, 2008 at 4:17 PM, Kevin Reid <[email protected]> wrote: > On Aug 1, 2008, at 18:17, Tyler Close wrote: >> On Fri, Aug 1, 2008 at 9:11 AM, Kevin Reid <[email protected]> wrote: >>> 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. In the Waterken Server implementation, I twiddle the trace to remove all the infrastructure code, leaving only the application code. I think this makes the trace much more usable for application developers. For example, see the sample traces at: http://waterken.sourceforge.net/debug/#log_format You'll notice there's no extra cruft in there beyond the application code. >> Could you be more specific about how the documentation should be >> improved? > > Replace: > "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." > > with: > "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." Thanks, I've committed these changes to the repository. >> 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. So, the dominant IDEs are: Visual Studio, Eclipse, IntelliJ IDEA and NetBeans. I think the last three, being implemented in Java, probably use the Java char definition of a column. I'd expect Visual Studio to use the definition of wchar_t, which is also a 16 bit unit that I think is the same as a Java char. Barring new information, I think we should decree that a column is a UTF-16 code unit. --Tyler