headers
Kevin Reid | 2 Nov 2004 22:35

Bug (0.8.30d): meta.context() exposes global state

? def c := meta.context()
# value: <a StaticContext>

? c.__optUncall()
# value: [<unsafe:org.erights.e.elang.scope.StaticContext>, "run", [<a 
ScopeLayoutLink>, null]]

? c == E.call(E, "call", c.__optUncall())
# value: true

? def oops := c.__optUncall()[0]
# value: <unsafe:org.erights.e.elang.scope.StaticContext>

? oops == <unsafe:org.erights.e.elang.scope.StaticContext>
# value: true

? oops.getStaticContextMaker()
# value: <unsafe:org.erights.e.elang.scope.StaticContext>

? oops.setStaticContextMaker(null)     # <-- globally visible mutation
? oops.getStaticContextMaker()

? oops.setStaticContextMaker(oops)

In addition to this hole (which I assume will be fixed by making 
StaticContext.StaticContextMaker final), it seems inappropriate that 
the uncall of a 'literal' PassByCopy object (any E code implicitly has 
a reference to it) involves a maker that is not itself <import>able - 
either it is unsafe (and should not be accessible) or is safe (and 
should be marked so in safej).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 3 Nov 2004 18:41

[Fwd: Abstraction Mechanisms for Access Control]

[forwarded with permission. --MarkM]

Hello Mark, hello Jonathan,

In http://www.erights.org/talks/asian03/paradigm-revised.pdf you wrote:

   While Dennis and van Horn's 1966 paper, Programming Semantics for
   Multiprogrammed Computations [Dennis66] clearly suggested both the
   need and a basis for a unified semantic view of permissions and
   program behavior, we are unaware of any formal analysis pursuing
   this approach in the security, programming language, or operating
   system literature.

You might be interested to learn about Askemos.  It's in a way pretty
simillar the object system you're describing in your paper and starts
out with a rights management system (a slight extension to usual
capability systems), which is proven to solve the revocation problem
(a *very* simple set theoretic proof).

Please see
1. Overview http://www.softeyes.net/A04538159df3258ea68544531bea1c006
2. http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/AskemosProtection
3. http://www.askemos.org - the implementation

May I ask for your permission to put your paper up on our servers for
reference and redistribution in the Askemos network?

