Kevin Reid | 7 Oct 14:49 2008
Picon

Re: Sending files with E?

On Sep 29, 2008, at 5:06, Toby Murray wrote:

> There probably is an easier way. Your solution is functionally  
> correct,
> but it is certainly not the most efficient way to stream a file.
>
> Kevin Reid has a new E IO library that might address this sort of  
> thing,
> but I'm yet to look at it. Kevin, any thoughts here?

All my work so far addresses basic stream objects and OS-level IO  
(files, pipes and sockets) -- I haven't started on the problem of  
efficiently streaming data over a CapTP connection.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Bill Frantz | 7 Oct 21:30 2008

Re: Sending files with E?

kpreid@... (Kevin Reid) on Tuesday, October 7, 2008 wrote:

>All my work so far addresses basic stream objects and OS-level IO  
>(files, pipes and sockets) -- I haven't started on the problem of  
>efficiently streaming data over a CapTP connection.

It seems to me that any streaming of data over CapTP connections
will run into the flow-control problem. Flow control is currently
left as an application issue.

We have the E-on-Java example where a vat receives all messages
promptly and queues them on the vat queue. This technique fails
when too many messages are sent and the vat queue runs out of
storage.

The Waterken protocol offers another approach, where the messages
are queued in the sender. Flow-control can be applied by stopping
the sending vat, but a "stuck" vat can still cascade into many
stuck vats.

I have always considered the problem of a program that wants to
invoke a remote object, once for each member of some collection
class, to be the canonical problem. The naive way of implementing
this algorithm is to use an interator on the class, and for each
member send an eventual message to the remote object. For a large
collection class, this algorithm will overflow the memory for the
receiving vat.

A naive approach to application-level flow-control is to hold off
sending the second message until the remote vat has responded to
(Continue reading)

"Marcelo D. Ré" | 8 Oct 14:58 2008
Picon

Re: AST view of E program

Kevin Reid escribió:
On Sep 29, 2008, at 7:49, Marcelo D. Ré wrote:
I am working in a module to support E in NetBeans. Currently it sopport code highlight, braces completion, run e from the ide, and are developping the syntax check. The question is: how to grab an AST from an E file? is it posible?
def makeEParser := <import:org.erights.e.elang.syntax.makeEParser> makeEParser.run(theFile.getTwine()) The result of this is an AST of type ENode. All of this can be accessed from Java too. There is one caveat: in E-on-Java, there is no reified AST for un- expanded E syntax, only for Kernel-E. This may be sufficient, particularly as, provided that the source is a Twine (not a String), every ENode carries the line and column number of the source text corresponding to it (getOptSpan). If it isn't, you can supply your own EBuilder (or is it ENodeBuilder? One's a class and the other's an interface) to EParser and get messages corresponding to the full syntax. Another option is to use the grammar from E-on-CL, which is actually written in Java (generated by ANTLR), which provides an unexpanded AST.
I have problem parsing the line match [] { println(uri) } in the counter-example.e. I don't find a clause that parse the "println" statement.
This is an ordinary function call. The Kernel-E AST for this is EMatcher ListPattern (no children) CallExpr NounExpr "println" "run" NounExpr "uri" The unexpanded AST for this in E-on-CL is EMatcher ListPattern (no children) FunCallExpr NounExpr "println" NounExpr "uri"
Hi

    I have problem to print the AST. I couldn't find the way to do this. Where is the class or method makeEParse? I didn't find it in the JavaDoc (http://www.erights.org/javadoc/index.html) son I could modify the program to print the AST.
    I try diferent ways but could not get it work. Could somebody help me? I need a program that print the on console AST view of a source.
    I have most of the syntax check working in my plugin but currently have a problem parsing the expresion:

    def x4k3 := (x10 * 4).keep(3)
   
    of the diceIt.e

    Thank

       Marcelo



_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang
Dominique Quatravaux | 10 Oct 18:12 2008
Picon

Clueless with Joe-E and Eclipse

Apologies if this is not the right place to ask. I'm trying to use
Joe-E and know nothing about Eclipse (it's like the second time I run
it). I followed the instructions at
http://code.google.com/p/joe-e/wiki/GettingStarted up to the point
where the plug-in is downloaded and Eclipse restarts, and then...
Nothing. There is no Joe-E pane in the Eclipse preferences, and no way
to "enable Joe-E verifier" in projects regardless of the CLASSPATH
settings.

I'd be happy with a solution that involves running the verifier
directly (as an Ant task or shell command), as I'm more of an Emacs
guy anyway. I hereby promise to add documentation into the Joe-E wiki
if appropriate.

I'm using Eclipse 3.4.1 (Build id: M20080911-1700) under Mac OS X for
Intel version 10.5.5 (9F33). Any help greatly appreciated.

--

-- 
  Dominique Quatravaux
  +41 79 609 40 72
Adrian Mettler | 11 Oct 01:31 2008
Picon

Re: Clueless with Joe-E and Eclipse

Thanks for your interest in Joe-E!

Mostly for silly reasons, the release on the website is not compatible 
with Eclipse 3.4.  (It's manifest file declares dependencies on other 
plugins that it doesn't actually depend on, and which no longer exist in 
  Eclipse 3.4; these have been removed in svn.)  There are also a few 
things that don't work quite right with 3.4 which still need to be fixed.
For the time being, you can:
- use the most recent release version with Eclipse 3.3
- hack it to load on Eclipse 3.4 by removing the bogus dependencies (but 
you may encounter 3.4-specific bugs).  I can send you a version with the 
modifed manifest if you like.
- wait a few more days

I am planning to release a new version very soon (which will also 
include a command-line verification option) once I fix the bugs that 
cause unit tests to fail with 3.4.
-Adrian

Dominique Quatravaux wrote:
> Apologies if this is not the right place to ask. I'm trying to use
> Joe-E and know nothing about Eclipse (it's like the second time I run
> it). I followed the instructions at
> http://code.google.com/p/joe-e/wiki/GettingStarted up to the point
> where the plug-in is downloaded and Eclipse restarts, and then...
> Nothing. There is no Joe-E pane in the Eclipse preferences, and no way
> to "enable Joe-E verifier" in projects regardless of the CLASSPATH
> settings.
> 
> I'd be happy with a solution that involves running the verifier
> directly (as an Ant task or shell command), as I'm more of an Emacs
> guy anyway. I hereby promise to add documentation into the Joe-E wiki
> if appropriate.
> 
> I'm using Eclipse 3.4.1 (Build id: M20080911-1700) under Mac OS X for
> Intel version 10.5.5 (9F33). Any help greatly appreciated.
> 
Kevin Reid | 11 Oct 14:19 2008
Picon

Re: AST view of E program

On Oct 8, 2008, at 8:58, Marcelo D. Ré wrote:

>     I have problem to print the AST. I couldn't find the way to do  
> this. Where is the class or method makeEParse?

All Java classes are presented in E named as "makeX". The actual class  
name is org.erights.e.elang.syntax.EParser.

> I didn't find it in the JavaDoc (http://www.erights.org/javadoc/index.html 
> )

