headers
Thomas Leonard | 2 Jun 2010 13:37
Picon
Favicon
Gravatar

Re: E patches for review: ELoader

Here are some cleaned-up patches for adding ELoader. There are four in 
the series (on my "proposed" branch):

http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commits/proposed

They are:

"Added <elang:interp.ELoaderAuthor>"
http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/1c03d05489a596a474bd87d3ccdb6deee7819714

"Added seedVat/3 to give envExtras to the new vat"
http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/fcfa012324148163edc33f7a34a6de0f64d74d66

"When running (unconfined) code with rune, give it a <this> loader by
default"
http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/6e8e15eaf64d423d749bf66ce37533ec44e50854

"Set <this> loader when running updoc scripts"
http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/2f18c1519028a755f0fe6c1349ae914961ff2066

I agree with Kevin that a full module system needs more than this. In
particular, the ability to have public and private APIs for modules.
However, I think this would build on these patches rather than replace
them.

The code above never connects modules together itself; it just gives a
single <this> loader to .e and .updoc scripts. Programs wanting to use
multiple modules (e.g. my prototype) make a loader for each module and
connect them themselves. They can choose whether to give a module its
dependency's <this> loader directly, or some restricted facet of it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Leonard | 2 Jun 2010 17:53
Picon
Favicon
Gravatar

Re: E updated with new Causeway

I probably won't have any time to work on this. One question though from
a quick look: where does the message ID come from?

On Mon, 2010-05-24 at 08:03 -0700, Terry Stanley wrote:
> Hi Thomas,
> 
> The pages at <http://wiki.erights.org/wiki/Causeway> and
> <http://wiki.erights.org/wiki/Causeway_Platform_Developer> are still
> rough and incomplete, but should help get you started. Please let me
> know of any questions you have.
> 
>   --Terry
> 
> 
> On Fri, May 21, 2010 at 9:05 AM, Terry Stanley <cocoonfx@...> wrote:
> > Hello Thomas,
> >
> > This weekend I expect to update the erights wiki with experience to
> > date instrumenting platforms to generate Causeway's trace logs.
> > Recently Tyler Close & Tom Van Cutsem and I discussed their
> > experiences with Waterken & AmbientTalk (respectively). The wiki will
> > be a good place for you to start to get an idea of what's involved. It
> > will include examples of the set of events that describe promise
> > behavior (Waterken & AmbientTalk generate different events),
> > difficulties of capturing stack traces, performance considerations,
> > and so on.
> >
> > Initially, Causeway worked only with E-on-Java and we had an ad-hoc
> > trace log format. Subsequently, Tyler defined the current
> > language-neutral json format. We expected to have E generate the new
(Continue reading)

Permalink | Reply | 8 comments |
headers
Tyler Close | 2 Jun 2010 18:49
Picon

Re: E updated with new Causeway

The message sender generates a GUID for the message. It's unspecified
how the sender and receiver coordinate the message identifier. The
Waterken Server identifies an inter-vat message by a GUID for the
vat-to-vat connection and a message serial number. The connection GUID
is the hash of the connection key. The connection key and the message
serial number are transmitted along with the message content itself
for all messages, regardless of whether or not Causeway logging is
enabled. The same identifiers are also used to ensure at-most-once
message delivery. For intra-vat messages, the Waterken Server uses a
different algorithm.

--Tyler

On Wed, Jun 2, 2010 at 8:53 AM, Thomas Leonard
<tal@...> wrote:
> I probably won't have any time to work on this. One question though from
> a quick look: where does the message ID come from?
>
>
> On Mon, 2010-05-24 at 08:03 -0700, Terry Stanley wrote:
>> Hi Thomas,
>>
>> The pages at <http://wiki.erights.org/wiki/Causeway> and
>> <http://wiki.erights.org/wiki/Causeway_Platform_Developer> are still
>> rough and incomplete, but should help get you started. Please let me
>> know of any questions you have.
>>
>>   --Terry
>>
>>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Thomas Leonard | 4 Jun 2010 17:38
Picon
Favicon
Gravatar

Re: E patches for review: ELoader, seedVat

