headers
Thomas Leonard | 24 Aug 2011 16:17
Picon
Favicon
Gravatar

Some minor patches

Some minor fixes I've been using for a while:

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/e14b3b40363499712b93680c09d0a730e6b48271
Give a shorter stack-trace from ELoader if the source file is missing

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/e1882154ea24f349187422305aaf99dea0c4825f
Added ReadOnlyFile.getCryptoHash()
This allows passing read-only files to updoc.

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/c41603af25758f2d9d0f33474211c7df5a89abbc
Clearer error message when a return value fails its guard
The message is now prefixed by "Bad return value: "

OK to commit?

--

-- 
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 |
headers
Kevin Reid | 24 Aug 2011 17:19
Favicon
Gravatar

Re: Some minor patches

On Aug 24, 2011, at 10:17, Thomas Leonard wrote:

> Some minor fixes I've been using for a while:
> 
> 
> 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?

> 
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/e1882154ea24f349187422305aaf99dea0c4825f
> Added ReadOnlyFile.getCryptoHash()
> This allows passing read-only files to updoc.

Good. This should exist.

Perhaps FileSugar should rethrow NoSuchAlgorithmException as runtime; we aren't expecting that
failure. (On the other hand, E doesn't care.)

> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/c41603af25758f2d9d0f33474211c7df5a89abbc
> Clearer error message when a return value fails its guard
> The message is now prefixed by "Bad return value: "

OK. This feels a little unclean, but it's probably not worth thinking about until we have a general plan for
Exceptions In E.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
(Continue reading)

Permalink | Reply |
headers
Thomas Leonard | 26 Aug 2011 12:55
Picon
Favicon
Gravatar

Re: Some minor patches / E stack traces

On 2011-08-24 16:19, Kevin Reid wrote:
> On Aug 24, 2011, at 10:17, Thomas Leonard wrote:
>
>> Some minor fixes I've been using for a while:
>>
>>
>> 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.

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), just 
look at the yellow lines. If you want to to know the *types* involved, 
look at the white text, and if you want to see source locations, look 
for green text.

Seems to help a bit (but assumes output is to an ANSI terminal).

--

--
(Continue reading)

Permalink | Reply |
headers
Kevin Reid | 26 Aug 2011 14:56
Favicon
Gravatar

Re: Some minor patches / E stack traces

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), just 
> look at the yellow lines. If you want to to know the *types* involved, 
> look at the white text, and if you want to see source locations, look 
> for green text.

This seems not-unreasonable (even assuming ANSI, as it is the de facto standard), except for the part where
we don't have information about whether the output is *to* a terminal. I would rather see this as a
syntax-highlighter stage optionally provided by elang.cmd.makeAnswerer (or a different object with
(Continue reading)

Permalink | Reply |
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 |
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 |
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 |

Gmane