This is the method you want, for basic
usage:

<http://www.erights.org/javadoc/org/erights/e/elang/syntax/EParser.html#run(org.erights.e.elib.tables.Twine) 
 >

> I need a program that print the on console AST view of a source.

There is no one true syntax for the AST besides normal Kernel-E  
syntax, but you can get a TermL form using a converter that's available:

? def convert := <elang:visitors.makeConvertENode2Term>()
# value: <convert>

? convert(e`def x4k3 := (x10 * 4).keep(3)`)
# value: term`def(finalP("x4k3"),
#                 call(call(noun("x10"),
#                           "multiply",
#                           [quote(4)]),
#                      "keep",
#                      [quote(3)]))`

If you must have this from Java, then provided that an E vat is  
already set up you can do this:

import org.erights.e.elib.tables.Twine;
import org.erights.e.elib.prim.E;
import org.erights.e.elang.syntax.EParser;
import org.erights.e.elang.evm.ENode;
import org.erights.e.elib.serial.Loader;

Object converter =
   E.call((Loader)(safeScope.get("import__uriGetter"))
            .get("org.erights.e.elang.visitors.makeConvertENode2Term"),
          "run");

ENode node = EParser.run(Twine.fromString(source_text, source_url));
System.out.print(E.call(converter, "run", node));

But really, I expect that a reasonably efficient IDE-support module  
would want to walk the ENode tree directly, not print it in any syntax.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Kevin Reid | 11 Oct 15:26 2008
Picon

Re: Sending files with E?

On Oct 7, 2008, at 15:30, Bill Frantz wrote:
> kpreid@... (Kevin Reid) on Tuesday, October 7, 2008 wrote:
>
>> All my work so far addresses basic stream objects and OS-level IO
>> (files, pipes and sockets) -- I haven't started on the problem of
>> efficiently streaming data over a CapTP connection.
>
> It seems to me that any streaming of data over CapTP connections
> will run into the flow-control problem. Flow control is currently
> left as an application issue.

I propose this classification of solutions:

1. Set up a separate OS/network level connection, and make use of its  
flow control rather than hiding it.

