[e-lang] Some minor patches

[Thomas Leonard]

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: [phone]

mailto:***@it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk/

[Kevin Reid]

Post by Thomas Leonard
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?

Post by Thomas Leonard
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.)

Post by Thomas Leonard
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.

[Thomas Leonard]

Post by Kevin Reid

Post by Thomas Leonard
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).
--
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: [phone]

mailto:***@it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk/

[Kevin Reid]

Post by Thomas Leonard

Post by Kevin Reid

Post by Thomas Leonard
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.
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 the same interface), so that it's closer to the UI layers and not baked into exception objects' protocol.

[Thomas Leonard]

Post by Thomas Leonard

Post by Kevin Reid

Post by Thomas Leonard
http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/e14b3b40363499712b93680c09d0a730e6b48271

Give a shorter stack-trace from ELoader if the source file is missing

Post by Thomas Leonard

Post by Kevin Reid
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.

but I agree colorizing is a reasonable improvement.

Post by Thomas Leonard
There's a patch on my "hacks" branch that colours the stack
http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/f3da8f91a5a4ce9aebb8d484780a98fde389de05

"." lines are highlighted in yellow and<file:...> references are

Post by Thomas Leonard
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 the same
interface), so that it's closer to the UI layers and not baked into
exception objects' protocol.

Also, I don't think Windows supports ANSI yet.

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).
--
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: [phone]

mailto:***@it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk/

[Kevin Reid]

Post by Thomas Leonard
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.

[Thomas Leonard]

Post by Kevin Reid

Post by Thomas Leonard
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: [phone]

mailto:***@it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk/