headers
Thomas Leonard | 2 Sep 2011 12:29
Picon
Favicon
Gravatar

Re: Some minor patches / E stack traces

On 2011-08-26 13:56, Kevin Reid wrote:
> On Aug 26, 2011, at 6:55, Thomas Leonard wrote:
>
>> On 2011-08-24 16:19, Kevin Reid wrote:
>>> On Aug 24, 2011, at 10:17, Thomas Leonard wrote:
>>>> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/e14b3b40363499712b93680c09d0a730e6b48271
>>>>
>>>>
Give a shorter stack-trace from ELoader if the source file is missing
>>>
>>> Is this really worth the additional complexity of the code?
>>
>> Maybe. I think that part of the problem is that E stack traces are
>> hard to read. There's a lot of information (which is useful), but
>> it's hard to scan by eye.
>
> Mm. I've always found the leading symbols ( <at>  . -) to be sufficient,
> but I agree colorizing is a reasonable improvement.
>
>> There's a patch on my "hacks" branch that colours the stack
>> traces:
>>
>> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/f3da8f91a5a4ce9aebb8d484780a98fde389de05
>>
>>
>>
"." lines are highlighted in yellow and<file:...>  references are
>> highlighted in green.
>>
>> So, if you want to know *what* calls were made (including values),
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Reid | 2 Sep 2011 13:46
Favicon
Gravatar

Re: Some minor patches / E stack traces

On Sep 2, 2011, at 6:29, Thomas Leonard wrote:

> Agree that highlighting should be separated from the exceptions, but
> I'm not sure the answerer is the best place - many stack traces come 
> from traceln(ex).

Under normal conditions, traceln goes to a file.

Ignoring that fact, I would say the TextWriter responsible for printing the exception object should in
this case be responsible for triggering highlighting -- I've been wanting for a while to generalize
TextWriter into producing other sorts of output. E-on-CL has a sketch of this - it's possible to plug into
TextWriter an object which changes the print syntax (though the output is plain text).

(Particularly, TextWriter has the invariant that printing an object does not grant its authority. I have
the notion to generalize to the name "Writer" (unfortunately a name conflict with Java, but it makes sense
inside of the E world) an object which has the same interface but may release authority. (Then the guard on a
__printOn method may be either TextWriter or Writer depending.) One use of such a facility would be a GUI
REPL -- permitting the user to select objects within a response and operate on them.)

So, the TextWriter(s) responsible for printing the argument to traceln should know that *if* trace output
is going to a console, they should provide color output.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 1 comment |
headers
Thomas Leonard | 2 Sep 2011 13:59
Picon
Favicon
Gravatar

Re: Some minor patches / E stack traces

On 2011-09-02 12:46, Kevin Reid wrote:
> On Sep 2, 2011, at 6:29, Thomas Leonard wrote:
>
>> Agree that highlighting should be separated from the exceptions, but
>> I'm not sure the answerer is the best place - many stack traces come
>> from traceln(ex).
>
> Under normal conditions, traceln goes to a file.

Not any more. It goes to java.util.logging (for E-on-Java anyway), which 
outputs to the console by default.

--

-- 
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK

tel: +44 23 8059 8866

mailto:tal@...
http://www.it-innovation.soton.ac.uk/
Permalink | Reply | 0 comments |
headers
Thomas Leonard | 8 Sep 2011 14:21
Picon
Favicon
Gravatar

Re: JSON / XML support in E

On 2010-02-22 15:42, Thomas Leonard wrote:
> On Sat, 2010-01-16 at 17:07 -0800, Mark Miller wrote:
>> On Fri, Jan 15, 2010 at 4:47 AM, Kevin Reid<kpreid@...>  wrote:
>>          On Jan 15, 2010, at 6:12, Thomas Leonard wrote:
>>          >  OK, I can create JSON documents easily enough using
>>          >
>>          >  def Term :=<type:org.quasiliteral.term.Term>
>>          >  def serialised := (testData :Term).asText()
>>          >
>>          >  This is nice and fast, and I assume it could produce XML in
>>          a
>>          >  similar way.
>>
>>
>>          Huh, I didn't know that worked except for leaf types. (I find
>>          that the
>>          relevant code is in
>>          org.erights.e.meta.org.quasiliteral.astro.AstroGuardSugar.)
>
>>
>>
>> Yes. The first test case at src/jsrc/org/quasiliteral/term/Term.updoc
>> is
>>
>>      ? [3=>4, "a"=>'x', [2,3]=>[4,5]]:Term
>>      # value: term`{3: 4,
>>      #              "a": 'x',
>>      #              [2, 3]:
>>      #                  [4, 5]}`
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin Reid | 8 Sep 2011 15:33
Favicon
Gravatar

Re: JSON / XML support in E