(Hm: This is an application for VatTP without CapTP, no?)

This would work fine for data, and could be made reasonably  
transparent in the EIO subsystem, I think, but gets tricky if you want  
to transport caps/objects over the flow-controlled stream, as you have  
to have some kind of interconnection with the primary CapTP stream.

2. Provide a way for (authorized) applications to see the flow  
information that is being hidden by CapTP (due to its ordering and non- 
blocking guarantees).

For example, getting reports on how many of the messages you've sent  
over some far ref have been delivered to the remote side, and thus how  
many more you can send to maintain reasonable flow.

3. Implement flow control at the application level as you described.

Comments? Missed options?

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Jimmy Wylie | 28 Oct 04:47 2008

Newbie Joe-E questions

Hi all,

I've downloaded joe-e for the first time and tried to import a simple 
project assigned from one of my beginner java classes.  After running 
the verifier, I've received 65 errors, but they all seem to be of the form:
 "Disabled field in from type System accessed: default deny"
 "Reference to disabled type Scanner: no policy specified for this class"
  "Disabled field out from type System accessed: default deny"
 "Method from disabled type PrintStream called: no policy specified for 
this class."

Now this class is a User Interface class, and I want it to be able to 
take in input from an instance of Scanner, and also do output.  How do I 
create a policy to allow these authorities for this class?
I tried simply passing an instance of Scanner in the constructor, 
instead of creating a new one when the constructor is called, but the 
verifier still objects to the "import java.util.Scanner" declaration.

Also, on sort of a separate note, could someone clarify exactly what a 
joe-e Token is? I read the Joe-E spec doc, and from what I can tell, it 
seems to be like a basic Joe-E type or a Joe-E "Object" class.  If I was 
writing a joe-e program, should all objects not declared to be powerless 
or immutable, be a Token instead?

Thanks for your help,
Jimmy Wylie
David Wagner | 28 Oct 05:55 2008
Picon

Newbie Joe-E questions

Jimmy Wylie writes:
>I've downloaded joe-e for the first time and tried to import a simple 
>project assigned from one of my beginner java classes.  After running 
>the verifier, I've received 65 errors, but they all seem to be of the form:
> "Disabled field in from type System accessed: default deny"
> "Reference to disabled type Scanner: no policy specified for this class"
>  "Disabled field out from type System accessed: default deny"
> "Method from disabled type PrintStream called: no policy specified for 
>this class."
>
>Now this class is a User Interface class, and I want it to be able to 
>take in input from an instance of Scanner, and also do output.  How do I 
>create a policy to allow these authorities for this class?
>I tried simply passing an instance of Scanner in the constructor, 
>instead of creating a new one when the constructor is called, but the 
>verifier still objects to the "import java.util.Scanner" declaration.

Thanks for giving Joe-E a whirl!  The Joe-E verifier is telling you
that those fields/methods are tamed away and are not accessible from
Joe-E.  The Joe-E verifier has a taming database that lists which fields
or methods in the Java libraries Joe-E code is allowed to access, and
System.in and System.out are purposefully excluded from that list.

There are two potential issues here:

1) Joe-E code is not supposed to be able to use the global variables
System.in and System.out, as those grant capabilities ambiently (i.e.,
they provide capabilities to all code by default, which is incompatible
with the principle of least privilege).  In this case the Joe-E verifier
is doing the right thing.  I think this is one issue you are hitting
(at least it is the one suggested by the "Disabled field" warning
messages you mention).

2) Currently, the Joe-E taming database is very minimalistic.  The policy
is "deny-by-default", meaning that if we haven't gotten around to taming
a particular portion of the Java library, then that portion of the
library will be inaccessible to Joe-E code by default -- and we haven't
gotten around to taming more than a tiny fraction of the Java library.
You might encounter this in other cases, where Joe-E code would like to
access some field/method of the Java libraries and where providing
access to that field/method would be OK (it wouldn't contradict any
capability principles) but because we haven't provided a taming database
for that portion of the Java libraries, you can't.  In those cases, the
only way to proceed would be to extend the taming database yourself.
You may be hitting this issue as well (e.g., in the warnings regarding
Scanner and PrintStream, which indeed have no taming policy specified
for them yet).