On Mon, 2010-05-24 at 09:50 -0400, Kevin Reid wrote:
[...]
> Ah. Your question is not 'how to uncall makeTraceln' but 'how to  
> uncall the loader'. And the answer is to use 'something else'.
> 
> Since makeELoader gives authority to log with arbitrary prefixes, it  
> should not be exposed: so loader objects, i.e. <this> must not use  
> __optUncall but rather some amplifier.
> 
> The role to be filled  loader/uncaller pair which gives access to  
> "process authorities" such as makeTraceln and <file> objects, allowing  
> them to be passed between vats... but shouldn't the usual set,  
> [<unsafe>, <file>, ...] suffice for that? Maybe we need something  
> extensible in that set (i.e. an unsealer amplifier with a public  
> sealer) so that your ELoaders can be uncalled by that?

Is it possible to use sealers with PassByCopy objects? There are a
number of objects (e.g. <file:...>, ELoaders) that could be pass-by-copy
over boot-comm (but pass-by-proxy over CapTP) but would need to use
__optSealedDispatch.

--

-- 
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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Reid | 4 Jun 2010 17:59
Favicon
Gravatar

Re: E patches for review: ELoader, seedVat

On Jun 4, 2010, at 8:38, Thomas Leonard wrote:
> On Mon, 2010-05-24 at 09:50 -0400, Kevin Reid wrote:
> [...]
>> Ah. Your question is not 'how to uncall makeTraceln' but 'how to
>> uncall the loader'. And the answer is to use 'something else'.
>>
>> Since makeELoader gives authority to log with arbitrary prefixes, it
>> should not be exposed: so loader objects, i.e. <this> must not use
>> __optUncall but rather some amplifier.
>>
>> The role to be filled  loader/uncaller pair which gives access to
>> "process authorities" such as makeTraceln and <file> objects,  
>> allowing
>> them to be passed between vats... but shouldn't the usual set,
>> [<unsafe>, <file>, ...] suffice for that? Maybe we need something
>> extensible in that set (i.e. an unsealer amplifier with a public
>> sealer) so that your ELoaders can be uncalled by that?
>
> Is it possible to use sealers with PassByCopy objects? There are a
> number of objects (e.g. <file:...>, ELoaders) that could be pass-by- 
> copy
> over boot-comm (but pass-by-proxy over CapTP) but would need to use
> __optSealedDispatch.

The notion of PassByConstruction is defined in terms of "should this  
behave this way *over the standard CapTP*". PassByCopy is just the  
additional restriction that the object is Selfless such that a  
roundtrip gets you the original object as defined by Equalizer.

There is no reason for these objects not to pass over boot-comm in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Leonard | 7 Jun 2010 17:44
Picon
Favicon
Gravatar

Re: E patches for review: ELoader

I've committed this now. I also added persistenceSealer to safeScope, as
suggested in
http://www.eros-os.org/pipermail/e-lang/2009-September/013279.html

I'll update the documentation on the wiki once a version with this in
has been released.

On Wed, 2010-06-02 at 12:37 +0100, Thomas Leonard wrote:
> Here are some cleaned-up patches for adding ELoader. There are four in 
> the series (on my "proposed" branch):
> 
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commits/proposed
> 
> 
> They are:
> 
> "Added <elang:interp.ELoaderAuthor>"
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/1c03d05489a596a474bd87d3ccdb6deee7819714
> 
> "Added seedVat/3 to give envExtras to the new vat"
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/fcfa012324148163edc33f7a34a6de0f64d74d66
> 
> "When running (unconfined) code with rune, give it a <this> loader by
> default"
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/6e8e15eaf64d423d749bf66ce37533ec44e50854
> 
> "Set <this> loader when running updoc scripts"
> http://gitorious.org/~tal-itinnov/repo-roscidus/it-innovation/commit/2f18c1519028a755f0fe6c1349ae914961ff2066
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 20 Jun 2010 17:16
Picon
Gravatar

New paper: Class Properties for Security Review in an Object-Capability Subset of Java (Short Paper)

New paper: http://www.cs.berkeley.edu/~amettler/joeetypes-plas10.pdf

Class Properties for Security Review in an Object-Capability Subset of Java (Short Paper)

By Adrian Mettler & David Wagner

just presented at PLAS 2010. Congrats Adrian & David, looks like a really good paper!

Joe-E is a subset of the Java language, with additional restrictions
enforced by a static source-code verifier. We explore several se-
mantic properties of classes relating to immutability and object
identity that can be declared by the programmer and are checked
by the Joe-E verifier. We present the simple, modular analyses we
use to verify these properties and describe how they are useful in
performing security reviews of applications.


--

   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 0 comments |
headers
Thomas Leonard | 22 Jun 2010 14:34
Picon
Favicon
Gravatar

IPv6 addresses