[The answer was yes. The reposted paper is at 
<http://www.askemos.org/A24c431e797f1d7c46dd98597f530387e>. --MarkM]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Reid | 8 Nov 2004 03:14

Bugs (0.8.31d): FlexList and FlexMap lose value type in uncall, FlexMap dies on some types

Simple example:

? [].diverge(float64).__optUncall()
# value: [[], "diverge", []]

I expected the value to be instead [[], "diverge", [float64]].

Demonstration of how this would affect a persistent application:

? def flexList1 := [1, 2.0, 3].diverge(float64)
# value: [1.0, 2.0, 3.0].diverge()

? flexList1.push(4)
? flexList1
# value: [1.0, 2.0, 3.0, 4.0].diverge()

? def flexList2 := E.call(E, "call", flexList1.__optUncall())
# value: [1.0, 2.0, 3.0, 4.0].diverge()

? flexList2.push(5)
? flexList2
# value: [1.0, 2.0, 3.0, 4.0, 5].diverge()

FlexMap has the same bug:

? ["a" => "b"].diverge(String, String).__optUncall()
# value: [["a" => "b"], "diverge", []]

- and some others:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matej Kosik | 8 Nov 2004 12:36
Picon
Favicon

question about persistence

Hello,

I have tried out recent version of E (0.8.31). The basics of the 
language and the computational model is quite well documented.

It seems to me to be worthwhile to make further experiments. I have ran 
into problems when I have tried to figure out things
concerning _persistence_. Ideally (from my perspective) it would be 
perfect if it was possible to make something similar to the following 
Smalltalk statement:

	Smalltalk snapshot: true andQuit: false

Is something like this possible? It was not able to work it out.

What can I do with it? Is it currently possible to save the status of a 
currently running _vat_ in some way?

PS: I have found a related example `persist-echat.e-awt'. It guess that 
the `timeMachine' object therein should be responsible for the _vat_ 
persistency (is it true?). Nonetheless, I wasn't successful to force 
that particular script to behave _persistently_. I do not now know 
whether I have used that particular script in a wrong way or if the 
`timeMachine' works at all.

Cheers
--

-- 
Matej Kosik
Permalink | Reply | 1 comment |
headers
marcs | 9 Nov 2004 00:27

RE: question about persistence

> I have tried out recent version of E (0.8.31). The basics of the 
> language and the computational model is quite well documented.

I for one am pleasantly surprised to hear you describe it as "well
documented" :-)

> 
> It seems to me to be worthwhile to make further experiments. 
> I have ran 
> into problems when I have tried to figure out things
> concerning _persistence_. Ideally (from my perspective) it would be 
> perfect if it was possible to make something similar to the following 
> Smalltalk statement:
> 
> 	Smalltalk snapshot: true andQuit: false
> 
> Is something like this possible? It was not able to work it out.

Unfortunately, persistence is, as you have noticed, the least well
documented part of E. In addition to the persistent e-chat you ran into, you
might also want to check out the DonutLab scripts (in
scripts/donutServices), which use persistence relatively extensively. To
bring up a donutLab mint, for example, first run the script createMint.e.
This will create a bunch of persistent accounts and revokers for those
accounts, in addition to a vat checkpoint. Shut the mint down, and run
reviveMint.e (in the same directory, so it can find its checkpoint to revive
from), and the same mint will be revive with the same vat ID. 

Both echat and donutLab use the addExit mechanism (you will find it in the
mint scripts), which is simple and useful but not a general purpose
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 9 Nov 2004 12:24

Re: perplexing problem

This is definitely a bug in E, and one that I don't yet understand. In E, 
leaving aside the surprising symptoms you're encountering, it is indeed the 
case that it's always better to say ":void" when that's correct, than it is to 
say ":any".

If you could send me two similar versions of the code, one of which exhibits 
this bug and one which doesn't, that would be great. Thanks.

I'm cc'ing this response to e-lang to alert everyone of this, and to see if 
anyone can offer any insights. Anyone?

(The problem referred to in the homework below, and related sample code, can 
be found on the course web page at 
<http://www.cs.jhu.edu/~scheideler/courses/600.348_F04/>.)

Benny Tsai wrote:
> After getting ahold of Nilo et. al's wheel network code, i immediately
> tested it to see if i could induce the same weird bug i wrote about
> earlier ("the donor is gone").  No luck, as evidently they wrote
> better code than i :)  So i began to compare their code to mine,
> migrating the differences over to my code one at a time to see what
> exactly would fix the bug.
> 
> Turns out that the problem seems to be caused by the ":void" return
> type on many of my functions.  When i write E code, any time a
> function does not actually return anything, i set it to have a void
> return type; seemed sensible enough to me.  I guess E doesn't like
> this very much.  After setting all such functions to have the ":any"
> return type instead, the "the donor is gone" bug disappeared.  If
> anyone could explain why this happens, i'd be delighted!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Reid | 9 Nov 2004 14:25

Re: Re: perplexing problem

On Nov 9, 2004, at 6:24, Mark Miller wrote:
> Benny Tsai wrote:
>> Turns out that the problem seems to be caused by the ":void" return
>> type on many of my functions.  When i write E code, any time a
>> function does not actually return anything, i set it to have a void
>> return type; seemed sensible enough to me.  I guess E doesn't like
>> this very much.  After setting all such functions to have the ":any"
>> return type instead, the "the donor is gone" bug disappeared.  If
>> anyone could explain why this happens, i'd be delighted!
>> -Benny
> This is definitely a bug in E, and one that I don't yet understand. In 
> E, leaving aside the surprising symptoms you're encountering, it is 
> indeed the case that it's always better to say ":void" when that's 
> correct, than it is to say ":any".
>
> If you could send me two similar versions of the code, one of which 
> exhibits this bug and one which doesn't, that would be great. Thanks.

I'd like to see the code too, if that's allowed.

> I'm cc'ing this response to e-lang to alert everyone of this, and to 
> see if anyone can offer any insights. Anyone?

(Please forward this message if appropriate.)

I have not come across any E bug like this.

However, what occurs to me is that there may be a return value actually 
in use that isn't obvious. This couldn't happen in easy-return style, 
but I'm guessing that they're not using it since the sample code
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 9 Nov 2004 14:37

Re: Java connection :))

Peter Dimitrov wrote:
> Hi Mark,
> 
> I still struggle to import my own class in E:)) I tried the following after
> I changed the CLASSPATH to point to MyClass.class (this is my class :)))
> 
> def mycls := <unsafe:MyClass>
> def mycls := <unsafe:MyClass>()
> def mycls := <unsafe:java.MyClass>()
> 
> and many more but still get the same error:
> 
> "# problem: Failed: java.MyClass not found" or
> "# problem: Failed: MyClass not found"
> 
> How that exactly has to be done?

How did you change the classpath? The recommended way is to invoke rune as 
follows:

     $ rune -cpa dir ...

or

     $ rune -cpb dir ...

where "dir" is the root of a directory tree containing your MyClass.class 
under the appropriate package path. (If the directory contains spaces or other 
odd characters, be sure to put quotes around it.) The "..." is the remainder 
of whatever your normal rune invocation would be, and would be empty for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 9 Nov 2004 15:00

Re: conflicting definitions error

Peter Dimitrov wrote:
> Hi Mark,
> 
> I noticed that when i use when catch the following warning occurs:
> 
> *** conflicting definitions of __main$makenode__C$node__C$done__C
> 
> What exactly this warning means?

That there are multiple objects defined with this same fully qualified name. 
This occurs with when-catch usage when you say, for example,

     def makenode {
         ...
         def node {
            ...
            when (...) -> done(...) { ... } catch ... { ... }
            ...
            when (...) -> done(...) { ... } catch ... { ... }
            ...
         }
     }

"done" is not a keyword above. Instead, it is simply used to name the object 
(the "done-closure") which behaves according to the code appearing to the 
right of the "->", much as "node" is used to name the object which behaves 
according to the code in the containing object definition above.

The fully qualified name is formed, as in Java, by appending the package path 
(in your case, "__main") with the path of names of containing object
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 12 Nov 2004 16:15

New paper: The Structure of Authority

At <http://www.erights.org/talks/no-sep/index.html>.

[Caution: wide distribution. Please send replies only to a narrower addressee 
list. Thanks.]

                             The Structure of Authority:
                      Why security is not a separable concern

by Mark S. Miller, Bill Tulloh, and Jonathan Shapiro

Common programming practice grants excess authority for the sake of 
functionality; programming principles require least authority for the sake of 
security. If we practice our principles, we could have both security and 
functionality. Treating security as a separate concern has not succeeded in 
bridging the gap between principle and practice, because it operates without 
knowledge of what constitutes least authority. Only when requests are made -- 
whether by humans acting through a user interface, or by one object invoking 
another -- can we determine how much authority is adequate. Without this 
knowledge, we must provide programs with enough authority to do anything they 
*might* be requested to do.

We examine the practice of least authority at four major layers of abstraction 
-- from humans in an organization down to individual objects within a 
programming language. We explain the special role of object-capability 
languages -- such as E or the proposed Oz-E -- in supporting practical least 
authority.

--

-- 
Text by me above is hereby placed in the public domain
(Continue reading)

Permalink | Reply | 0 comments |

Gmane