Re: Various E patches

On Tue, 2010-04-13 at 07:32 -0400, Kevin Reid wrote:
> On Apr 13, 2010, at 7:10, Thomas Leonard wrote:
> 
> > I'll commit the next set of patches on the proposed branch on  
> > Wednesday.
> > They are:
> >
> > http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commits/proposed
> 
> I haven't had time to review even your previous Wednesday commits.  
> I'll give my comments just on the descriptions:
> 
> > * Preserve source information about the collection used in a for
> > expansion
> 
> If this is just propagation of SourceSpans from one node to another,  
> good.

Yes:

$ 0launch --before=0.9.2-post2 http://repo.roscidus.com/e/e-core
? def a; for x in a {}
# problem: Failed: not synchronously callable
#   @ iterate/1

$ 0launch --not-before=0.9.2-post2 http://repo.roscidus.com/e/e-core
? def a; for x in a {}
# problem: Failed: not synchronously callable
#   @ iterate/1: <-.e#:blob::1:16::1:16>

> > * Added SQL quasi-parser
> 
> I am uncomfortable with this; I think we should start using separate  
> libraries (as by your eloader or my e-modules (and we need to discuss  
> the design principles for that)) rather than packing everything for  
> every purpose into the builtin namespace. In particular, SQL isn't a  
> lots-of-applications-use-it-so-it's-useful-to-bundle thing.

I'd certainly like to see less unrelated stuff in the E repository (e.g.
we have csrc/enative, jsrc/org/waterken, etc).

On the other hand, it seems a bit silly to split out 118 lines of code
into a separate module, and access to a database is pretty vital for
most applications, I would have thought (though I don't know what other
things E is being used for). Anything that needs persistence with
reasonable performance is likely to need it, at least.

My two main concerns are:

* Having some "official" SQL API, so people don't write their own
because they didn't find the existing one (e.g. as happened with the
module system).

* Providing a way for Windows users to install easily, given that
Windows doesn't seem to have a mechanism for handling dependencies
automatically. Though maybe this isn't an issue, as we'd have to bundle
E itself with any application for Windows anyway.

> > * Fix optimisation of simple return statements
> 
> What was broken?

The escape didn't get optimised out, so every method return becomes a
thrown-and-caught exception, leading to the performance issues I
mentioned previously ("to vs method").

> > * Share a single SafeScope within each vat
> 
> This sounds like the right thing. Where is it stored?

Each ImportLoader creates and stores one (since there's already one
ImportLoader per thread, and it's the thing that uses it).

> > * Removed unnecessary synchronized on LazyEvalSlot
> 
> Good.
> 
> > * In "not synchronously callable" error, give the verb
> 
> E-on-CL generates "not synchronously callable: rec.verb(args...)" for  
> the message. The implementations shouldn't be gratuitously different  
> in this regard. Do you have a rationale for not printing the other  
> components?

Just the general issue of error messages leaking information. I'm a bit
concerned about ex.eStack() showing the arguments too, though it's
certainly useful.


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk