Re: E patches for review: ELoader, Scope.with, seedVat

Mark Miller <[email protected]>
Newsgroups gmane.comp.lang.e.general
Message-ID <[email protected]>
On Thu, May 20, 2010 at 6:44 AM, Thomas Leonard <
tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]> wrote:

> "Uncalling ReadOnlyFile objects" is now committed. I ducked the issue of
> changing the public protocol for file objects by making isDeepReadOnly
> package-level for now.
>

Thanks.


>
>
> Next up:
>
> "Load resources using E's classloader, not the system one"
>
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/f62d40e241020deec8f3c856edfde15a017c967c<http://gitorious.org/%7Etal-itinnov/repo-roscidus/it-innovation/commit/f62d40e241020deec8f3c856edfde15a017c967c>
>
> E tries to load various resources (e.g. "ParserTables.data") using the
> system classloader. This doesn't work if E has been deployed in a
> container with its own classloader (e.g. we use it in a JBI binding
> component to map between CapTP and SOAP).
>

Looks good.



>
> "Added Scope.with(ConstMap)"
>
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/25e640051591682361a1e28dd22338cb662a1ebd<http://gitorious.org/%7Etal-itinnov/repo-roscidus/it-innovation/commit/25e640051591682361a1e28dd22338cb662a1ebd>
>
> Convenience method. I'm thinking of adding EExpr.eval(ConstMap) too,
> with the eventual goal of turning safeScope into a normal map. I think
> someone (MarkM?) mentioned that E programs should see scopes as simple
> maps, rather than being given the low-level Scope object, which is an
> implementation detail of the interpreter?
>


This change by itself looks good. However, regarding "EExpr.eval(ConstMap)",
what about the fqnPrefix?


>
>
>
> For discussion:
>
> Can I remove ESecureRandom? "This class provides a cryptographically
> strong random number generator based on user provided sources of entropy
> and the MD5 hash algorithm." I'm guessing that the normal Java version
> is pretty good these days - is there any reason why E needs its own
> one?
>
> My particular reason for wanting to remove it is that the Java version
> lets you request a lower-security configuration that's much faster for
> testing, and I worry that the crypto stuff in E isn't actively
> maintained.
>

I remember this came up at Electric Communities. Bill (cc'ed) did
ESecureRandom. ESecureRandom wouldn't provide random bits until it could
provide good ones. This led to longer startup times, which was frustrating
during our rapid development cycle. Bill was repeatedly asked "We don't need
high quality randomness during development. Can't you just give us a switch
so that we can turn this off during development?" IIRC, Bill refused to
provide a switch until we could build a development process that could
ensure that this switch wouldn't accidentally be left on in the shipping
product.

Whether I remember this accurately or not (Bill?), it has become one of my
favorite stories about the proper attitude to security during software
development.

Are there any remaining vestiges of this switch? What was the means of
ensuring that this switch was not left on in the shipping product? Although
I love the story, I never did become familiar with the specifics.



>
>
> Finally, I'd like to add an extra argument to seedVat.run that is a map
> of additional bindings for the new vat's environment. This is so that
> you can create a new vat with the same module configuration as the
> current one, e.g.
>
>  seedVat(newVat, privSrc, <this>.getEnvExtras())
>
> It uses the persistence sealer to serialize and unserialise the map,
> which seems necessary because a loader has a reference to makeTraceln,
> which is unsafe. Is this the best way to do it?
>

This seems plausible.



>
>
> --
> 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
>
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>



-- 
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.