E doesn't work with IPv6 addresses. Here's a patch:

http://gitorious.org/repo-roscidus/it-innovation/commit/5cda14106e59be94cda1aa013ee6422458025768

This also adds "[]" to the list of acceptable URI characters.

By the way, I found this surprising:

$ ls
a|b

$ rune
? <file:a|b>.getText()
# problem: <FileNotFoundException: .../a:b (No such file or directory)>

? <file>["a|b"].getText()
# problem: <FileNotFoundException: .../a:b (No such file or directory)>

? for name in <file:.>.list() { println(<file>[name].getText()) }
# problem: <FileNotFoundException: .../a/a:b (No such file or directory)>

Why does it do that?

--

-- 
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@...
http://www.it-innovation.soton.ac.uk
Permalink | Reply | 8 comments |
headers
Mark S. Miller | 22 Jun 2010 17:49
Picon
Favicon

Re: IPv6 addresses

On Tue, Jun 22, 2010 at 5:34 AM, Thomas Leonard <tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/VHan8Is@public.gmane.org> wrote:

E doesn't work with IPv6 addresses. Here's a patch:

http://gitorious.org/repo-roscidus/it-innovation/commit/5cda14106e59be94cda1aa013ee6422458025768

This also adds "[]" to the list of acceptable URI characters.

Hi Thomas, I notice that this patch refers to RFC 2732 for the new IPv6 friendly URI syntax. Web searching, I find <http://tools.ietf.org/html/rfc3986> claims it obsoletes RFC 2732. I have no idea if there are any relevant differences. I've never looked at either of these RFCs before. Any idea what this is about?

 

By the way, I found this surprising:

$ ls
a|b

$ rune
? <file:a|b>.getText()
# problem: <FileNotFoundException: .../a:b (No such file or directory)>

? <file>["a|b"].getText()
# problem: <FileNotFoundException: .../a:b (No such file or directory)>

? for name in <file:.>.list() { println(<file>[name].getText()) }
# problem: <FileNotFoundException: .../a/a:b (No such file or directory)>

Why does it do that?

IIRC, it was a misguided attempt on my part to be compatible with some stupid IE6 file: URL behavior. Please feel free to fix. Thanks.

 


--
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 <at> it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk

_______________________________________________
e-lang mailing list
e-lang-r2jiIPW7MOYEUp5O9OQuKg@public.gmane.org
http://www.eros-os.org/mailman/listinfo/e-lang



--
   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Permalink | Reply | 6 comments |
headers
Kevin Reid | 22 Jun 2010 18:51
Favicon
Gravatar

Re: IPv6 addresses

On Jun 22, 2010, at 5:34, Thomas Leonard wrote:

> E doesn't work with IPv6 addresses. Here's a patch:
>
> http://gitorious.org/repo-roscidus/it-innovation/commit/5cda14106e59be94cda1aa013ee6422458025768
>
> This also adds "[]" to the list of acceptable URI characters.

Looks plausible to me; go ahead and commit, but only after adding some  
(updoc) unit tests for the parsing and printing.

> By the way, I found this surprising:
>
> $ ls
> a|b
>
> $ rune
> ? <file:a|b>.getText()
> # problem: <FileNotFoundException: .../a:b (No such file or  
> directory)>
>
> ? <file>["a|b"].getText()
> # problem: <FileNotFoundException: .../a:b (No such file or  
> directory)>
>
> ? for name in <file:.>.list() { println(<file>[name].getText()) }
> # problem: <FileNotFoundException: .../a/a:b (No such file or  
> directory)>
>
> Why does it do that?

Poorly-thought-out Windows compatibility. "|" is the conventional  
(including outside of E, IIRC) way to use a Windows drive letter in a  
URL without making it look like a URL scheme. There is also a rule  
such that <c:foo> (where c is any single letter) is actually  
<file:c:foo>.

I haven't looked into the issues here (e.g. whether removing this  
would break E on Windows) so I have no recommendations at the moment.

MarkM and I are of the opinion that it would be not a bad idea to make  
separate FileGetters (or whatever they would be called) for "the root  
of the filesystem" and "the current directory", since they are  
different sorts of authority. I've thought about making <file> stick  
to file-URL syntax (including %20s) since it's nominally and  
syntactically a URL; combining these two, there would then be a third  
object for "interpret platform filename syntax" including Windows  
drive letters, unescaped spaces, and relative paths.

--

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>
Permalink | Reply | 0 comments |

Gmane