Let me comment on 1) above some more.  The obvious question is:
If Joe-E code is never allowed to gain any capabilities on its own
(only to receive capabilities passed to it), where does Joe-E code
get interesting capabilities from in the first place?  This is the
bootstrapping problem.  The canonical way to deal with this right
now is probably to build your application as a combination of Java and
Joe-E code.  The startup code (e.g., the implementation of main()) might
be written in Java.  Java code is unconstrained by the Joe-E verifier,
so it can directly access System.in and System.out.  The startup code
would then instantiate some Joe-E classes and invoke them, passing them
any capabilities they need to do their job.  Thus you might write the
bulk of your application in Joe-E.  Those Joe-E application classes
might expect you to pass them an InputStream and an OutputStream.
Your Java startup code could then just instantiate those classes and
pass System.in/System.out as an argument to their constructors.

I realize this may be a bit confusing; I'm not sure if that made
sense.  Sorry about that.

>Also, on sort of a separate note, could someone clarify exactly what a 
>joe-e Token is?

You can ignore Tokens for now.  They're an advanced feature that
aren't needed for most purposes -- just pretend they don't exist.

Oh, you want to know why they exist?  A Token is an object that
exists solely for its unique object identity.  If you do
    Token t = new Token();
    Token u = new Token();
then you are guaranteed that t!=u, and in particular no two Token
objects will have the same object identity.  There are some cases
where it's useful to have a bunch of "key" objects that exist solely
for their object identity (e.g., when building sealer/unsealers), and
then the idiomatic way to implement that in Joe-E is to use Tokens.
The recommended Joe-E idiom is that you normally shouldn't use object
identity (the "address" of an object) as a way to escalate privileges;
in those cases where you do want to do that, use a Token, not any
old object.  e.g.,
    public class Lockbox {
        private final Token key;
        private final Object contents;
        public Lockbox(Token k, Object o) {
            key = k; contents = o;
        }
        public Object unlock(Token k) {
            if (k == key)
                return contents;
            else
                throw new SecurityException("wrong key");
        }
    }
Here I can create a Lockbox using a new Token t, then hand Alice
the Lockbox and hand Bob the Token; now Alice and Bob can only retrieve
the contents of the Lockbox if they both cooperate.

http://www.cs.berkeley.edu/~daw/joe-e/api/org/joe_e/Token.html

If that didn't make sense, just ignore Tokens for now.

>I read the Joe-E spec doc, and from what I can tell, it 
>seems to be like a basic Joe-E type or a Joe-E "Object" class.

Nope.

>If I was 
>writing a joe-e program, should all objects not declared to be powerless 
>or immutable, be a Token instead?

Nope.  Just write your mutable classes like normal (ignore Token,
and don't do anything special -- you don't have to subclass any
preexisting special class or anythign like that).
Toby Murray | 28 Oct 11:49 2008
Picon
Picon

LockBox and static typing (was: Newbie Joe-E questions)

On Mon, 2008-10-27 at 21:55 -0700, David Wagner wrote:
> A Token is an object that
> exists solely for its unique object identity.  If you do
>     Token t = new Token();
>     Token u = new Token();
> then you are guaranteed that t!=u, and in particular no two Token
> objects will have the same object identity.  There are some cases
> where it's useful to have a bunch of "key" objects that exist solely
> for their object identity (e.g., when building sealer/unsealers), and
> then the idiomatic way to implement that in Joe-E is to use Tokens.
> The recommended Joe-E idiom is that you normally shouldn't use object
> identity (the "address" of an object) as a way to escalate privileges;
> in those cases where you do want to do that, use a Token, not any
> old object.  e.g.,
>     public class Lockbox {
>         private final Token key;
>         private final Object contents;
>         public Lockbox(Token k, Object o) {
>             key = k; contents = o;
>         }
>         public Object unlock(Token k) {
>             if (k == key)
>                 return contents;
>             else
>                 throw new SecurityException("wrong key");
>         }
>     }
> Here I can create a Lockbox using a new Token t, then hand Alice
> the Lockbox and hand Bob the Token; now Alice and Bob can only retrieve
> the contents of the Lockbox if they both cooperate.

In E, this implementation would be vulnerable to malicious (supposed)
LockedBoxes stealing Tokens. I'm wondering, does the Java static type
system prevent this sort of problem?

To expand, suppose Alice creates a LockedBox l using Token t. She hands
t to Bob. Bob is subsequently handed what he thinks is l but is really
l' -- an Object whose unlock() method simply keeps a copy of whatever
token it was passed, thereby accumulating keys to LockedBoxes. When Bob
tries to unlock l', he inadvertently passes t (a powerful capability,
when used with l) to some (possibly malicious, certainly untrusted)
thirdparty.

However, to what extent does the static typing in Java prevent this from
happening? Bob is expecting a LockedBox; does the type system guarantee
that if an object is assigned to a field of this type, then its unlock
method behaves as Bob would expect (in that it won't steal his Token)?

Cheers

Toby

Gmane