On Sep 8, 2011, at 8:21, Thomas Leonard wrote:
> On further investigation, it seems that newlines aren't allowed in JSON 
> strings anyway:
> 
> http://stackoverflow.com/questions/42068/how-do-i-handle-newlines-in-json
> 
> This patch turns newlines into "\n" sequences and doesn't quote "'" 
> (which JSON also doesn't allow):
> 
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/1b0a82891d305059c3732bc33b6702b41e944acf
> 
> I spotted these problems when trying to parse E's JSON output using 
> Python. The changes also fix <elib:serial.deJSONKit>.

Looks OK, but please audit other users of StringHelper to see if any need it the other way.

I would object to escaping newlines for the readability reduction, except that not doing so means that
pretty-printing indentation changes the content, which is a bug.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 1 comment |
headers
Thomas Leonard | 8 Sep 2011 16:13
Picon
Favicon
Gravatar

Re: JSON / XML support in E

On 2011-09-08 14:33, Kevin Reid wrote:
> On Sep 8, 2011, at 8:21, Thomas Leonard wrote:
>> On further investigation, it seems that newlines aren't allowed in JSON
>> strings anyway:
>>
>> http://stackoverflow.com/questions/42068/how-do-i-handle-newlines-in-json
>>
>> This patch turns newlines into "\n" sequences and doesn't quote "'"
>> (which JSON also doesn't allow):
>>
>> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/1b0a82891d305059c3732bc33b6702b41e944acf
>>
>> I spotted these problems when trying to parse E's JSON output using
>> Python. The changes also fix<elib:serial.deJSONKit>.
>
> Looks OK, but please audit other users of StringHelper to see if any need it the other way.
>
> I would object to escaping newlines for the readability reduction, except that not doing so means that
pretty-printing indentation changes the content, which is a bug.

Note that there are (now) two methods in StringHelper:

- quote is mostly as before, except it no longer escapes "'"
- the new quoteIncludingNewline method also quotes newlines

The change to "quote" isn't strictly necessary, but it seemed sensible 
and better than trying to explain why the two methods handled "'" 
differently.

This causes the following change:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Leonard | 19 Sep 2011 11:24
Picon
Favicon
Gravatar

Patch for review: don't report errors twice

Simple patch to fix E error reporting:

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/c9a58031350e65d0b721f9b865dba821327703ba

Without the patch exceptions get reported twice:

$ cat test.e
foo
$ rune test.e
# problem: Failed: Undefined variable: foo
#
#    <at>  </home/tal/tmp/test.e#:span::1:0::1:2>
#   - EExpr#evalToPair(Scope)
#   . e`foo`.evalToPair(<a Scope>)
#    <at>  evalToPair/1: 
<jar:file:/opt/src/e/dist/e.jar!/org/erights/e/elang/cmd/cmdMakerMaker.emaker#:span::128:57::128:66>

# problem: Failed: Undefined variable: foo
#
#    <at>  </home/tal/tmp/test.e#:span::1:0::1:2>
#   - EExpr#evalToPair(Scope)
#   . e`foo`.evalToPair(<a Scope>)
#    <at>  evalToPair/1: 
<jar:file:/opt/src/e/dist/e.jar!/org/erights/e/elang/cmd/cmdMakerMaker.emaker#:span::128:57::128:66>
#   - static Ref#fulfillment(Object)
#   . <makeRef>.fulfillment(<ref broken by problem: Failed: Undefined 
variable: foo>)
#    <at>  fulfillment/1

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Reid | 19 Sep 2011 13:05
Favicon
Gravatar

Re: Patch for review: don't report errors twice


On Sep 19, 2011, at 5:24, Thomas Leonard wrote:

> Simple patch to fix E error reporting:
> 
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/c9a58031350e65d0b721f9b865dba821327703ba
> 
> Without the patch exceptions get reported twice:

Good to have this fixed; looks reasonable, but please explain the rationale in the source code as well as the
commit message.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 0 comments |
headers
Thomas Leonard | 21 Sep 2011 15:37
Picon
Favicon
Gravatar

Patch for review: show updoc errors immediately

One problem I frequently hit with updoc is that it doesn't report errors 
until the script finishes. But, often, the error prevents the script 
from finishing. Then you have to bisect the script manually until you 
see the error.

As a simple test case, consider:

   ? def a
   ? bind a = 3
   ? interp.waitAtTop(a)
   ? a
   # value: 3

This script (which contains a syntax error on the second line), will 
silently hang:

$ rune demo.updoc

updoc: started

/tmp/demo.updoc:..
[ hangs ]

With this patch, it reports the error:

$ rune demo.updoc

updoc: started

/tmp/demo.updoc:...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Thomas Leonard | 26 Sep 2011 12:16
Picon
Favicon
Gravatar

Re: Patch for review: show updoc errors immediately

On 2011-09-21 14:37, Thomas Leonard wrote:
> One problem I frequently hit with updoc is that it doesn't report errors
> until the script finishes. But, often, the error prevents the script
> from finishing. Then you have to bisect the script manually until you
> see the error.
[...]

> Patch:
>
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/dca612f2a472451881c00ea02e290a398a92b22e

Any objections to me committing this today?

--

-- 
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK

tel: +44 23 8059 8866

mailto:tal@...
http://www.it-innovation.soton.ac.uk/
Permalink | Reply | 3 comments |

Gmane