http://wiki.erights.org/mediawiki/index.php?title=Special:Contributions&feed=atom&target=AnsibleErights - User contributions [en]2024-03-19T05:02:09ZFrom ErightsMediaWiki 1.15.5-7http://wiki.erights.org/wiki/File:Erights_small_logo.gifFile:Erights small logo.gif2012-09-05T19:06:19Z<p>Ansible: </p>
<hr />
<div></div>Ansiblehttp://wiki.erights.org/wiki/SandboxSandbox2012-09-05T14:46:33Z<p>Ansible: Can I still make changes?</p>
<hr />
<div>Use this page for test edits of the wiki.<br />
----<br />
Test edit after move.<br />
<br />
---------<br />
Test after reboot.<br />
[http://www.example.com Example]<br />
<br />
-----------<br />
<br />
After rebooing on Monday. [http://www.reddit.com Reddit].<br />
<br />
-----------<br />
<br />
Testing recent changes.<br />
<br />
I can still make changes.</div>Ansiblehttp://wiki.erights.org/wiki/SandboxSandbox2012-07-09T15:31:18Z<p>Ansible: Another test.</p>
<hr />
<div>Use this page for test edits of the wiki.<br />
----<br />
Test edit after move.<br />
<br />
---------<br />
Test after reboot.<br />
[http://www.example.com Example]<br />
<br />
-----------<br />
<br />
After rebooing on Monday. [http://www.reddit.com Reddit].</div>Ansiblehttp://wiki.erights.org/wiki/SandboxSandbox2012-04-27T16:38:35Z<p>Ansible: test after reboot & reconfig</p>
<hr />
<div>Use this page for test edits of the wiki.<br />
----<br />
Test edit after move.<br />
<br />
---------<br />
Test after reboot.<br />
[http://www.example.com Example]</div>Ansiblehttp://wiki.erights.org/wiki/SandboxSandbox2011-11-08T00:12:48Z<p>Ansible: </p>
<hr />
<div>Use this page for test edits of the wiki.<br />
----<br />
Test edit after move.</div>Ansiblehttp://wiki.erights.org/wiki/Walnut/Distributed_Computing/PromisesWalnut/Distributed Computing/Promises2011-04-20T19:49:24Z<p>Ansible: revert vandalism</p>
<hr />
<div>[[Category:Walnut|3]]<br />
<br />
===Promises===<br />
<br />
When you make an eventual send to an object (referred to hereafter simply as a ''send'', which contrasts with a ''call'' to a local object that waits for the action to complete), even though the action may not occur for a long time, you immediately get back a promise for the result of the action:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def carVow := makeCar <- ("Mercedes")<br />
carVow <- moveTo(2,3)</nowiki><br />
<br />
</pre><br />
<br />
In this example, we have sent the makeCar function the default "run" message. Eventually the carMaker will create the new car on the same computer where the carMaker resides; in the meantime, we get back a promise for the car.<br />
<br />
Once we've got a promise, pipelining comes into the picture: ''We can immediately start making eventual sends to the promise just as if it were indeed the car''. Enormous queues of operations can be shipped across the poor-latency comm network while waiting for the car to be created, confident that those operations will be executed as soon as possible.<br />
<br />
But don't try to make an immediate call on the promise. Don't try it even if the car maker (and therefore the car it creates) actually live on the same computer with the program. To make immediate calls on the promised object, you must set up an action to occur when the promise resolves, using a when-catch construct:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def temperatureVow := carVow <- getEngineTemperature()<br />
when (temperatureVow) -> {<br />
println(`The temperature of the car engine is: $temperatureVow`)<br />
} catch prob {<br />
println(`Could not get engine temperature: $prob`)<br />
}<br />
println("execution of the when-catch waits for resolution of the promise,")<br />
println("but the program moves on immediately to these printlns")</nowiki><br />
<br />
</pre><br />
<br />
We can read the when-catch statement as, "when the promise for a temperature becomes done, and therefore the temperature is locally available, perform the main action block... but if something goes wrong, catch the problem in variable prob and perform the problem block". In this example, we have requested the engine temperature from the carVow. Eventually the carVow resolves to a car and receives the request for engine temperature; then eventually the temperatureVow resolves into an actual temperature. The when-catch construct waits for the temperature to resolve into an actual (integer) temperature, but only the when-catch construct waits (i.e., the when catch will execute later, out of order, when the promise resolves). The program itself does not wait: rather, it proceeds on, with methodical determination, to the next statement following the when-catch.<br />
<br />
Inside the when-catch statement, we say that the promise has been ''resolved''. A resolved promise is either ''fulfilled'' or ''broken''. If the promise is fulfilled, the main body of the when-catch is activated. If the promise is broken, the catch clause is activated.<br />
<br />
Notice that after ''temperatureVow'' resolves to ''temperature'', the when clause treats temperature as a local object. This is always safe to do when using vows. A ''vow'' is a reference that always resolves to a local object. In the example, variable names suffixed with "vow" remind us and warn others that this reference is a vow. We can reliably make eventual sends on the vow and immediate calls on what the vow resolves to, but we cannot reliably make immediate calls to the vow itself. A more detailed discussion of these types of warnings can be found in the Naming Conventions section later.<br />
<br />
Not all references can guarantee to resolve to a local object. A ''receiver'' is a reference that can resolve to a local or remote object. Since we cannot ascertain beforehand whether it is local or remote, we must treat it as a remote object, i.e., we must interact with it only using eventual sends. We can use either the suffix Rcvr on the variable name as a reminder, or we can use the rcvr guard when defining the variable as a reminder. If you use Rcvr as a suffix, you will be more reliably reminded not to use immediate calls, but it does produce long variable names.<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def car :rcvr := makeCarRcvr <- ("Mercedes")<br />
car <- moveTo(2,3)</nowiki><br />
<br />
</pre><br />
<br />
In this example, makeCarRcvr is a reference to a makeCar function that we have reason to believe may be remote, and therefore can only be spoken to reliably with eventual sends. We could name the vehicle a carRcvr, since it's a reference to a car local to the makeCar function, which therefore is also probably remote to us (if makeCar is remote, so is the car). Instead, we have chosen to use the rcvr guard to remind us to only use eventual sends when interacting with this car.<br />
<br />
When-catch, like try-catch, has an optional ''finally'' clause that always executes:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
when (tempVow) -> {<br />
#...use tempVow<br />
} catch prob {<br />
#.... report problem<br />
} finally {<br />
#....log event<br />
}</nowiki><br />
<br />
</pre></div>Ansiblehttp://wiki.erights.org/wiki/Category:Message_abs/0Category:Message abs/02011-04-20T19:49:03Z<p>Ansible: revert vandalism</p>
<hr />
<div>{{message category|abs|0}}</div>Ansiblehttp://wiki.erights.org/wiki/Walnut/Distributed_Computing/Testing_for_Equality_in_a_Distributed_SystemWalnut/Distributed Computing/Testing for Equality in a Distributed System2011-04-20T19:03:23Z<p>Ansible: revert the revert (Kevin fixed it already)</p>
<hr />
<div>===Testing for Equality in a Distributed System===<br />
<br />
As noted above, you can send eventual messages to both promises and far references. So if you plan to treat the fulfilled object as a far reference, using only eventual sends, there is usually no reason to use a when-catch to wait for resolution. Just go ahead and start sending messages, uncaring of whether the promise has yet been fulfilled.<br />
<br />
There are four reasons to use a when-catch construct to resolve the promise for a far object.<br />
<br />
* To find out that the original request succeeded, or otherwise, to get the problem<br />
* To flush out all previous messages sent via a reference to an object before taking an action<br />
* To use the result as a key in a hash table (a promise cannot be used as a hash key)<br />
* To test for equality, i.e., to see whether the promised object is the same object that you received from another activity.<br />
<br />
Here is a test for equality:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def polePositionCarRcvr := raceTrack <- getPolePositionCar()<br />
when (polePositionCarRcvr) -> {<br />
if (polePositionCarRcvr == myCar) {<br />
println("My car is in pole position")<br />
}<br />
} catch prob {}</nowiki><br />
<br />
</pre><br />
<br />
Note that the catch clause is empty. Because remote references across a network are unreliable, you will usually want to handle the problem that triggered the catch clause. However, if you have many pending actions with a single remote object, all the catch clauses for all those actions will start up if the connection fails, so you may want to disregard most of the catch clauses and focus on handling the larger problem (loss of connection) in one place. Often in this situation you will want to set up a whenBroken message, described later.<br />
<br />
But in this example, there is no compelling special action to take if you can't find out whether your car is in pole position, so no action is taken.<br />
<br />
===Making your own Promises===<br />
<br />
If you write a function or method that must get values from a far object before returning an answer, your function should return a promise for the answer, and fulfill that answer later. You can create your own promises using Ref.promise() in <span class="e">''E''</span><nowiki>:</nowiki><br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def calcMilesBeforeEmptyVow(carRcvr) {<br />
def [milesBeforeEmptyPromise, milesBeforeEmptyResolver] := Ref.promise()<br />
def fuelRemainingVow := carRcvr <- getFuelRemaining()<br />
def mpgVow := carRcvr <- getEfficiency()<br />
when (fuelRemainingVow, mpgVow) -> {<br />
milesBeforeEmptyResolver.resolve(mpgVow * fuelRemainingVow)<br />
} catch prob {<br />
milesBeforeEmptyResolver.smash(`Car Lost: $prob`)<br />
}<br />
return milesBeforeEmptyPromise<br />
}<br />
<br />
#....Meanwhile, somewhere else in the program....<br />
def myCar {<br />
to getFuelRemaining() {return 5}<br />
to getEfficiency() {return 2}<br />
}<br />
def milesVow := calcMilesBeforeEmptyVow(myCar)<br />
when (milesVow) -> {<br />
println(`miles before empty = $milesVow`)<br />
} catch e {println(`Error: $e`)}</nowiki><br />
<br />
</pre><br />
<br />
This example highlights several different features of promises. The basic idea of the example is that the function calcMilesBeforeEmptyVow(carRcvr) will eventually compute the number of miles the car can still travel before it is out of fuel; later in the program, when this computation is resolved, the program will print the value. However, before we can do the computation, we must first get both the fuelRemaining and the milesPerGallon values from the remote car.<br />
<br />
The promise and the resolver for that promise are created as a pair using Ref.promise(). They are "normal" variables in the sense that they can be passed as arguments, returned from methods as answers, and sent eventual messages. Resolvers truly are ordinary objects. There are 3 restrictions on the promises: they cannot accept immediate calls, they cannot be tested for equality, and they cannot be used as keys in hash tables.<br />
<br />
In this example, the function returns the milesBeforeEmptyPromise to the caller just as it would return any other kind of value. To cause the promise to resolve, the function calls the resolver (or sends to the resolver if the resolver may be remote to your program) with the "resolve(value)" method. To break the promise (which produces a problem that will cause the catch clause of a when-catch to execute), call the resolver with the "smash(problem)" method.<br />
<br />
It is possible to chain resolutions: you can resolve a promise by handing the resolver another promise (though if you hand the resolver the promise which it is intended to resolve, <span class="e">''E''</span> will detect the problem and automatically break the promise--a promise resolved to itself can never be fulfilled). If you resolve a promise with another promise, the original promise is not yet considered resolved, i.e., the when-catch body will not be activated by such a resolution. The when-catch body will only be activated when the entire promise chain is resolved, and there is an actual reference to an actual object available.</div>Ansiblehttp://wiki.erights.org/wiki/VatVat2011-04-20T18:58:03Z<p>Ansible: revert vandalism</p>
<hr />
<div>See [http://www.erights.org/elib/concurrency/vat.html].<br />
<br />
<br />
==Example: How to create a new Vat==<br />
<pre><br />
? introducer.onTheAir()<br />
# value: ["3DES_SDH_M2", "3DES_SDH_M"]<br />
<br />
? def seedVat := <elang:interp.seedVatAuthor>(<unsafe>).virtualize(introducer)<br />
# value: <virtualSeedVat><br />
<br />
? def source := "def run(thing) {println(`Thing: $thing`)}"<br />
# value: "def run(thing) {println(`Thing: $thing`)}"<br />
<br />
? def [farObj, vat] := seedVat(source)<br />
# value: [<Promise>, <Vat newVirtualSeedVat in <runs in newVirtualSeedVat>>]<br />
<br />
? farObj <- ("Hello Vat")<br />
# value: <Promise><br />
<br />
? Thing: Hello Vat<br />
<br />
# shutting down the vat<br />
? def ack := vat <- orderlyShutdown("because I said so")<br />
# value: <Promise><br />
<br />
</pre><br />
<br />
[[Category:ELib specification]]</div>Ansiblehttp://wiki.erights.org/wiki/Walnut/Distributed_ComputingWalnut/Distributed Computing2011-04-20T18:56:36Z<p>Ansible: revert vandalism</p>
<hr />
<div>[[Category:Walnut|3]]<br />
<br />
==Distributed Computing==<br />
<br />
Multiple threads form the basis of conventional models of concurrent programming. Remarkably, human beings engage in concurrent distributed computing every day even though people are generally single threaded (there are exceptions: Walter Cronkite routinely listened to one broadcast with one ear, a different broadcast with the other, while simultaneously taking notes on another topic and speaking authoritatively to an audience of millions. But most people, including this author, live single-threaded lives).<br />
<br />
How do we simple creatures pull off the feat of distributed computing without multiple threads? Why do we not see groups of people, deadlocked in frozen tableau around the coffepot, one person holding the sugar waiting for milk, the other holding milk waiting for sugar?<br />
<br />
The answer is, we use a sophisticated computational mechanism known as a ''nonblocking promise''.<br />
<br />
Let us look at a conventional human distributed computation. Alice, the CEO of Evernet Computing, needs a new version of the budget including R&D numbers from the VP of Engineering, Bob. Alice calls Bob: "Could you get me those numbers?"<br />
<br />
Bob jots Alice's request on his to-do list. "Sure thing, Alice, I promise I'll get them for you after I solve this engineering problem."<br />
<br />
Bob has handed Alice a promise for the answer. He has ''not '' handed her the answer. But neither Bob nor Alice sits on their hands, blocked, waiting for the resolution.<br />
<br />
Rather, Bob continues to work his current problem. And Alice goes to Carol, the CFO: "Carol, when Bob gets those numbers, plug 'em into the spreadsheet and give me the new budget,okay?"<br />
<br />
Carol: "No problem." Carol writes Alice's request on her own to-do list, but does not put it either first or last in the list. Rather, she puts it in the conditional part of the list, to be done when the condition is met--in this case, when Bob fulfills his promise.<br />
<br />
Conceptually, Alice has handed to Carol a copy of Bob's promise for numbers, and Carol has handed to Alice a promise for a new integrated spreadsheet. Once again, no one waits around, blocked. Carol ambles down the hall for a contract negotiation, Alice goes back to preparing for the IPO.<br />
<br />
When Bob finishes his calculations, he signals that his promise has been fulfilled; when Carol receives the signal, she uses Bob's fulfilled promise to fulfill her own promise; when Carol fulfills her promise, Alice gets her spreadsheet. A sophisticated distributed computation has been completed so simply that no one realizes an advanced degree in computer science should have been required.<br />
<br />
In this simple example, we see why human beings never get trapped in the thread-based deadlock situations described endlessly in books on concurrent programming. People don't deadlock because they live in a concurrent world managed with a promise-based architecture. And so it is with <span class="e">''E''</span>.<br />
<br />
This chapter on distributed computing is the longest and most challenging part of the book. The Promise Architecture of <span class="e">''E''</span> is very different from the threads, synchronized methods, guarded objects, and RMI of Java. One might expect the Security chapter and its Capability paradigm to be equally new and challenging. But in fact, the implementation of security is embedded so deeply in E's infrastructure that much of the effort merely involves realizing the power inherent in constructs we have already learned. Security with <span class="e">''E''</span> is more a matter of architecture than of coding.<br />
<br />
Distributed computation, however, still requires gritty effort. We start simply, with the eventually operator.<br />
<br />
{{:Walnut/Distributed Computing/Eventually Operator}}<br />
{{:Walnut/Distributed Computing/Promises}}<br />
{{:Walnut/Distributed Computing/Multiway when-catch}}<br />
{{:Walnut/Distributed Computing/Partial Ordering Of Sent Messages}}<br />
{{:Walnut/Distributed Computing/Naming conventions}}<br />
{{:Walnut/Distributed Computing/Testing for Equality in a Distributed System}}<br />
<br />
===Letting When-Catch make a Promise For You===<br />
<br />
As noted in chapter 1 under the Secret Lives of Flow Control Structures, control structures return values. When used as described up to this point, the return value of the when--catch expression has been ignored. In fact, the when-catch expression returns a promise for the value that the done function will return. If the done function does not return a value, then it will always resolve to null. However, if the <font color="#FF0000">done(value) function</font> of the when-catch returns a value, the when-catch returns a promise that will be fulfilled by the last value in the executed clause. Rewriting the calcMilesBeforeEmptyVow using this feature, we get: <span class="warn" style="color:red">not right, not right, fix</span><br />
<br />
<pre><br />
<br />
<nowiki># E sample <br />
def calcMilesBeforeEmptyVow(carRcvr) { <br />
def fuelRemainingVow := carRcvr <- getFuelRemaining() <br />
def mpgVow := carRcvr <- getEfficiency() <br />
return when (fuelRemainingVow, mpgVow) -> { <br />
mpgVow * fuelRemainingVow <br />
} catch prob { <br />
throw(`Car Lost: $prob`)<br />
}<br />
}</nowiki><br />
<br />
</pre><br />
<br />
Here the when-catch creates the promise which is returned by the function, and resolution is automatic at the end of the when-catch execution. <br />
So when the promise that the when-catch depends on is resolved the promise it returned will be resolved to the result of the last seqExp in the when clause but if the promise that the when-catch depends on is smashed the returned promise will be smashed by the throw in the catch clause. Eather way the finally clause has no effect on the resolution of the promise returned by when-catch.<br />
<br />
===Broken Promise Contagion===<br />
<br />
When chaining promises, what happens if one of the promises in the middle or the far end breaks? The problem that breaks the far promise is propagated down all the promises dependent on it. As a consequence, broken promises work their way through the system in a similar way to exceptions being caught in try/catch blocks.<br />
<br />
===State Transitions for References===<br />
<br />
Having worked our way through near, far, broken, and promised references, let us put all the transitions among these together in a single place. The following diagram shows all the kinds of references <span class="e">''E''</span> distinguishes between, and it shows the two possible transitions:<br />
<br />
<font color="rgb(255, 0, 0)"> [[Image:ref-mech-0.gif|state transition diagram]]</font><br />
<br />
The 2 transitions are:<br />
<br />
* A promise may transition (resolve) into a resolved reference, which can be near or far or broken..<br />
* A far ref may transition to a broken ref.<br />
<br />
That is the complete collection of transitions.<br />
<br />
===Guards for distributed systems===<br />
<br />
Very early in the book, we presented a list of <span class="e">''E''</span> types, including any, integer, float64, etc. In that list were "rcvr", "vow", "pbc" and "near". "pbc" means that the type of the value is required to be "pass by construction". Transparent immutables are generally pbc, and can be passed through this type declaration. Strings, integers, floats, booleans, ConstMaps and ConstLists are all pbc. Objects that are pbc are copied when they are sent, so that even if the object originated on a remote computer, when you get it you can use immediate calls on it. Also, since pbc objects do not embody any code, pbc objects passed across a trust boundary can be used with far fewer security concerns: the pbc object may contain bad data, but it cannot play any tricky games in its execution.<br />
<br />
"Near" means that the value must be local. Promises and far references will not pass the near guard. Anything that passes a near guard can be sent messages with immediate calls.<br />
<br />
At this time, "rcvr" and "vow" have the same algorithmic meaning as "any", but can be used as hints to the programmer about how to interact with the object (a vow should be referenced only eventually until it is resolved; a rcvr should always be referenced only eventually).<br />
<br />
===Nested When-Catch constructs===<br />
<br />
As discussed earlier, we can guarantee the ordering of messages sent from one object to another object. But when a program sends messages to several objects, on different machines, the order in which answers will be received cannot be predicted. Suppose you need to perform a computation involving two far answers, and the algorithm depends on the result from the first answer. You can nest when-catch clauses to await the outcome of the dependency:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def fileRcvr := fileCacheRcvr <- getFile()<br />
when (def exists := fileRcvr <- exists()) -> {<br />
if (exists) {<br />
when (def text := fileRcvr <- getText()) -> {<br />
println(`File has text: $text`)<br />
} catch p2 {println(`Problem with existing file: $p2`)}<br />
} else {println("File does not exist")}<br />
} catch prob {println(`Problem reaching file: $prob`)}<br />
</nowiki><br />
<br />
</pre><br />
<br />
Here, we want to print the text of a farFile, but we want to be sure the file exists first. So we ask the file if it exists, and only after we determine that it does indeed exist do we proceed to get the text.<br />
<br />
As noted earlier, <font color="#FF0000">the "done(variable)" clause </font>of the when-catch construct is actually the declaration of a function and a series of parameters. The reasons for this are beyond the scope of this book, but the operational consequence is that you must use different function names if you have multiple when-catch clauses in the same scope.<br />
<br />
Nested when-catch clauses put the "done" functions into the same scope. In the example here, we gave the inner when-catch "done" function the name "done2" to prevent name collision. We also gave the error-containing variables in the catch clauses different names, e and e2.<br />
<br />
===Live Refs, Sturdy Refs, and URIs===<br />
<br />
Up to this point we have carefully dodged a critical question. How does a program acquire its very first reference to an object on a different computer? In all our examples up to this point, we have always started out with a reference to at least one remote object, and we retrieved other remote objects by asking that object for other objects: for example, we asked a remote carMakerRcvr for a new (remote) carRcvr, and were able to immediately work with the car just like any other remote object. How did we get the reference to the carMakerRcvr in the first place?<br />
<br />
In <span class="e">''E''</span>, the reference to an object can be encoded as a Universal Resource Identifier string, known as a ''uri'' (the familiar url of the Web is a type of uri). This uri string can be passed around in many fashions; one good secure way of passing a uri is to save it as a text file, encrypt and sign it with PGP, and send it in email. If you wish to run a seriously secure distributed <span class="e">''E''</span> system, encrypting the uris is crucial: indeed, the passing of the uris from machine to machine is the main security issue that <span class="e">''E''</span> cannot address for you (and is a problem shared by all security systems, a problem that will diminish with time as secure systems like PGP email are deployed). Other ways uris have been passed in operational <span class="e">''E''</span> systems have been to send the uri over an ssh connection, and (less securely) by reading the uri off over a telephone! If you are using <span class="e">''E''</span> on a local area network and have no security concerns, but are using <span class="e">''E''</span> simply because it is simpler, safer, and more maintainable for distributed computing, the uris can be stored in files on a shared file system and read directly by the programs on different computers as they start up.<br />
<br />
The functions makeURI(object) and objFromURI(uri) detailed in the <span class="e">''E''</span> Quick Reference Card perform the basic transformations you need to hook up objects on multiple computers. These routines use sturdy refs and liverefs in their computations. A sturdyRef is an object that contains an enduring description of where an object can be found; sturdyRefs and URIs are simple transformations of one another. LiveRefs are actual connections to objects that disappear any time a connection goes down. LiveRefs carry the actual traffic in <span class="e">''E''</span> communication. When you request a remote object from another remote object (as in farCarMaker <- ("mercedes")), what you actually get is a liveRef. If you want to continue to connect with that particular car across multiple sessions, you will need to explicitly get a sturdyRef from the car (and the car will have to have an explicit method for granting the sturdyRef. The sturdyref function is an important capability, not one handed out by default).<br />
<br />
Each program that expects to work with remote objects needs to invoke the command<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
introducer.onTheAir() </nowiki><br />
<br />
</pre><br />
<br />
before starting any remote connections, including the making or using of uris. An example of these functions working together can be found in eChat.<br />
<br />
===blockAtTop and continueAtTop===<br />
<br />
E programs never block. They never just sit and wait around for results. However, most programs will toss out some windows, or set up some services, and then desire to wait for someone or some thing to use them. Often, the first version of a program written by a new <span class="e">''E''</span> programmer will set everything up, execute the last line of the program, and then shut down. It is quite disconcerting to watch your windows briefly light up and then disappear, along with the java virtual machine underlying the entire program.<br />
<br />
The command<br />
<br />
<pre><br />
<br />
interp.blockAtTop()<br />
<br />
</pre><br />
<br />
causes the <span class="e">''E''</span> interpreter to wait for requests to come in. The command<br />
<br />
<pre><br />
<br />
interp.continueAtTop()<br />
<br />
</pre><br />
<br />
causes the <span class="e">''E''</span> interpreter to stop waiting. These commands are used in the eChat sample at the end of this chapter: the last line of the program initiates blockAtTop, and continueAtTop is invoked when the user closes his chat window.<br />
<br />
===A bit of Philosophy when using Promises for the first time===<br />
<br />
If a method accepts a promise or far reference as a parameter, the returned value almost certainly cannot be a local object. Why is this? If the computation of the returned object depends on something eventual, the computation will have to wait for an answer, which means the best the object can do for immediately returning something is to return a promise. So a method like getCar(licensePlateVow) has almost certainly violated the naming convention, one way or the other.<br />
<br />
As a consequence of this and other characteristics of promises, beginning E programmers often experience a moment of breathlessness soon after they first try to use them. This moment occurs when the programmer erroneously concludes that, once you let a promise into your system, the program has tumbled down a slippery slope from which there is no recovery. It feels as if you will never be able to have a real value in your hands again; you'll spend the rest of your life making eventual sends, coupled with endless when-catch constructs just to get to the next step.<br />
<br />
The breathlessness can metastasize into a feeling of having lost control of the software: everything is off computing somewhere else and all you have is a bunch of promises. Since <span class="e">''E''</span> never (really, never!) blocks, you can never tell things, "just stop for a moment while I catch my breath and gather up all the values" :-)<br />
<br />
In fact, there are several patterns and tools for getting control of things again. The basic multi-promise when-catch, and the promiseAllResolved and Summoner patterns at the end of this chapter are just a few examples of structures specifically designed to reduce the frequency with which you need when-catch. They allow you to get quickly back into local computation after a distributed action. You really can catch your breath.<br />
<br />
And once the moment of breathlessness passes, you will feel freedom, for you will never have to deal with thread synchronization again; you will never lie awake at night wondering if an unexplored race condition will cause deadlock a few days after the production load level hits your system. <font color="#ff0000">How early can I put this paragraph easily? AHK proposes right after Promises.</font><br />
<br />
===Additional Promise-Related Operations===<br />
<br />
* whenBroken<br />
* E isBroken<br />
* whenResolved Use this when your action will be the same once the promise resolves, regardless of whether it resolves broken or not.<br />
* E isResolved<br />
* E send(object,verb,arguments) This function is identical to the E call() function described earlier, but does an eventual send rather than an immediate call.<br />
* E sendOnly<br />
* E join(a,b) Guarantees sends to result of join are delivered only after messages to a and b have been delivered, sort of a test for equality on-the-fly<br />
<br />
===Under the Covers: Vats and Game Turns===<br />
<br />
<font color="#ff0000">Each vat has a separate event loop, each game turn corresponds to the processing of a single event to conclusion with no interruptions. There are frontend vats, which all share the swing event queue for queuing messages to their event loops, and there are backend queues, each of which has its own separate event queue and runs on a separate thread. Frontend vats have the advantage that they can interact directly with user interface widgets. The initial vat created by default at the start of an E program is a frontend vat. You might want multiple frontend vats if you want to shut down whole subsystems in one fell swoop: you can tell a vat to shut down, and it will terminate all its connections to the outside world, making it available for garbage collection. Have markm review this and tell me what is wrong with this description.</font><br />
<br />
<font color="#ff0000">creating a second frontend vat on a single jvm. creating a backend vat on a jvm</font><br />
<br />
===Example: Alice, Bob, and Carol as Code===<br />
<br />
We started this chapter with a description of a human interaction, with Alice as the CEO of Evernet Computing in search of a new spreadsheet for her IPO preparation. What would that distributed problem look like in code? Though we present only a skeleton of this human operation here, it is perhaps nonetheless informative. It might also be informative, after one has read how to do the example in <span class="e">''E''</span>, to think about how it would be done with threads, in Java or C++. That, however, is left as an exercise for the reader.<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
#---- Bob Code<br />
<br />
def bobRcvr {<br />
to handleExplosionInNetworkServerRoom() {<br />
# handle the explosion<br />
}<br />
to getCostNumbers() :pbc {<br />
return ["R&D" => 10000]<br />
}<br />
}<br />
<br />
#------------ Carol Code<br />
<br />
def carolRcvr {<br />
to attendMeeting(room, time) {<br />
# attend the meeting<br />
}<br />
to integrateSpreadsheetVow(RDNumbersVow) {<br />
def sheetVow := when (RDNumbersVow) -> {<br />
["Marketing" => 50000] | RDNumbersVow<br />
} catch prob {<br />
println("No numbers!")<br />
prob<br />
}<br />
return sheetVow<br />
}<br />
}<br />
<br />
#--------- Alice Code<br />
<br />
def aliceRcvr {<br />
to prepareIPOVow() {<br />
def RDNumbersVow := bobRcvr <- getCostNumbers()<br />
def spreadsheet := carolRcvr <- integrateSpreadsheetVow(RDNumbersVow)<br />
return when (spreadsheet) -> {<br />
println(`Appendix: Budget Spreadsheet: $\n$spreadsheet`)<br />
} catch prob {<br />
aliceRcvr <- fireSomebody([bobRcvr, carolRcvr])<br />
}<br />
# do other IPO preparations<br />
}<br />
to fireSomebody(candidateRcvrs) {<br />
# get rid of culprit<br />
}<br />
}<br />
<br />
bobRcvr <- handleExplosionInNetworkServerRoom()<br />
carolRcvr <- attendMeeting(1,2)<br />
aliceRcvr <- prepareIPOVow()</nowiki><br />
<br />
</pre><br />
<br />
===Example: minChat version 1===<br />
<br />
In order to focus on the distributed computation features of this chat tool, we have gone to extreme lengths to make the user interface machinery a very short piece of code. Hence, this should properly be called "minChat", because the user interface is so brutally minimal. Even with such minimization, however, the user interface still requires more lines of code than the actual distributed computation!<br />
<br />
The chatController at the bottom of the example is the heart and soul of the computation.<br />
<br />
<code><br />
<br />
<br />
#?? in new vat minChatVat.e-swt<br />
## E sample<br />
#!/usr/bin/env rune<br />
#eChat with minimalist user interface<br />
pragma.syntax("0.9")<br />
def <widget> := <swt:widgets.*><br />
def SWT := <swt:SWT><br />
introducer.onTheAir()<br />
# return the object represented by the URI<br />
def getObjectFromURI(uri) {return introducer.sturdyFromURI(uri).getRcvr()}<br />
<br />
def makeURIFromObject(obj) :String {<br />
# This implementation assumes a non-persistent single incarnation<br />
def [sr, _, _] := identityMgr.makeKnown(obj)<br />
<span style="color:#FF0000">#XXX not a uri if bracketed, bug, markm?</span><br />
def bracketed := introducer.sturdyToURI(sr)<br />
if (bracketed =~ `<@uri>`) {return uri}<br />
return bracketed<br />
}<br />
<br />
def chatController<br />
def chatArea<br />
def chatUI {<br />
to show() {<br />
def frame := <widget:Shell>(currentDisplay)<br />
frame.setText("eChat"); frame.setBounds(30, 30, 600, 300)<br />
def winDisposeListener {to widgetDisposed(event) {interp.continueAtTop()}} <br />
frame.addDisposeListener(winDisposeListener)<br />
bind chatArea := <widget:Text>(frame, <br />
(SWT.getMULTI() | SWT.getWRAP()) | (SWT.getBORDER() | SWT.getV_SCROLL()))<br />
def commandLine := <widget:Text>(frame, SWT.getSINGLE() | SWT.getBORDER())<br />
def enterKeyListener {<br />
to keyPressed (event) {<br />
if (event.getKeyCode() == 27) {<br />
if (commandLine.getText() =~ `@command @argument`) {<br />
commandLine.setText("")<br />
switch (command) {<br />
match == "save" {chatController.save(<file: argument>)}<br />
match == "load" {chatController.load(<file: argument>)}<br />
match == "send" {chatController.send(argument)}<br />
match _ {commandLine.setText("Error. Try save load, or send")}<br />
}<br />
} else {commandLine.setText("Error. Try save, load, or send")}<br />
}<br />
}<br />
match [verb, args] {}<br />
}<br />
commandLine.addKeyListener(enterKeyListener) <br />
def label := <widget:Label>(frame, SWT.getLEFT())<br />
label.setText("save, load, send. No quotes for path. Use Escape to start operation. ")<br />
swtGrid`$frame: $chatArea.X.Y<br />
$label.X<br />
$commandLine.X`<br />
frame.open()<br />
}<br />
to showMessage(initiator, text) {chatArea.append(`$initiator: $text $\n`)}<br />
}<br />
<br />
def friend<br />
bind chatController {<br />
to send(message) {<br />
when (friend<-receive(message)) -> {<br />
chatUI.showMessage("self", message)<br />
} catch prob {chatUI.showMessage("system", "connection lost")}<br />
}<br />
to receive(message) {chatUI.showMessage("friend", message)}<br />
to receiveFriend(friendRcvr) {<br />
bind friend := friendRcvr <br />
chatUI.showMessage("system", "friend has arrived")<br />
}<br />
to save(file) {file.setText(makeURIFromObject(chatController))}<br />
to load(file) {<br />
bind friend := getObjectFromURI(file.getText())<br />
friend <- receiveFriend(chatController)<br />
}<br />
}<br />
chatUI.show()<br />
# In actual code, the following line would not be commented out<br />
# interp.blockAtTop()</nowiki><br />
<br />
</code><br />
<br />
There are only 5 methods in making chat happen: sending a message to the friend, receiving a message from the friend, being informed that the friend has found you (the ''receivedFriend ''method), saving the URI where your friend can find you, and loading the URI that describes where you can find your friend.<br />
<br />
A quick run through can be done by putting the source in a file (file extension ".e-swt", this example uses SWT for user interface) and launching the file twice to get 2 chat windows. In one window, type "save ~/me.minchat" and press the Escape key. This creates a file (in your home directory) that contains a cap: URI describing where your chat session can be found (a chat session that can only be found by someone to whom this file has been given--the location cannot be found or guessed by anyone else). In the other window, type "load ~/me.minchat" and press Escape. In the first window you should see a message pop up that the "friend has arrived". Now in either window type "send hi y'all", and you will see the message appear in both windows.<br />
<br />
In minChat , every time you start up the program, it comes to life with a new uri that must be sent to the friend with whom you wish to chat; the old uri from the previous session is useless. MinChat would be far more useful if you could create a minChat session with Bob, and continue that session even after you have rebooted your computer. We look at building such a persistent chat in the chapter on Persistent Secure Distributed Computing--after first looking at minChat here through the eyes of a security reviewer (or a cybercracker) in the chapter on Secure Distributed Computing.<br />
<br />
===Patterns of Promises===<br />
<br />
====resolveAllVow====<br />
<br />
Note: this is available as '''<import:com.skyhunter.e.net.resolveAllVow>'''<br />
<br />
Suppose you have a computation that cannot be performed until you have received answers from multiple remote objects. Your first thought would be to use a multi-vow when-catch. But further suppose you do not know beforehand how many vows there are (i.e., suppose you have an arbitrary list of promises). In this case neither the multi-vow when-catch construct nor the nested when-catch pattern will work. For this situation, you can use the resolveAllVow utility described here.<br />
<br />
The resolveAllVow utility has another distinction compared to a multi-vow when-catch: whereas the multi-vow activates the catch clause as soon as it hits a broken promise, resolveAllVow sends no resolution until everything in the list is resolved one way or the other. So, even if several of the promises were broken, with resolveAllVow you can be sure that the rest have been fulfilled when the catch clause is activated.<br />
<br />
In this example, we use resolveAllVow to sum a list of contributions. We do not know beforehand how many contributions there are (perhaps thousands), and we want to sum them up even if some of the requests for donations return broken promises.<br />
<br />
E isBroken(obj) does not work. what does?<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
# Given a List of promises, when all the promises have been resolved,<br />
# resolve the returned vow, either fulfilling it with the list of fulfillments (if<br />
# all the promises were fulfilled) or by smashing the returned promise<br />
# with one of the broken promises (if at least one promise was broken). <br />
def resolveAllVow(promises) {<br />
def [resultVow, resolver] := Ref.promise()<br />
var count := promises.size()<br />
var resolution := promises<br />
var noneBroken := true<br />
if (count == 0) {resolver.resolve(promises)}<br />
for promise in promises {<br />
when (promise) -> {<br />
# success processed in finally clause<br />
} catch prob {<br />
resolution := prob<br />
noneBroken := false<br />
} finally {<br />
count -= 1<br />
if (count == 0) {<br />
if (noneBroken) {<br />
resolver.resolve(resolution)<br />
} else {resolver.smash(resolution)}<br />
}<br />
}<br />
}<br />
return resultVow<br />
}<br />
#now use the promiseAllResolved to sum contributions, where the<br />
#number of contributions is unknown prior to execution<br />
def printTotalContributions(amountsList) {<br />
var total := 0<br />
for each in amountsList {<br />
if (!(Ref.isBroken(each))) {total += each}<br />
}<br />
println(`Total contributions are: $total`)<br />
}<br />
# scaffold contributors: real contributors would be remote Rcvrs<br />
def makeContributer(donation) {<br />
return def contributor { to getDonation() :int {return donation} }<br />
}<br />
def contributorRcvrsList := [makeContributer(5), makeContributer(6)]<br />
def amountsVows := [].diverge()<br />
for each in contributorRcvrsList {<br />
amountsVows.push(each <- getDonation())<br />
}<br />
when (def amounts := resolveAllVow(amountsVows)) -> { <br />
printTotalContributions(amounts)<br />
} catch prob {<br />
#due to the nature of resolveAllVows, in this catch clause<br />
#we are guaranteed everything in amountsVows is resolved to <br />
#either an amount or a broken reference<br />
printTotalContributions(amountsVows)<br />
}</nowiki><br />
<br />
</pre><br />
<br />
The basic behavior of resolveAllVow is this: when initiated, the function takes a count of how many promises there are, then immediately spins off when-catches for all of them. Each time a promise resolves, the count of outstanding promises is decremented. When the counter drops to zero, implying all the promises have been resolved, the single promise initially returned by resolveAllVow is finally resolved.<br />
<br />
====dialogVowMaker====<br />
<br />
Java's standard dialog boxes, found in JOptionPane, are seriously flawed for use in a distributed <span class="e">''E''</span> system: those convenience dialogs are fully blocking. As a consequence, if your computer is part of a distributed computation, and you go home for the night, if a Java dialog box pops up, your machine is effectively offline until you return in the morning. Included in the <span class="e">''E''</span> distribution is a dialog box tool, the dialogVowMaker:<br />
<br />
<font color="#ff0000">code here</font><br />
<br />
====Recursion for send sequencing====<br />
<br />
As discussed earlier, putting a when-catch inside a for loop does not give you any guarantees on which when-catch will activate first: it only guarantees which message is sent first, which is mostly uninteresting. For general-purpose ensured sequencing of resolution, you must use recursion.<br />
<br />
Earlier, we had an example in which we told a list of cars to moveTo the same location. Suppose we wished to ensure that the cars arrived in the order in which they appear in the list:<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def moveAllCarsInSequence(carRcvrs,toX,toY) {<br />
var carI := 0<br />
def moveRemainingCars() {<br />
if (carI < carRcvrs.size()) {<br />
def nextCarRcvr := carRcvrs[carI]<br />
carI += 1<br />
def nameVow := nextCarRcvr <- getName()<br />
when (nameVow,nextCarRcvr <- moveTo(toX,toY)) -> {<br />
println(nameVow + " arrived, next car about to start moving")<br />
} catch e {<br />
println(`car died: $e`)<br />
} finally {moveRemainingCars()}<br />
}<br />
}<br />
moveRemainingCars()<br />
}<br />
# scaffold carmaker<br />
def makeCarRcvr(name) {<br />
def carRcvr {<br />
to getName() :String {return name}<br />
to moveTo(x, y) {<br />
#move the car<br />
}<br />
}<br />
return carRcvr<br />
}<br />
<br />
moveAllCarsInSequence([makeCarRcvr("car1"),makeCarRcvr("car2")],3,4) </nowiki><br />
<br />
</pre><br />
<br />
Inside the moveAllCarsInSequence function, we declare the recursive moveRemainingCars function, then simply invoke moveRemainingCars. The function moveRemainingCars tells the next car to move; once that movement has resolved, moveRemainingCars invokes itself once again.<br />
<br />
In this version of moveAllCarsInSequence, if a car is lost (i.e., its promise to move is broken), the recursion continues. If we wanted to abort after a problem occurred, we would simply delete the call to moveRemainingCars() from the finally clause, and place it in the when clause.<br />
<br />
====sendValve====<br />
<br />
As we have seen, it is possible to spin off large numbers of eventual sends in the blink of an eye. In fact, tossing off vast numbers of such sends can sometimes consume a lot of resources for no good purpose. In the eDesk program at the end of the book, it is possible for the user to request the transfer of whole directories full of files. It would be possible for eDesk to initiate transfer of all of those files simultaneously. But the processing bottleneck is probably bandwidth, so initiating them all at once won't get the whole transfer done any faster, and meanwhile each individual file transfer consumes buffer space once initiated. Starting all the transfers at once could actually slow down the transfer if enough buffers thrash virtual memory.<br />
<br />
What you want is a ''valve'', which can be opened and closed depending on the situation. The program can still set up all the operations in a single swoop, but the valve will constrain the number of such operations that are actually active at a given moment. The sendValve below performs this function.<br />
<br />
<pre><br />
<br />
<nowiki>#sendValve. If you have numerous eventual sends to initiate,<br />
# but initiating them all at once would consume vast resources<br />
# and/or would actually slow down processing, queue the actions <br />
# through a valve.<br />
#An ActionTrio is the list of [obj,"verb",[arguments]]<br />
# that can be used in an E send()<br />
#The actions are guaranteed to be initiated in the sequence in<br />
# which they are placed in the valve, though of course there is<br />
# no guarantee as to which will terminate first (unless you have<br />
# special knowledge of such sequencing outside the valve).<br />
#The numSimultaneousAllowed is the number of actions that can<br />
# be run concurrently through this valve.<br />
<br />
# E sample<br />
def makeSendValve (numSimultaneousAllowed) {<br />
var actionQueue := []<br />
var numRunning := 0<br />
def startNext() {<br />
if (!(actionQueue.size()==0)) {<br />
def [actionTrio, resolver] := actionQueue[0]<br />
actionQueue := actionQueue(1, actionQueue.size())<br />
numRunning += 1<br />
def completeVow := E.send(actionTrio[0],actionTrio[1],actionTrio[2])<br />
resolver.resolve(completeVow)<br />
when (completeVow) -> {<br />
} catch prob {<br />
} finally { <br />
numRunning -= 1 <br />
startNext()<br />
}<br />
}<br />
}<br />
def valve {<br />
to makeActionVow(actionTrio) {<br />
def [completeVow, resolver] := Ref.promise()<br />
actionQueue := actionQueue.with([actionTrio, resolver])<br />
if (numRunning < numSimultaneousAllowed) {<br />
startNext()<br />
}<br />
return completeVow<br />
}<br />
}<br />
return valve<br />
}</nowiki><br />
<br />
</pre><br />
<br />
The sendValve utility, if used with numSimultaneousAllowed==1, can also perform the send sequencing function described earlier. However, the earlier general send sequencing pattern is still useful. For example, if the moveAllCarsInSequence operation should abort upon a encountering a broken resolution, this version of sendValve would not give the correct result.<br />
<br />
====Summoning====<br />
<br />
====Transparent forwarder====<br />
<br />
It is possible to have a network of machines in which the machines do not all have direct access to one another. Suppose in the network with machine A, B, and C, A and C cannot form a direct connection because of network topology, but B can reach everything. If A needs a capability on C, we can put a transparent forwarder on B such that A sends its messages to the forwarder on B:<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def makeTransparentForwarder(representedRcvr) {<br />
def forwarder {<br />
match [verb,args] {E.send(representedRcvr,verb,args)}<br />
}<br />
return forwarder<br />
}</nowiki><br />
<br />
</pre><br />
<br />
Create the forwarder on B, and hand the reference to the forwarder to the appropriate object on A. An example can be found in the eDesk example at the end of the book, in which a forwarder is used if the system detects that two of the file servers are unable to directly connect. Note that the "delegate" keyword does not quite work here: delegate generates immediate calls, not eventual sends. So we had to revert to the more general purpose matching process.<br />
<br />
====acceptOnlyMoreRecentVow====<br />
<br />
Suppose you are periodically requesting a particular piece of information from a far object. Suppose the far object cannot supply the answer in a single game turn, i.e., it must ask other objects for information to get the answer, and so it sends you a promise rather than a result. It is possible for the resolutions of these promises to occur out-of-order, i.e., the resolution on the second request could get to you after the resolution of the third request has already occurred. In this situation, it will appear that the answer to the second request is newer and more up-to-date than the third request.<br />
<br />
<font color="#000000">In this situation, to ensure you are getting only new information, not stale information, use the acceptOnlyMoreRecentVow utility.</font><br />
<br />
<pre><br />
<br />
def acceptOnlyMoreRecentVow<br />
<br />
</pre><br />
<br />
<font color="#ff0000">code here</font><br />
<br />
This situation, while rare, actually arises in the Marketplace example in the Secure Distributed Computing chapter.<br />
<br />
<font color="#ff0000">something about time, the race construct, timeout construct</font><br />
<br />
====eDesk overwrite copy jewel====<br />
<br />
The following is not really a pattern so much as it is an example of all the more novel (i.e., not-like-Java) elements of <span class="e">''E''</span> playing together. The problem, taken from the eDesk program in the Examples at the end of the book, is this:<br />
<br />
example<br />
<br />
===Data Lock===<br />
<br />
Though <span class="e">''E''</span> is safe from deadlock, in which several objects compete for acquisition to a set of resources, there is a related dilemma that <span class="e">''E''</span> programs can encounter. If two or more "when" clauses wait for each other to resolve before they can resolve themselves, this causes ''data lock''. A complete discussion of data lock and why it is far less of a risk than deadlock is beyond the scope of this book. Briefly, both theory and current experience suggest that data locks are more difficult to create in the wild than deadlocks. Furthermore, when datalocks do occur, they are less likely to freeze up important subsystems on a grand scale: unlike the deadlock, they only choke a few "when" clauses, not a set of "critical sections" which have been named "critical" in thread programming for good reasons. And lastly, datalocks are consistent, reproducible, and therefore fixable, unlike the deadlocks that appear mysteriously when some incredibly arcane race condition occurs.<br />
<br />
Here is a simple though foolish example of datalock. It is the E implementation of the English sentence, "This sentence is false."<br />
<br />
<pre><br />
<br />
def sentence := sentence <- not()<br />
<br />
</pre><br />
<br />
In this construction, the sentence will forever be an unresolved promise. As noted above, the failure of this to resolve will not impede the progress of the rest of the program in the least. And it is very reliable: the unresolvability of the promise will appear the first time you run the program, and the second, and in every debugging pass thereafter.<br />
<br />
At the time of this writing, data lock has been seen only once in the wild. In that instance, a widely used object (call it WUO),contained one piece of mutable state and one piece of immutable state. The object that computed new versions of WUO's mutable state needed the immutable part of the state, and requested the current version of WUO from the owner of the object. Unfortunately, the owner knew that a new version was under construction, and was only sending out promises for WUO until the update was resolved. The solution in this case was to refactor WUO. This resulted in an architecture that was cleaner even by normal object design criteria, without regard to the distributed usage behavior. Insufficient data is yet available to assess how commonly this type of solution will suffice.<br />
<br />
<br />
Next Section: [[Walnut/Secure_Distributed_Computing|Secure Distributed Computing]]</div>Ansiblehttp://wiki.erights.org/wiki/Surprise_listSurprise list2011-04-20T18:55:37Z<p>Ansible: revert vandalism</p>
<hr />
<div>Potentially surprising parts of the [[E language]].<br />
<br />
Current as of [http://www.erights.org/download/0-8-29/ E 0.8.33o].<br />
<br />
==For-loop pattern failure is not an error==<br />
<br />
<!-- FIXME: link to erights.org for loop doc --><br />
<br />
If the key or value pattern of a <code>for</code> loop does not match, then the loop simply skips that element of the collection. This can be useful, but is unlike all other non-explicit pattern match operations (<code>def</code> and parameter lists).<br />
<br />
===Examples===<br />
<br />
# E sample<br />
<br />
? def things := [1, "two", 3]<br />
# value: [1, "two", 3]<br />
<br />
? for x :int in things { <br />
> println(x)<br />
> }<br />
# stdout: 1<br />
# 3<br />
# <br />
<br />
<br />
===Alternative===<br />
<br />
Move the pattern into a <code>def</code>:<br />
<br />
# E sample<br />
<br />
? for thing in things {<br />
> def x :int := thing<br />
> println(x)<br />
> }<br />
# stdout: 1<br />
# <br />
<br />
# problem: &lt;ClassCastException: String doesn't coerce to an int&gt;<br />
<br />
==<code>def x</code> doesn't return <var>x</var>==<br />
<br />
The forward declaration expression, <code>def <var>var</var></code>, does not return <var>var</var> but rather the [[Resolver]] for it.<br />
<br />
===Examples===<br />
<br />
# E sample<br />
<br />
? def x<br />
# value: &lt;Resolver&gt;<br />
<br />
? x<br />
# value: &lt;Promise&gt;<br />
<br />
===Rationale===<br />
<br />
If you want to pass a resolver as an argument, using it as an “out parameter”, this syntax is helpful:<br />
<br />
x.hereIsAResolver(def y)<br />
<var>... use y</var><br />
<br />
===Alternative===<br />
<br />
If you want the actual promise, simply write <code>(def x; x)</code>.<br />
<br />
==Unresolved references do not necessarily behave as their future resolved identity==<br />
<br />
&mdash; messages sent before the reference is resolved may be reacted to however the current holder of the reference &ldquo;arrow-head&rdquo; chooses, which does not necessarily correspond to the reference to which the unresolved reference resolves.<br />
<br />
This has been discussed in [http://www.eros-os.org/pipermail/e-lang/2005-July/010821.html an e-lang thread].<br />
<br />
===Rationale===<br />
<br />
This cannot be fixed without removing [http://www.erights.org/elib/distrib/pipeline.html pipelining], eliminating one of the major benefits of the E reference model.<br />
<br />
===Examples===<br />
<br />
For now, see [http://www.eros-os.org/pipermail/e-lang/2005-July/010827.html this lengthy example by MarkM].<br />
<br />
===Alternative===<br />
<br />
To avoid being vulnerable to this type of misbehavior, do not use a sameness test (<code>==</code>) or Map key lookup in order to decide on the reliability of the response to a ''previously'' sent message. This might involve using a when-catch/whenResolved construct to wait until the reference is resolved.<br />
<br />
==Accumulator operator is lowest-precedence==<br />
<br />
As you can see in the following expansion, the operator following the “_” is always lowest-precedence (as it is the one effectively rewritten into an assignment form):<br />
<br />
? e`pragma.enable("accumulator"); accum 0 while (a) { _ * b + c }`<br />
# value: e`null<br />
...<br />
# accum__1 := accum__1.multiply(b.add(c))<br />
...<br />
<br />
===Rationale===<br />
<br />
None known; this is probably an accident of the definition of the expansion of accumulator syntax.<br />
<br />
===Alternative===<br />
<br />
Avoid accumulator syntax when the accumulation cannot be expressed as a single call.<br />
<br />
<br />
<br />
== Shadowing function arguments ==<br />
<br />
Rebinding a name within a block is an error, e.g.<br />
<br />
def foo() {<br />
def x := 2<br />
def x := 3<br />
}<br />
<br />
("Failed: x already in scope")<br />
<br />
However, rebinding an argument does not issue any warning:<br />
<br />
def foo(x) {<br />
...<br />
def x := 2<br />
...<br />
println(x)<br />
}<br />
<br />
=== Rationale ===<br />
<br />
The already-in-scope error is intended to catch accidentally using the same name twice, not prohibit rebinding. Generally, you can expect it to be supressed anywhere there is visible <code>{...}</code> syntax.<br />
<br />
== Single-letter uriGetters are a special case ==<br />
<br />
It is not possible to refer to a single-letter uriGetter in a URI literal.<br />
<br />
? def <t> := ["foo" => "bar"]<br />
# value: ["foo" => "bar"]<br />
<br />
? interp.setExpand(true)<br />
? <t:foo><br />
# expansion: file__uriGetter.get("t:foo")<br />
<br />
# value: <file:/Users/kpreid/t:foo><br />
<br />
===Rationale===<br />
<br />
This is a feature intended for convenient support for Windows drive letter filenames. {{XXX|Look at whether MarkM agreed to remove it.}}<br />
<br />
===Alternative===<br />
<br />
Use names longer than one letter.<br />
<br />
[[Category:E language]]</div>Ansiblehttp://wiki.erights.org/wiki/Category:Message_diverge/*Category:Message diverge/*2011-04-20T17:17:13Z<p>Ansible: revert vandalism</p>
<hr />
<div>{{verb category|diverge}}</div>Ansiblehttp://wiki.erights.org/wiki/Walnut/Distributed_Computing/Testing_for_Equality_in_a_Distributed_SystemWalnut/Distributed Computing/Testing for Equality in a Distributed System2011-04-20T17:16:43Z<p>Ansible: revert vandalism</p>
<hr />
<div>pplQLr With the bases loaded you struck us out with that asnewr!<br />
<br />
===Making your own Promises===<br />
<br />
If you write a function or method that must get values from a far object before returning an answer, your function should return a promise for the answer, and fulfill that answer later. You can create your own promises using Ref.promise() in <span class="e">''E''</span><nowiki>:</nowiki><br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def calcMilesBeforeEmptyVow(carRcvr) {<br />
def [milesBeforeEmptyPromise, milesBeforeEmptyResolver] := Ref.promise()<br />
def fuelRemainingVow := carRcvr <- getFuelRemaining()<br />
def mpgVow := carRcvr <- getEfficiency()<br />
when (fuelRemainingVow, mpgVow) -> {<br />
milesBeforeEmptyResolver.resolve(mpgVow * fuelRemainingVow)<br />
} catch prob {<br />
milesBeforeEmptyResolver.smash(`Car Lost: $prob`)<br />
}<br />
return milesBeforeEmptyPromise<br />
}<br />
<br />
#....Meanwhile, somewhere else in the program....<br />
def myCar {<br />
to getFuelRemaining() {return 5}<br />
to getEfficiency() {return 2}<br />
}<br />
def milesVow := calcMilesBeforeEmptyVow(myCar)<br />
when (milesVow) -> {<br />
println(`miles before empty = $milesVow`)<br />
} catch e {println(`Error: $e`)}</nowiki><br />
<br />
</pre><br />
<br />
This example highlights several different features of promises. The basic idea of the example is that the function calcMilesBeforeEmptyVow(carRcvr) will eventually compute the number of miles the car can still travel before it is out of fuel; later in the program, when this computation is resolved, the program will print the value. However, before we can do the computation, we must first get both the fuelRemaining and the milesPerGallon values from the remote car.<br />
<br />
The promise and the resolver for that promise are created as a pair using Ref.promise(). They are "normal" variables in the sense that they can be passed as arguments, returned from methods as answers, and sent eventual messages. Resolvers truly are ordinary objects. There are 3 restrictions on the promises: they cannot accept immediate calls, they cannot be tested for equality, and they cannot be used as keys in hash tables.<br />
<br />
In this example, the function returns the milesBeforeEmptyPromise to the caller just as it would return any other kind of value. To cause the promise to resolve, the function calls the resolver (or sends to the resolver if the resolver may be remote to your program) with the "resolve(value)" method. To break the promise (which produces a problem that will cause the catch clause of a when-catch to execute), call the resolver with the "smash(problem)" method.<br />
<br />
It is possible to chain resolutions: you can resolve a promise by handing the resolver another promise (though if you hand the resolver the promise which it is intended to resolve, <span class="e">''E''</span> will detect the problem and automatically break the promise--a promise resolved to itself can never be fulfilled). If you resolve a promise with another promise, the original promise is not yet considered resolved, i.e., the when-catch body will not be activated by such a resolution. The when-catch body will only be activated when the entire promise chain is resolved, and there is an actual reference to an actual object available.</div>Ansiblehttp://wiki.erights.org/wiki/SandboxSandbox2010-02-15T13:48:54Z<p>Ansible: all good men test</p>
<hr />
<div>[[Agoric opaque box]]<br />
[[Capability-based Active Invocation Certificates]]<br />
----<br />
<br />
Walnut is here:<br />
[[Walnut]]<br />
<br />
<nowiki>pragma.syntax(&quot;0.9&quot;)</nowiki><br />
<br />
<nowiki><b>Using</b> nowiki</nowiki><br />
<br />
<pre><b>Using</b> pre instead of nowiki</pre><br />
normal text<br />
<code><b>Using</b> code instead of nowiki</code><br />
more normal text<br />
<nowiki><pre><b>Using</b> pre inside of nowiki</pre></nowiki><br />
<br />
<pre><nowiki><b>Using</b> nowiki inside of pre</nowiki></pre><br />
<br />
&quot;This is in quotes.&quot;<br />
<br />
<br />
----<br />
<br />
How to do interwiki links:<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[wiki:EeLanguage|'''''E''''' on the C2 wiki]]<br />
<br />
----<br />
<br />
And now for something completely different.<br />
<br />
[[Security Shootout]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[[Object-capability operating systems]]<br />
<br />
[[Cryptographic-capability protocols]]<br />
<br />
[[Distributed object-capability systems]]<br />
<br />
[[Standard updoc prelude]]<br />
<br />
[[Standard updoc prelude for awt and swing]]<br />
<br />
[[Standard updoc prelude for swt]]<br />
<br />
[[Horton]]<br />
<br />
-----<br />
<br />
It's that classic love triangle: [[Image:erights_send.gif]]<br />
<br />
-----<br />
<br />
This is just some anonymous text.<br />
<br />
And this is an anonymous link: http://www.google.com<br />
<br />
And logged in as 'me', this should be fine: http://www.yahoo.com<br />
<br />
-----<br />
<br />
And now is the time for all good men to come to the aid of their country.<br />
------<br />
<br />
From icanhascheezburger.com:<br />
<br />
[[Image:4chan_shiny_device.jpg]]</div>Ansiblehttp://wiki.erights.org/wiki/DevelopmentDevelopment2010-02-12T19:38:58Z<p>Ansible: added gitorious repo</p>
<hr />
<div>== Source Code ==<br />
<br />
=== Official Subversion Repository ===<br />
<br />
If you wish to obtain an official stable release of '''''E''''', see the [[Downloads]] page.<br />
<br />
The '''''E''''' sources and the erights.org website are both maintained in [[wikipedia:Subversion|Subversion]]. If you have a Subversion client, you can check out the latest '''''E''''' sources by doing, for example,<br />
<br />
$ svn co svn://svn.synchrona.org/erights/e/trunk e<br />
<br />
You can obtain the erights.org website by doing<br />
<br />
$ svn co svn://svn.synchrona.org/erights/doc doc<br />
<br />
=== Unofficial Git Repository ===<br />
<br />
http://gitorious.org/repo-roscidus/e-core<br />
<br />
== Bug Tracking ==<br />
<br />
[https://sourceforge.net/tracker/?func=add&group_id=75274&atid=551529 '''''E''''' Bug Tracking on SourceForge]<br />
<br />
== Design and Future Directions ==<br />
<br />
[[:Category:Unresolved design issues|Unresolved Design Issues]]<br />
<br />
== Development Environments ==<br />
<br />
[[E Under Eclipse|'''''E''''' Under Eclipse]]<br />
<br />
[http://code.google.com/p/nbe-lang/ NetBeans support for '''''E''''']</div>Ansiblehttp://wiki.erights.org/wiki/Talk:DevelopmentTalk:Development2009-07-13T17:02:28Z<p>Ansible: low priority note to MarkM about IntellJ setup</p>
<hr />
<div>MarkM: it is rumored that you use IntellJ for development. If you still do, and have any setup instructions or configuration files, please consider linking them here. --[[User:Ansible|Ansible]] 12:02, 13 July 2009 (CDT)</div>Ansiblehttp://wiki.erights.org/wiki/Erights:Community_PortalErights:Community Portal2009-07-13T16:59:31Z<p>Ansible: re-word whiteboards description</p>
<hr />
<div>[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to '''''E''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
[[Whiteboards]] - Discussion of ideas and other works in progress.</div>Ansiblehttp://wiki.erights.org/wiki/Main_PageMain Page2009-07-13T16:57:06Z<p>Ansible: move whiteboards to Community subsection</p>
<hr />
<div>__NOTOC__<br />
<big>'''Welcome to the ERights.org wiki.'''</big><br />
<br />
E is an [[wikipedia:Object-capability model|object-capability]] programming language and platform for writing [[wikipedia:Distributed computing|distributed]], secure, and robust software. This wiki is about E and the larger subject of [[wikipedia:Capability-based security|capability-based security]].<br />
<br />
== [[Getting Started]] ==<br />
<br />
[[Getting Started]] - Tips for '''''E''''' newbies<br />
<br />
== What's New? ==<br />
<br />
[http://www.erights.org/talks/index.html#google-abac Google Techtalk series on ABAC] - Authorization Based Access Control.<br />
<br />
[[Future research topics]]<br />
<br />
== [[Documentation]] ==<br />
<br />
* [[Documentation#Books|Books]]<br />
** [[Walnut|'''''E''''' in a Walnut]]<br />
* [[Documentation#Tutorials|Tutorials]]<br />
* [[FAQ]]<br />
* [[Documentation#Papers|Papers]]<br />
* [[Documentation#Talks and Presentations|Talks and Presentations]]<br />
<br />
== [[Downloads]] ==<br />
<br />
* [[Downloads#Releases|Releases]] - ready-to-install versions of '''''E'''''.<br />
<br />
==[[:Category:Applications|Applications]]==<br />
<br />
== [[Erights:Community Portal|Community]] ==<br />
<br />
[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the [http://www.mibbit.com/?server=irc.freenode.net&channel=%23erights #erights] IRC channel at irc.freenode.net, you can talk to a running instance of '''''E ''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
[[Whiteboards]] - Discussion of ideas and other works in progress.<br />
<br />
==[[Development]]==<br />
* [[Downloads#Subversion|Subversion Repository]] — development branch<br />
* [[:Category:Unresolved design issues|Unresolved design issues]] — things that need thinking about<br />
<br />
== [[Related Sites]] ==<br />
<br />
[http://www.erights.org Main Erights.org site]<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[http://rosettacode.org/wiki/Category:E '''''E''''' on Rosetta Code]<br />
<br />
[[Object-capability languages]]<br />
<br />
[http://www.combex.com/ Combex, Inc.] - The for-profit facet of the '''''E''''' project, featuring [[CapDesk]] -- the capability secure desktop, and [[caplet]] installation and launching framework.</div>Ansiblehttp://wiki.erights.org/wiki/Erights:Community_PortalErights:Community Portal2009-07-13T16:54:16Z<p>Ansible: link to whiteboards</p>
<hr />
<div>[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to '''''E''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
[[Whiteboards]] are pages that members of various E and Capabilities discussions can hash stuff out upon.</div>Ansiblehttp://wiki.erights.org/wiki/SandboxSandbox2008-07-10T16:52:01Z<p>Ansible: shiny device</p>
<hr />
<div>Walnut is here:<br />
[[Walnut]]<br />
<br />
<nowiki>pragma.syntax(&quot;0.9&quot;)</nowiki><br />
<br />
<nowiki><b>Using</b> nowiki</nowiki><br />
<br />
<pre><b>Using</b> pre instead of nowiki</pre><br />
normal text<br />
<code><b>Using</b> code instead of nowiki</code><br />
more normal text<br />
<nowiki><pre><b>Using</b> pre inside of nowiki</pre></nowiki><br />
<br />
<pre><nowiki><b>Using</b> nowiki inside of pre</nowiki></pre><br />
<br />
&quot;This is in quotes.&quot;<br />
<br />
<br />
----<br />
<br />
How to do interwiki links:<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[wiki:EeLanguage|'''''E''''' on the C2 wiki]]<br />
<br />
----<br />
<br />
And now for something completely different.<br />
<br />
[[Security Shootout]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[[Object-capability operating systems]]<br />
<br />
[[Cryptographic-capability protocols]]<br />
<br />
[[Distributed object-capability systems]]<br />
<br />
[[Standard updoc prelude]]<br />
<br />
[[Standard updoc prelude for awt and swing]]<br />
<br />
[[Standard updoc prelude for swt]]<br />
<br />
[[Horton]]<br />
<br />
-----<br />
<br />
It's that classic love triangle: [[Image:erights_send.gif]]<br />
<br />
-----<br />
<br />
This is just some anonymous text.<br />
<br />
And this is an anonymous link: http://www.google.com<br />
<br />
And logged in as 'me', this should be fine: http://www.yahoo.com<br />
<br />
------<br />
<br />
From icanhascheezburger.com:<br />
<br />
[[Image:4chan_shiny_device.jpg]]</div>Ansiblehttp://wiki.erights.org/wiki/DevelopmentDevelopment2008-07-09T21:02:49Z<p>Ansible: /* Development Environments */ NetBeans</p>
<hr />
<div>== Source Code ==<br />
<br />
If you wish to obtain an official stable release of '''''E''''', see the [[Downloads]] page.<br />
<br />
The '''''E''''' sources and the erights.org website are both maintained in [[wikipedia:Subversion|Subversion]]. If you have a Subversion client, you can check out the latest '''''E''''' sources by doing, for example,<br />
<br />
$ svn co svn://svn.synchrona.org/erights/e/trunk e<br />
<br />
You can obtain the erights.org website by doing<br />
<br />
$ svn co svn://svn.synchrona.org/erights/doc doc<br />
<br />
== Bug Tracking ==<br />
<br />
[https://sourceforge.net/tracker/?func=add&group_id=75274&atid=551529 '''''E''''' Bug Tracking on SourceForge]<br />
<br />
== Design and Future Directions ==<br />
<br />
[[:Category:Unresolved design issues|Unresolved Design Issues]]<br />
<br />
== Development Environments ==<br />
<br />
[[E Under Eclipse|'''''E''''' Under Eclipse]]<br />
<br />
[http://code.google.com/p/nbe-lang/ NetBeans support for '''''E''''']</div>Ansiblehttp://wiki.erights.org/wiki/Talk:Main_PageTalk:Main Page2008-07-07T20:12:41Z<p>Ansible: </p>
<hr />
<div>== Goals for the Main Page ==<br />
<br />
I've been trying to keep the main page as short and concise as possible. We need to keep in mind the users of this site. The main page is, in a sense, the main user interface for the wiki... it is how people start using the 'application'. So I'll be trying very hard to keep only the most important and relevant stuff on the main page. --[[User:Ansible|Ansible]] 11:32, 28 March 2007 (CDT)<br />
<br />
In fact, either on the main page, or on the getting started page, I'd like to have a 1 (one!) paragraph summary of '''''E''''' and why it the greatest thing since sliced bread. And then 3 or so paragraphs of further explaination. Perhaps we need to have an updated FAQ, and the first question answers this. --[[User:Ansible|Ansible]] 11:37, 28 March 2007 (CDT)<br />
<br />
I just starded the [[FAQ]]. I'll try to hack in as many questions as I can think of. --[[User:mscheffler|mscheffler]] 12:43, 21 April 2007 (CDT)<br />
<br />
== '''''E''''' vs. E==<br />
<br />
There seems to be a difference of opinion on how to write '''''E''''' on wiki pages. In some of the original documentatin on erights.org, I've seen it shown as in an italic and green font. We don't have easy wiki markup for colors, so I've always been just using the '''bold''' and ''italic'' markup together for the letter 'E' when it refers to the programming language. However, this is not the only view, and Kevin seems to prefer just a plain 'E'. Can we create a consensus on how to display 'E'? --[[User:Ansible|Ansible]] 05:50, 4 July 2008 (CDT)<br />
<br />
I'd suggest creating a template page, Template:E. Put in that page the wikitext for how we want the name of this language to be rendered. Then in other pages, simply transclude the template, i.e. write <nowiki>{{E}}</nowiki> for the language name. This would ensure consistency and be at least as simple as <nowiki>'''''E'''''</nowiki>. --[[User:Toby.murray|Toby.murray]] 07:57, 4 July 2008 (CDT)<br />
<br />
I've just created a demo templte, using my user talk page. Use it by writing <nowiki>{{:User_talk:Toby.murray}}</nowiki> somewhere, like here: {{User_talk:Toby.murray}}, or {{User_talk:Toby.murray}} there. --[[User:Toby.murray|Toby.murray]] 08:05, 4 July 2008 (CDT)<br />
* Nice, I like it. --[[User:Ansible|Ansible]] 15:12, 7 July 2008 (CDT)</div>Ansiblehttp://wiki.erights.org/wiki/Talk:Main_PageTalk:Main Page2008-07-04T10:50:41Z<p>Ansible: '''''E''''' vs. E</p>
<hr />
<div>== Goals for the Main Page ==<br />
<br />
I've been trying to keep the main page as short and concise as possible. We need to keep in mind the users of this site. The main page is, in a sense, the main user interface for the wiki... it is how people start using the 'application'. So I'll be trying very hard to keep only the most important and relevant stuff on the main page. --[[User:Ansible|Ansible]] 11:32, 28 March 2007 (CDT)<br />
<br />
In fact, either on the main page, or on the getting started page, I'd like to have a 1 (one!) paragraph summary of '''''E''''' and why it the greatest thing since sliced bread. And then 3 or so paragraphs of further explaination. Perhaps we need to have an updated FAQ, and the first question answers this. --[[User:Ansible|Ansible]] 11:37, 28 March 2007 (CDT)<br />
<br />
I just starded the [[FAQ]]. I'll try to hack in as many questions as I can think of. --[[User:mscheffler|mscheffler]] 12:43, 21 April 2007 (CDT)<br />
<br />
== '''''E''''' vs. E==<br />
<br />
There seems to be a difference of opinion on how to write '''''E''''' on wiki pages. In some of the original documentatin on erights.org, I've seen it shown as in an italic and green font. We don't have easy wiki markup for colors, so I've always been just using the '''bold''' and ''italic'' markup together for the letter 'E' when it refers to the programming language. However, this is not the only view, and Kevin seems to prefer just a plain 'E'. Can we create a consensus on how to display 'E'? --[[User:Ansible|Ansible]] 05:50, 4 July 2008 (CDT)</div>Ansiblehttp://wiki.erights.org/wiki/User_talk:DglibickiUser talk:Dglibicki2008-06-23T19:16:44Z<p>Ansible: Markup on Heftza page</p>
<hr />
<div>Hello Daniel. When you have time, please wikify the [[Heftza]] page. The markup you're using now is not for MediaWiki. If you have questions or need help, please discuss this on the e-lang mailing list. Thanks. --[[User:Ansible|Ansible]] 14:16, 23 June 2008 (CDT)</div>Ansiblehttp://wiki.erights.org/wiki/Joe-EJoe-E2008-06-04T15:23:50Z<p>Ansible: added paper "Verifiable functional purity in Java"</p>
<hr />
<div>Joe-E is a subset of the [[wikipedia:Java_%28programming_language%29|Java programming langauge]] designed to support programming according to object-capability discipline.<br />
<br />
The language guarantees additional security properties by placing restrictions on Java code, but does not modify programs or change their meaning. This allows programmers' existing knowledge of Java to be applied and existing compilers, debuggers, and other tools to be used with Joe-E programs. <br />
<br />
== Papers ==<br />
<br />
* [http://www.cs.berkeley.edu/~amettler/purecomp.pdf Verifiable functional purity in Java] - by Matthew Finifter, Adrian Mettler, Naveen Sastry, David Wagner<br />
<br />
== Links ==<br />
<br />
* [http://joe-e.googlecode.com/ Joe-E Home Page]<br />
* [http://code.google.com/p/joe-e/wiki/GettingStarted Getting Started with Joe-E]<br />
* [http://eclipse.joe-e.org/ Eclipse plug-in]<br />
* [http://www.cs.berkeley.edu/~daw/joe-e/ Original Joe-E Home Page]</div>Ansiblehttp://wiki.erights.org/wiki/Object-capability_languagesObject-capability languages2008-05-30T21:12:38Z<p>Ansible: updated link for foolscap</p>
<hr />
<div>== Independent or Prior Objcap Languages ==<br />
<br />
* [http://www.erights.org/history/morris73.pdf Gedanken]<br />
* [http://www.erights.org/history/actors.html Actors]<br />
* [http://portal.acm.org/ft_gateway.cfm?id=323739&type=pdf Vulcan],<br />
* [http://www.agorics.com/Library/joule.html Joule]<br />
* [http://mumble.net/~jar/pubs/secureos/ W7]<br />
* [http://portal.acm.org/citation.cfm?doid=323627.323646 Eden, Emerald]<br />
* [http://citeseer.ist.psu.edu/279442.html J-Kernel]<br />
* [http://plash.beasts.org Plash]<br />
* [http://prog.vub.ac.be/amop/ AmbientTalk]<br />
* [http://www.erlang.org/ Erlang] - Erlang is almost, but not quite an object-capability language.<br />
<br />
== Related to '''''E''''' ==<br />
{| <br />
|+Relationships of '''''E''''' and other languages<br />
! Base language !! '''''E''''' Implementation !! Adapted to objcaps<br />
|-<br />
| [http://java.sun.com Java] || [http://erights.org/download/ E-on-Java] || [[Joe-E]] [http://waterken.sourceforge.net/ Waterken] [http://asyncobjects.sourceforge.net/ AsyncObjects]<br />
|-<br />
| [http://www.mozart-oz.org/ Mozart/Oz] || || [http://www.info.ucl.ac.be/people/PVR/oze.pdf Oz-E]<br />
|-<br />
| C/C++ || [http://erights.org/e-impls/e-on-c/index.html MC] || <br />
|-<br />
| [http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html Smallcaps] || [http://erights.org/e-impls/e-on-smallcaps/index.html E-on-Smallcaps] || <br />
|-<br />
| [http://www.squeak.org/ Squeak] || [http://erights.org/e-impls/e-on-squeak/index.html E-on-Squeak] || [http://www.squeaksource.com/SecureSqueak.html SecureSqueak] [http://wiki.squeak.org/squeak/6011 SqueakElibVM]<br />
|-<br />
| Common Lisp || [http://erights.org/e-impls/e-on-cl/index.html E-on-CL] || [http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html CL-E]<br />
|-<br />
| [http://caml.inria.fr/ocaml/index.en.html OCaml] || || [[Emily]]<br />
|-<br />
| [http://www.haskell.org/ Haskell] || [http://homepage.mac.com/kpreid/elang/ E-on-Haskell] || [http://code.google.com/p/caskell/ Caskell]<br />
|-<br />
| Python || || [http://twistedmatrix.com/ Twisted Python] [http://foolscap.lothar.com/trac FoolsCap] [http://www.cs.ubc.ca/~drifty/papers/python_security.pdf Secure Python]<br />
|-<br />
| Perl || || [http://caperl.links.org/ CaPerl]<br />
|-<br />
| [http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html Pict] || || [http://altair.sk/mediawiki/index.php/Tamed_Pict Tamed Pict]<br />
|-<br />
| E || E-on-E ||<br />
|-<br />
| || || [http://sebyla.sourceforge.net/ Sebyla]<br />
|-<br />
| Javascript || || [http://code.google.com/p/google-caja/ Caja] [http://www.adsafe.org/ ADsafe] [http://wiki.developers.facebook.com/index.php/FBJS FBJS][http://video.google.com/videoplay?docid=452089494323007214 Vats on Gears]<br />
|}<br />
<br />
<br />
Also applicable to ML and Haskell style systems: [http://okmij.org/ftp/papers/lightweight-static-capabilities.pdf Lightweight Static Capabilities]</div>Ansiblehttp://wiki.erights.org/wiki/Standard_updoc_preludeStandard updoc prelude2008-05-09T17:11:43Z<p>Ansible: </p>
<hr />
<div>The following line<br />
<code><br />
? pragma.syntax("0.9")<br />
</code><br />
declares to [[updoc]] that further updoc passages on this page are in '''''E''''' 0.9 syntax.</div>Ansiblehttp://wiki.erights.org/wiki/User_talk:ZarutianUser talk:Zarutian2008-04-03T15:39:55Z<p>Ansible: </p>
<hr />
<div>The 'discussion' pages are also appropriate places to ask questions or keep notes. But I agree with Kevin, the e-lang mailing list should probably be your first resort when there are questions. --[[User:Ansible|Ansible]] 10:39, 3 April 2008 (CDT)</div>Ansiblehttp://wiki.erights.org/wiki/Main_PageMain Page2008-03-24T18:38:22Z<p>Ansible: </p>
<hr />
<div>__NOTOC__<br />
<big>'''Welcome to the ERights.org wiki.'''</big><br />
<br />
'''''E''''' is a secure, [[wikipedia:Distributed computing|distributed]], [[wikipedia:Object-oriented programming|pure-object]] platform and [[wikipedia:Peer-to-peer|P2P]] scripting language for writing [[wikipedia:Object-capability model|''Capability-based'']] [[Smart Contract]]s.<br />
<br />
== [[Getting Started]] ==<br />
<br />
[[Getting Started]] - Tips for '''''E''''' newbies<br />
<br />
== What's New? ==<br />
<br />
[http://www.erights.org/talks/index.html#google-abac Google Techtalk series on ABAC] - Authorization Based Access Control.<br />
<br />
[[Future research topics]]<br />
<br />
== [[Documentation]] ==<br />
<br />
* [[Documentation#Books|Books]]<br />
** [[Walnut|'''''E''''' in a Walnut]]<br />
* [[Documentation#Tutorials|Tutorials]]<br />
* [[FAQ]]<br />
* [[Documentation#Papers|Papers]]<br />
* [[Documentation#Talks and Presentations|Talks and Presentations]]<br />
<br />
== [[Downloads]] ==<br />
<br />
* [[Downloads#Releases|Releases]] - ready-to-install versions of '''''E'''''.<br />
<br />
==[[:Category:Applications|Applications]]==<br />
<br />
== [[Erights:Community Portal|Community]] ==<br />
<br />
[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to a running instance of '''''E ''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
==[[Development]]==<br />
* [[Downloads#Subversion|Subversion Repository]] - development branch<br />
<br />
== [[Related Sites]] ==<br />
<br />
[http://www.erights.org Main Erights.org site]<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[http://www.combex.com/ Combex, Inc.] - The for-profit facet of the '''''E''''' project, featuring [[CapDesk]] -- the capability secure desktop, and [[caplet]] installation and launching framework.</div>Ansiblehttp://wiki.erights.org/wiki/Smart_ContractsSmart Contracts2008-03-24T18:36:47Z<p>Ansible: Smart Contracts moved to Smart Contract: normalize name</p>
<hr />
<div>#REDIRECT [[Smart Contract]]</div>Ansiblehttp://wiki.erights.org/wiki/Smart_ContractSmart Contract2008-03-24T18:36:47Z<p>Ansible: Smart Contracts moved to Smart Contract: normalize name</p>
<hr />
<div>A Smart Contract is an on-line cooperative arrangement between mutually suspicious parties.<br />
<br />
These are normally implemented using cryptographic protocols to ensure many of the typical properties of real-world contracts.<br />
<br />
Smart Contracts were initially conceived by Nick Szabo.<br />
<br />
== Related Links ==<br />
<br />
[http://www.cypherpunks.to/erights/smart-contracts/index.html Smart Contracts on the erights.org website.]<br />
<br />
[http://www.cypherpunks.to/erights/elib/capability/ode/index.html Capability-based Financial Instruments]</div>Ansiblehttp://wiki.erights.org/wiki/DownloadsDownloads2008-03-07T20:07:06Z<p>Ansible: move development stuff to Development</p>
<hr />
<div>== Releases ==<br />
<br />
[http://www.erights.org/download/index.html E-on-Java Download Page] - licensed under Mozilla or Mozilla compatible open source license.<br />
<br />
[http://homepage.mac.com/kpreid/elang/e-on-cl/ E on Common Lisp] - Kevin Reid's implementation of '''''E''''' on [[wikipedia:Common Lisp|Common Lisp]].<br />
<br />
The current [[Development|development]] version of '''''E''''' is stored in [[Development#Source Code|a Subversion repository]].</div>Ansiblehttp://wiki.erights.org/wiki/Main_PageMain Page2008-03-07T20:01:34Z<p>Ansible: move subversion to the development section</p>
<hr />
<div>__NOTOC__<br />
<big>'''Welcome to the ERights.org wiki.'''</big><br />
<br />
'''''E''''' is a secure, [[wikipedia:Distributed computing|distributed]], [[wikipedia:Object-oriented programming|pure-object]] platform and [[wikipedia:Peer-to-peer|P2P]] scripting language for writing [[wikipedia:Object-capability model|''Capability-based'']] [[Smart Contracts]].<br />
<br />
== [[Getting Started]] ==<br />
<br />
[[Getting Started]] - Tips for '''''E''''' newbies<br />
<br />
== What's New? ==<br />
<br />
[http://www.erights.org/talks/index.html#google-abac Google Techtalk series on ABAC] - Authorization Based Access Control.<br />
<br />
[[Future research topics]]<br />
<br />
== [[Documentation]] ==<br />
<br />
* [[Documentation#Books|Books]]<br />
** [[Walnut|'''''E''''' in a Walnut]]<br />
* [[Documentation#Tutorials|Tutorials]]<br />
* [[FAQ]]<br />
* [[Documentation#Papers|Papers]]<br />
* [[Documentation#Talks and Presentations|Talks and Presentations]]<br />
<br />
== [[Downloads]] ==<br />
<br />
* [[Downloads#Releases|Releases]] - ready-to-install versions of '''''E'''''.<br />
<br />
==[[:Category:Applications|Applications]]==<br />
<br />
== [[Erights:Community Portal|Community]] ==<br />
<br />
[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to a running instance of '''''E ''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
==[[Development]]==<br />
* [[Downloads#Subversion|Subversion Repository]] - development branch<br />
<br />
== [[Related Sites]] ==<br />
<br />
[http://www.erights.org Main Erights.org site]<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[http://www.combex.com/ Combex, Inc.] - The for-profit facet of the '''''E''''' project, featuring [[CapDesk]] -- the capability secure desktop, and [[caplet]] installation and launching framework.</div>Ansiblehttp://wiki.erights.org/wiki/Main_PageMain Page2008-03-07T20:00:23Z<p>Ansible: Change top-level applications link to the category page</p>
<hr />
<div>__NOTOC__<br />
<big>'''Welcome to the ERights.org wiki.'''</big><br />
<br />
'''''E''''' is a secure, [[wikipedia:Distributed computing|distributed]], [[wikipedia:Object-oriented programming|pure-object]] platform and [[wikipedia:Peer-to-peer|P2P]] scripting language for writing [[wikipedia:Object-capability model|''Capability-based'']] [[Smart Contracts]].<br />
<br />
== [[Getting Started]] ==<br />
<br />
[[Getting Started]] - Tips for '''''E''''' newbies<br />
<br />
== What's New? ==<br />
<br />
[http://www.erights.org/talks/index.html#google-abac Google Techtalk series on ABAC] - Authorization Based Access Control.<br />
<br />
[[Future research topics]]<br />
<br />
== [[Documentation]] ==<br />
<br />
* [[Documentation#Books|Books]]<br />
** [[Walnut|'''''E''''' in a Walnut]]<br />
* [[Documentation#Tutorials|Tutorials]]<br />
* [[FAQ]]<br />
* [[Documentation#Papers|Papers]]<br />
* [[Documentation#Talks and Presentations|Talks and Presentations]]<br />
<br />
== [[Downloads]] ==<br />
<br />
* [[Downloads#Releases|Releases]] - ready-to-install versions of '''''E'''''.<br />
* [[Downloads#Subversion|Subversion]] - development code<br />
<br />
==[[:Category:Applications|Applications]]==<br />
<br />
== [[Erights:Community Portal|Community]] ==<br />
<br />
[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to a running instance of '''''E ''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
==[[Development]]==<br />
<br />
== [[Related Sites]] ==<br />
<br />
[http://www.erights.org Main Erights.org site]<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[http://www.combex.com/ Combex, Inc.] - The for-profit facet of the '''''E''''' project, featuring [[CapDesk]] -- the capability secure desktop, and [[caplet]] installation and launching framework.</div>Ansiblehttp://wiki.erights.org/wiki/DevelopmentDevelopment2008-03-05T23:03:27Z<p>Ansible: </p>
<hr />
<div>== Source Code ==<br />
<br />
If you wish to obtain an official stable release of '''''E''''', see the [[Downloads]] page.<br />
<br />
The '''''E''''' sources and the erights.org website are both maintained in [[wikipedia:Subversion|Subversion]]. If you have a Subversion client, you can check out the latest '''''E''''' sources by doing, for example,<br />
<br />
$ svn co svn://svn.synchrona.org/erights/e/trunk e<br />
<br />
You can obtain the erights.org website by doing<br />
<br />
$ svn co svn://svn.synchrona.org/erights/doc doc<br />
<br />
== Bug Tracking ==<br />
<br />
[https://sourceforge.net/tracker/?func=add&group_id=75274&atid=551529 E Bug Tracking on SourceForge]<br />
<br />
== Design and Future Directions ==<br />
<br />
[[:Category:Unresolved design issues|Unresolved Design Issues]]</div>Ansiblehttp://wiki.erights.org/wiki/DevelopmentDevelopment2008-03-05T23:02:57Z<p>Ansible: Not sure how to linkify a code example, so deleting the ref to TortiseSVN for now.</p>
<hr />
<div>== Source Code ==<br />
<br />
If you wish to obtain an official stable release of '''''E''''', see the [[Downloads]] page.<br />
<br />
The E sources and the erights.org website are both maintained in [[wikipedia:Subversion|Subversion]]. If you have a Subversion client, you can check out the latest E sources by doing, for example,<br />
<br />
$ svn co svn://svn.synchrona.org/erights/e/trunk e<br />
<br />
You can obtain the erights.org website by doing<br />
<br />
$ svn co svn://svn.synchrona.org/erights/doc doc<br />
<br />
== Bug Tracking ==<br />
<br />
[https://sourceforge.net/tracker/?func=add&group_id=75274&atid=551529 E Bug Tracking on SourceForge]<br />
<br />
== Design and Future Directions ==<br />
<br />
[[:Category:Unresolved design issues|Unresolved Design Issues]]</div>Ansiblehttp://wiki.erights.org/wiki/DevelopmentDevelopment2008-03-05T21:15:47Z<p>Ansible: Unredirected Development page, added sections for source code and bug tracking.</p>
<hr />
<div>== Source Code ==<br />
<br />
If you wish to obtain an official stable release of '''''E''''', see the [[Downloads]] page.<br />
<br />
The E sources and the erights.org website are both maintained in [[wikipedia:Subversion|Subversion]]. If you have a Subversion client, you can check out the latest E sources by doing, for example,<br />
<br />
$ svn co svn://svn.synchrona.org/erights/e/trunk e<br />
<br />
You can obtain the erights.org website by doing<br />
<br />
$ svn co svn://svn.synchrona.org/erights/doc doc<br />
<br />
With the [[wikipedia:TortoiseSVN|TortoiseSVN]] client, you can simply click on the svn: links above to check out these source trees.<br />
<br />
== Bug Tracking ==<br />
<br />
[https://sourceforge.net/tracker/?func=add&group_id=75274&atid=551529 E Bug Tracking on SourceForge]<br />
<br />
== Design and Future Directions ==<br />
<br />
[[:Category:Unresolved design issues|Unresolved Design Issues]]</div>Ansiblehttp://wiki.erights.org/wiki/WaterkenWaterken2008-03-04T21:13:05Z<p>Ansible: wikify</p>
<hr />
<div>The Waterken Server is a web server and distributed app framework written in [[Joe-E]], the object-capability subset of [[wikipedia:Java_(programming language)|Java]]. It defines a distributed capability protocol in terms of [[wikipedia:JSON|JSON]] data sent over [[wikipedia:TLS|TLS]], with cryptographic-capabilities (or [[web-keys]]) represented as https URLs.<br />
<br />
[[CapWiki]], a wiki with capability-based access control, has been built on Waterken/Joe-E, but is not currently operational. The [http://erights.org/download/horton/ reference implementation of Horton] is expressed in Waterken/Joe-E.<br />
<br />
== External Links ==<br />
<br />
* [http://waterken.sourceforge.net/ Waterken Server]<br />
<br />
<br />
[[Category:Applications]]</div>Ansiblehttp://wiki.erights.org/wiki/DevelopmentDevelopment2008-03-04T21:07:57Z<p>Ansible: </p>
<hr />
<div>Proposed / in progress changes to '''''E'''''.<br />
<br />
== [[E Language|Language]] ==<br />
<br />
== [[E Parser|Parser]] ==<br />
<br />
* [[Indented multiline literals]]<br />
<br />
== [[E Compiler|Compiler]] ==<br />
<br />
== [[E Runtime|Runtime]] ==<br />
<br />
== [[Elib|Elib Standard Library]] ==</div>Ansiblehttp://wiki.erights.org/wiki/Main_PageMain Page2008-03-04T21:03:46Z<p>Ansible: added Development top level link</p>
<hr />
<div>__NOTOC__<br />
<big>'''Welcome to the ERights.org wiki.'''</big><br />
<br />
'''''E''''' is a secure, [[wikipedia:Distributed computing|distributed]], [[wikipedia:Object-oriented programming|pure-object]] platform and [[wikipedia:Peer-to-peer|P2P]] scripting language for writing [[wikipedia:Object-capability model|''Capability-based'']] [[Smart Contracts]].<br />
<br />
== [[Getting Started]] ==<br />
<br />
[[Getting Started]] - Tips for '''''E''''' newbies<br />
<br />
== What's New? ==<br />
<br />
[http://www.erights.org/talks/index.html#google-abac Google Techtalk series on ABAC] - Authorization Based Access Control.<br />
<br />
[[Future research topics]]<br />
<br />
== [[Documentation]] ==<br />
<br />
* [[Documentation#Books|Books]]<br />
** [[Walnut|'''''E''''' in a Walnut]]<br />
* [[Documentation#Tutorials|Tutorials]]<br />
* [[FAQ]]<br />
* [[Documentation#Papers|Papers]]<br />
* [[Documentation#Talks and Presentations|Talks and Presentations]]<br />
<br />
== [[Downloads]] ==<br />
<br />
* [[Downloads#Releases|Releases]] - ready-to-install versions of '''''E'''''.<br />
* [[Downloads#Subversion|Subversion]] - development code<br />
<br />
==[[Applications]]==<br />
See [[:Category:Applications]].<br />
<br />
== [[Erights:Community Portal|Community]] ==<br />
<br />
[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to a running instance of '''''E ''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
==[[Development]]==<br />
<br />
== [[Related Sites]] ==<br />
<br />
[http://www.erights.org Main Erights.org site]<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[http://www.combex.com/ Combex, Inc.] - The for-profit facet of the '''''E''''' project, featuring [[CapDesk]] -- the capability secure desktop, and [[caplet]] installation and launching framework.</div>Ansiblehttp://wiki.erights.org/wiki/Indented_multiline_literalsIndented multiline literals2008-03-04T21:01:44Z<p>Ansible: link for quasi-literals</p>
<hr />
<div>The '''''E''''' parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and [[Walnut/Ordinary_Programming/Quasi-Literals_and_Quasi-Parsers|quasi-literals]] which is indifferent to the level of indentation in human-written programs.<br />
<br />
==Proposals==<br />
<br />
None yet.<br />
<br />
==Discussion==<br />
<br />
* [http://www.eros-os.org/pipermail/e-lang/2008-March/012520.html Initial report].<br />
<br />
[[Category:Unresolved design issues]]</div>Ansiblehttp://wiki.erights.org/wiki/Indented_multiline_literalsIndented multiline literals2008-03-04T21:00:03Z<p>Ansible: Fixing the '''''E'''''.</p>
<hr />
<div>The '''''E''''' parser and printer fail to be consistent when given a string literal containing a line break. It would also be useful to have syntax for multi-line string and quasi-literals which is indifferent to the level of indentation in human-written programs.<br />
<br />
==Proposals==<br />
<br />
None yet.<br />
<br />
==Discussion==<br />
<br />
* [http://www.eros-os.org/pipermail/e-lang/2008-March/012520.html Initial report].<br />
<br />
[[Category:Unresolved design issues]]</div>Ansiblehttp://wiki.erights.org/wiki/Joe-EJoe-E2008-02-21T16:12:11Z<p>Ansible: </p>
<hr />
<div>Joe-E is a subset of the [[wikipedia:Java_%28programming_language%29|Java programming langauge]] designed to support programming according to object-capability discipline.<br />
<br />
The language guarantees additional security properties by placing restrictions on Java code, but does not modify programs or change their meaning. This allows programmers' existing knowledge of Java to be applied and existing compilers, debuggers, and other tools to be used with Joe-E programs. <br />
<br />
== Links ==<br />
<br />
* [http://joe-e.googlecode.com/ Joe-E Home Page]<br />
* [http://code.google.com/p/joe-e/wiki/GettingStarted Getting Started with Joe-E]<br />
* [http://eclipse.joe-e.org/ Eclipse plug-in]<br />
* [http://www.cs.berkeley.edu/~daw/joe-e/ Original Joe-E Home Page]</div>Ansiblehttp://wiki.erights.org/wiki/Joe-EJoe-E2008-02-21T16:05:47Z<p>Ansible: </p>
<hr />
<div>Joe-E is a subset of the Java programming language designed to support programming according to object-capability discipline.<br />
<br />
The language guarantees additional security properties by placing restrictions on Java code, but does not modify programs or change their meaning. This allows programmers' existing knowledge of Java to be applied and existing compilers, debuggers, and other tools to be used with Joe-E programs. <br />
<br />
== Links ==<br />
<br />
* [http://joe-e.googlecode.com/ Joe-E Home Page]<br />
* [http://www.cs.berkeley.edu/~daw/joe-e/ Original Joe-E Home Page]</div>Ansiblehttp://wiki.erights.org/wiki/Object-capability_languagesObject-capability languages2008-02-21T16:03:57Z<p>Ansible: local page for Joe-E</p>
<hr />
<div>== Independent or Prior Objcap Languages ==<br />
<br />
* [http://www.erights.org/history/morris73.pdf Gedanken]<br />
* [http://www.erights.org/history/actors.html Actors]<br />
* [http://portal.acm.org/ft_gateway.cfm?id=323739&type=pdf Vulcan],<br />
* [http://www.agorics.com/Library/joule.html Joule]<br />
* [http://mumble.net/~jar/pubs/secureos/ W7]<br />
* [http://portal.acm.org/citation.cfm?doid=323627.323646 Eden, Emerald]<br />
* [http://citeseer.ist.psu.edu/279442.html J-Kernel]<br />
* [http://plash.beasts.org Plash]<br />
* [http://prog.vub.ac.be/amop/ AmbientTalk]<br />
* [http://www.erlang.org/ Erlang] - Erlang is almost, but not quite an object-capability language.<br />
<br />
== Related to '''''E''''' ==<br />
{| <br />
|+Relationships of '''''E''''' and other languages<br />
! Base language !! '''''E''''' Implementation !! Adapted to objcaps<br />
|-<br />
| [http://java.sun.com Java] || [http://erights.org/download/ E-on-Java] || [[Joe-E]] [http://waterken.sourceforge.net/ Waterken] [http://asyncobjects.sourceforge.net/ AsyncObjects]<br />
|-<br />
| [http://www.mozart-oz.org/ Mozart/Oz] || || [http://www.info.ucl.ac.be/people/PVR/oze.pdf Oz-E]<br />
|-<br />
| C/C++ || [http://erights.org/e-impls/e-on-c/index.html MC] || <br />
|-<br />
| [http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html Smallcaps] || [http://erights.org/e-impls/e-on-smallcaps/index.html E-on-Smallcaps] || <br />
|-<br />
| [http://www.squeak.org/ Squeak] || [http://erights.org/e-impls/e-on-squeak/index.html E-on-Squeak] || [http://www.squeaksource.com/SecureSqueak.html SecureSqueak] [http://wiki.squeak.org/squeak/6011 SqueakElibVM]<br />
|-<br />
| Common Lisp || [http://erights.org/e-impls/e-on-cl/index.html E-on-CL] || [http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html CL-E]<br />
|-<br />
| [http://caml.inria.fr/ocaml/index.en.html OCaml] || || [[Emily]]<br />
|-<br />
| [http://www.haskell.org/ Haskell] || [http://homepage.mac.com/kpreid/elang/ E-on-Haskell] || Caps in Haskell<br />
|-<br />
| Python || || [http://twistedmatrix.com/ Twisted Python] [http://twistedmatrix.com/trac/wiki/FoolsCap FoolsCap] [http://www.cs.ubc.ca/~drifty/papers/python_security.pdf Secure Python]<br />
|-<br />
| Perl || || [http://caperl.links.org/ CaPerl]<br />
|-<br />
| [http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html Pict] || || [http://altair.sk/mediawiki/index.php/Tamed_Pict Tamed Pict]<br />
|-<br />
| E || E-on-E ||<br />
|-<br />
| || || [http://sebyla.sourceforge.net/ Sebyla]<br />
|-<br />
| Javascript || || [http://code.google.com/p/google-caja/ Caja] [http://www.adsafe.org/ ADsafe] [http://wiki.developers.facebook.com/index.php/FBJS FBJS][http://video.google.com/videoplay?docid=452089494323007214 Vats on Gears]<br />
|}<br />
<br />
<br />
Also applicable to ML and Haskell style systems: [http://okmij.org/ftp/papers/lightweight-static-capabilities.pdf Lightweight Static Capabilities]</div>Ansiblehttp://wiki.erights.org/wiki/Walnut/Distributed_ComputingWalnut/Distributed Computing2008-02-19T14:20:44Z<p>Ansible: section breakup</p>
<hr />
<div>[[Category:Walnut|3]]<br />
<br />
==Distributed Computing==<br />
<br />
Multiple threads form the basis of conventional models of concurrent programming. Remarkably, human beings engage in concurrent distributed computing every day even though people are generally single threaded (there are exceptions: Walter Cronkite routinely listened to one broadcast with one ear, a different broadcast with the other, while simultaneously taking notes on another topic and speaking authoritatively to an audience of millions. But most people, including this author, live single-threaded lives).<br />
<br />
How do we simple creatures pull off the feat of distributed computing without multiple threads? Why do we not see groups of people, deadlocked in frozen tableau around the coffepot, one person holding the sugar waiting for milk, the other holding milk waiting for sugar?<br />
<br />
The answer is, we use a sophisticated computational mechanism known as a ''nonblocking promise''.<br />
<br />
Let us look at a conventional human distributed computation. Alice, the CEO of Evernet Computing, needs a new version of the budget including R&D numbers from the VP of Engineering, Bob. Alice calls Bob: "Could you get me those numbers?"<br />
<br />
Bob jots Alice's request on his to-do list. "Sure thing, Alice, I promise I'll get them for you after I solve this engineering problem."<br />
<br />
Bob has handed Alice a promise for the answer. He has ''not '' handed her the answer. But neither Bob nor Alice sits on their hands, blocked, waiting for the resolution.<br />
<br />
Rather, Bob continues to work his current problem. And Alice goes to Carol, the CFO: "Carol, when Bob gets those numbers, plug 'em into the spreadsheet and give me the new budget,okay?"<br />
<br />
Carol: "No problem." Carol writes Alice's request on her own to-do list, but does not put it either first or last in the list. Rather, she puts it in the conditional part of the list, to be done when the condition is met--in this case, when Bob fulfills his promise.<br />
<br />
Conceptually, Alice has handed to Carol a copy of Bob's promise for numbers, and Carol has handed to Alice a promise for a new integrated spreadsheet. Once again, no one waits around, blocked. Carol ambles down the hall for a contract negotiation, Alice goes back to preparing for the IPO.<br />
<br />
When Bob finishes his calculations, he signals that his promise has been fulfilled; when Carol receives the signal, she uses Bob's fulfilled promise to fulfill her own promise; when Carol fulfills her promise, Alice gets her spreadsheet. A sophisticated distributed computation has been completed so simply that no one realizes an advanced degree in computer science should have been required.<br />
<br />
In this simple example, we see why human beings never get trapped in the thread-based deadlock situations described endlessly in books on concurrent programming. People don't deadlock because they live in a concurrent world managed with a promise-based architecture. And so it is with <span class="e">''E''</span>.<br />
<br />
This chapter on distributed computing is the longest and most challenging part of the book. The Promise Architecture of <span class="e">''E''</span> is very different from the threads, synchronized methods, guarded objects, and RMI of Java. One might expect the Security chapter and its Capability paradigm to be equally new and challenging. But in fact, the implementation of security is embedded so deeply in E's infrastructure that much of the effort merely involves realizing the power inherent in constructs we have already learned. Security with <span class="e">''E''</span> is more a matter of architecture than of coding.<br />
<br />
Distributed computation, however, still requires gritty effort. We start simply, with the eventually operator.<br />
<br />
{{:Walnut/Distributed Computing/Eventually Operator}}<br />
{{:Walnut/Distributed Computing/Promises}}<br />
{{:Walnut/Distributed Computing/Multiway when-catch}}<br />
{{:Walnut/Distributed Computing/Partial Ordering Of Sent Messages}}<br />
{{:Walnut/Distributed Computing/Naming conventions}}<br />
{{:Walnut/Distributed Computing/Testing for Equality in a Distributed System}}<br />
<br />
===Letting When-Catch make a Promise For You===<br />
<br />
As noted in chapter 1 under the Secret Lives of Flow Control Structures, control structures return values. When used as described up to this point, the return value of the when--catch expression has been ignored. In fact, the when-catch expression returns a promise for the value that the done function will return. If the done function does not return a value, then it will always resolve to null. However, if the <font color="#FF0000">done(value) function</font> of the when-catch returns a value, the when-catch returns a promise that will be fulfilled by the last value in the executed clause. Rewriting the calcMilesBeforeEmptyVow using this feature, we get: <span class="warn" style="color:red">not right, not right, fix</span><br />
<br />
<pre><br />
<br />
<nowiki># E sample <br />
def calcMilesBeforeEmptyVow(carRcvr) { <br />
def fuelRemainingVow := carRcvr <- getFuelRemaining() <br />
def mpgVow := carRcvr <- getEfficiency() <br />
return when (fuelRemainingVow, mpgVow) -> { <br />
mpgVow * fuelRemainingVow <br />
} catch prob { <br />
throw(`Car Lost: $prob`)<br />
}<br />
}</nowiki><br />
<br />
</pre><br />
<br />
Here the when-catch creates the promise which is returned by the function, and resolution is automatic at the end of the when-catch execution. <font color="rgb(255, 0, 0)">What does the promise resolve to during a catch and/or a finally?</font><br />
<br />
===Broken Promise Contagion===<br />
<br />
When chaining promises, what happens if one of the promises in the middle or the far end breaks? The problem that breaks the far promise is propagated down all the promises dependent on it. As a consequence, broken promises work their way through the system in a similar way to exceptions being caught in try/catch blocks.<br />
<br />
===State Transitions for References===<br />
<br />
Having worked our way through near, far, broken, and promised references, let us put all the transitions among these together in a single place. The following diagram shows all the kinds of references <span class="e">''E''</span> distinguishes between, and it shows the two possible transitions:<br />
<br />
<font color="rgb(255, 0, 0)"> [[Image:ref-mech-0.gif|state transition diagram]]</font><br />
<br />
The 2 transitions are:<br />
<br />
* A promise may transition (resolve) into a resolved reference, which can be near or far or broken..<br />
* A far ref may transition to a broken ref.<br />
<br />
That is the complete collection of transitions.<br />
<br />
===Guards for distributed systems===<br />
<br />
Very early in the book, we presented a list of <span class="e">''E''</span> types, including any, integer, float64, etc. In that list were "rcvr", "vow", "pbc" and "near". "pbc" means that the type of the value is required to be "pass by construction". Transparent immutables are generally pbc, and can be passed through this type declaration. Strings, integers, floats, booleans, ConstMaps and ConstLists are all pbc. Objects that are pbc are copied when they are sent, so that even if the object originated on a remote computer, when you get it you can use immediate calls on it. Also, since pbc objects do not embody any code, pbc objects passed across a trust boundary can be used with far fewer security concerns: the pbc object may contain bad data, but it cannot play any tricky games in its execution.<br />
<br />
"Near" means that the value must be local. Promises and far references will not pass the near guard. Anything that passes a near guard can be sent messages with immediate calls.<br />
<br />
At this time, "rcvr" and "vow" have the same algorithmic meaning as "any", but can be used as hints to the programmer about how to interact with the object (a vow should be referenced only eventually until it is resolved; a rcvr should always be referenced only eventually).<br />
<br />
===Nested When-Catch constructs===<br />
<br />
As discussed earlier, we can guarantee the ordering of messages sent from one object to another object. But when a program sends messages to several objects, on different machines, the order in which answers will be received cannot be predicted. Suppose you need to perform a computation involving two far answers, and the algorithm depends on the result from the first answer. You can nest when-catch clauses to await the outcome of the dependency:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def fileRcvr := fileCacheRcvr <- getFile()<br />
when (def exists := fileRcvr <- exists()) -> {<br />
if (exists) {<br />
when (def text := fileRcvr <- getText()) -> {<br />
println(`File has text: $text`)<br />
} catch p2 {println(`Problem with existing file: $p2`)}<br />
} else {println("File does not exist")}<br />
} catch prob {println(`Problem reaching file: $prob`)}<br />
</nowiki><br />
<br />
</pre><br />
<br />
Here, we want to print the text of a farFile, but we want to be sure the file exists first. So we ask the file if it exists, and only after we determine that it does indeed exist do we proceed to get the text.<br />
<br />
As noted earlier, <font color="#FF0000">the "done(variable)" clause </font>of the when-catch construct is actually the declaration of a function and a series of parameters. The reasons for this are beyond the scope of this book, but the operational consequence is that you must use different function names if you have multiple when-catch clauses in the same scope.<br />
<br />
Nested when-catch clauses put the "done" functions into the same scope. In the example here, we gave the inner when-catch "done" function the name "done2" to prevent name collision. We also gave the error-containing variables in the catch clauses different names, e and e2.<br />
<br />
===Live Refs, Sturdy Refs, and URIs===<br />
<br />
Up to this point we have carefully dodged a critical question. How does a program acquire its very first reference to an object on a different computer? In all our examples up to this point, we have always started out with a reference to at least one remote object, and we retrieved other remote objects by asking that object for other objects: for example, we asked a remote carMakerRcvr for a new (remote) carRcvr, and were able to immediately work with the car just like any other remote object. How did we get the reference to the carMakerRcvr in the first place?<br />
<br />
In <span class="e">''E''</span>, the reference to an object can be encoded as a Universal Resource Identifier string, known as a ''uri'' (the familiar url of the Web is a type of uri). This uri string can be passed around in many fashions; one good secure way of passing a uri is to save it as a text file, encrypt and sign it with PGP, and send it in email. If you wish to run a seriously secure distributed <span class="e">''E''</span> system, encrypting the uris is crucial: indeed, the passing of the uris from machine to machine is the main security issue that <span class="e">''E''</span> cannot address for you (and is a problem shared by all security systems, a problem that will diminish with time as secure systems like PGP email are deployed). Other ways uris have been passed in operational <span class="e">''E''</span> systems have been to send the uri over an ssh connection, and (less securely) by reading the uri off over a telephone! If you are using <span class="e">''E''</span> on a local area network and have no security concerns, but are using <span class="e">''E''</span> simply because it is simpler, safer, and more maintainable for distributed computing, the uris can be stored in files on a shared file system and read directly by the programs on different computers as they start up.<br />
<br />
The functions makeURI(object) and objFromURI(uri) detailed in the <span class="e">''E''</span> Quick Reference Card perform the basic transformations you need to hook up objects on multiple computers. These routines use sturdy refs and liverefs in their computations. A sturdyRef is an object that contains an enduring description of where an object can be found; sturdyRefs and URIs are simple transformations of one another. LiveRefs are actual connections to objects that disappear any time a connection goes down. LiveRefs carry the actual traffic in <span class="e">''E''</span> communication. When you request a remote object from another remote object (as in farCarMaker <- ("mercedes")), what you actually get is a liveRef. If you want to continue to connect with that particular car across multiple sessions, you will need to explicitly get a sturdyRef from the car (and the car will have to have an explicit method for granting the sturdyRef. The sturdyref function is an important capability, not one handed out by default).<br />
<br />
Each program that expects to work with remote objects needs to invoke the command<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
introducer.onTheAir() </nowiki><br />
<br />
</pre><br />
<br />
before starting any remote connections, including the making or using of uris. An example of these functions working together can be found in eChat.<br />
<br />
===blockAtTop and continueAtTop===<br />
<br />
E programs never block. They never just sit and wait around for results. However, most programs will toss out some windows, or set up some services, and then desire to wait for someone or some thing to use them. Often, the first version of a program written by a new <span class="e">''E''</span> programmer will set everything up, execute the last line of the program, and then shut down. It is quite disconcerting to watch your windows briefly light up and then disappear, along with the java virtual machine underlying the entire program.<br />
<br />
The command<br />
<br />
<pre><br />
<br />
interp.blockAtTop()<br />
<br />
</pre><br />
<br />
causes the <span class="e">''E''</span> interpreter to wait for requests to come in. The command<br />
<br />
<pre><br />
<br />
interp.continueAtTop()<br />
<br />
</pre><br />
<br />
causes the <span class="e">''E''</span> interpreter to stop waiting. These commands are used in the eChat sample at the end of this chapter: the last line of the program initiates blockAtTop, and continueAtTop is invoked when the user closes his chat window.<br />
<br />
===A bit of Philosophy when using Promises for the first time===<br />
<br />
If a method accepts a promise or far reference as a parameter, the returned value almost certainly cannot be a local object. Why is this? If the computation of the returned object depends on something eventual, the computation will have to wait for an answer, which means the best the object can do for immediately returning something is to return a promise. So a method like getCar(licensePlateVow) has almost certainly violated the naming convention, one way or the other.<br />
<br />
As a consequence of this and other characteristics of promises, beginning E programmers often experience a moment of breathlessness soon after they first try to use them. This moment occurs when the programmer erroneously concludes that, once you let a promise into your system, the program has tumbled down a slippery slope from which there is no recovery. It feels as if you will never be able to have a real value in your hands again; you'll spend the rest of your life making eventual sends, coupled with endless when-catch constructs just to get to the next step.<br />
<br />
The breathlessness can metastasize into a feeling of having lost control of the software: everything is off computing somewhere else and all you have is a bunch of promises. Since <span class="e">''E''</span> never (really, never!) blocks, you can never tell things, "just stop for a moment while I catch my breath and gather up all the values" :-)<br />
<br />
In fact, there are several patterns and tools for getting control of things again. The basic multi-promise when-catch, and the promiseAllResolved and Summoner patterns at the end of this chapter are just a few examples of structures specifically designed to reduce the frequency with which you need when-catch. They allow you to get quickly back into local computation after a distributed action. You really can catch your breath.<br />
<br />
And once the moment of breathlessness passes, you will feel freedom, for you will never have to deal with thread synchronization again; you will never lie awake at night wondering if an unexplored race condition will cause deadlock a few days after the production load level hits your system. <font color="#ff0000">How early can I put this paragraph easily? AHK proposes right after Promises.</font><br />
<br />
===Additional Promise-Related Operations===<br />
<br />
* whenBroken<br />
* E isBroken<br />
* whenResolved Use this when your action will be the same once the promise resolves, regardless of whether it resolves broken or not.<br />
* E isResolved<br />
* E send(object,verb,arguments) This function is identical to the E call() function described earlier, but does an eventual send rather than an immediate call.<br />
* E sendOnly<br />
* E join(a,b) Guarantees sends to result of join are delivered only after messages to a and b have been delivered, sort of a test for equality on-the-fly<br />
<br />
===Under the Covers: Vats and Game Turns===<br />
<br />
<font color="#ff0000">Each vat has a separate event loop, each game turn corresponds to the processing of a single event to conclusion with no interruptions. There are frontend vats, which all share the swing event queue for queuing messages to their event loops, and there are backend queues, each of which has its own separate event queue and runs on a separate thread. Frontend vats have the advantage that they can interact directly with user interface widgets. The initial vat created by default at the start of an E program is a frontend vat. You might want multiple frontend vats if you want to shut down whole subsystems in one fell swoop: you can tell a vat to shut down, and it will terminate all its connections to the outside world, making it available for garbage collection. Have markm review this and tell me what is wrong with this description.</font><br />
<br />
<font color="#ff0000">creating a second frontend vat on a single jvm. creating a backend vat on a jvm</font><br />
<br />
===Example: Alice, Bob, and Carol as Code===<br />
<br />
We started this chapter with a description of a human interaction, with Alice as the CEO of Evernet Computing in search of a new spreadsheet for her IPO preparation. What would that distributed problem look like in code? Though we present only a skeleton of this human operation here, it is perhaps nonetheless informative. It might also be informative, after one has read how to do the example in <span class="e">''E''</span>, to think about how it would be done with threads, in Java or C++. That, however, is left as an exercise for the reader.<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
#---- Bob Code<br />
<br />
def bobRcvr {<br />
to handleExplosionInNetworkServerRoom() {<br />
# handle the explosion<br />
}<br />
to getCostNumbers() :pbc {<br />
return ["R&D" => 10000]<br />
}<br />
}<br />
<br />
#------------ Carol Code<br />
<br />
def carolRcvr {<br />
to attendMeeting(room, time) {<br />
# attend the meeting<br />
}<br />
to integrateSpreadsheetVow(RDNumbersVow) {<br />
def sheetVow := when (RDNumbersVow) -> {<br />
["Marketing" => 50000] | RDNumbersVow<br />
} catch prob {<br />
println("No numbers!")<br />
prob<br />
}<br />
return sheetVow<br />
}<br />
}<br />
<br />
#--------- Alice Code<br />
<br />
def aliceRcvr {<br />
to prepareIPOVow() {<br />
def RDNumbersVow := bobRcvr <- getCostNumbers()<br />
def spreadsheet := carolRcvr <- integrateSpreadsheetVow(RDNumbersVow)<br />
return when (spreadsheet) -> {<br />
println(`Appendix: Budget Spreadsheet: $\n$spreadsheet`)<br />
} catch prob {<br />
aliceRcvr <- fireSomebody([bobRcvr, carolRcvr])<br />
}<br />
# do other IPO preparations<br />
}<br />
to fireSomebody(candidateRcvrs) {<br />
# get rid of culprit<br />
}<br />
}<br />
<br />
bobRcvr <- handleExplosionInNetworkServerRoom()<br />
carolRcvr <- attendMeeting(1,2)<br />
aliceRcvr <- prepareIPOVow()</nowiki><br />
<br />
</pre><br />
<br />
===Example: minChat version 1===<br />
<br />
In order to focus on the distributed computation features of this chat tool, we have gone to extreme lengths to make the user interface machinery a very short piece of code. Hence, this should properly be called "minChat", because the user interface is so brutally minimal. Even with such minimization, however, the user interface still requires more lines of code than the actual distributed computation!<br />
<br />
The chatController at the bottom of the example is the heart and soul of the computation.<br />
<br />
<code><br />
<br />
<br />
#?? in new vat minChatVat.e-swt<br />
## E sample<br />
#!/usr/bin/env rune<br />
#eChat with minimalist user interface<br />
pragma.syntax("0.9")<br />
def <widget> := <swt:widgets.*><br />
def SWT := <swt:SWT><br />
introducer.onTheAir()<br />
# return the object represented by the URI<br />
def getObjectFromURI(uri) {return introducer.sturdyFromURI(uri).getRcvr()}<br />
<br />
def makeURIFromObject(obj) :String {<br />
# This implementation assumes a non-persistent single incarnation<br />
def [sr, _, _] := identityMgr.makeKnown(obj)<br />
<span style="color:#FF0000">#XXX not a uri if bracketed, bug, markm?</span><br />
def bracketed := introducer.sturdyToURI(sr)<br />
if (bracketed =~ `<@uri>`) {return uri}<br />
return bracketed<br />
}<br />
<br />
def chatController<br />
def chatArea<br />
def chatUI {<br />
to show() {<br />
def frame := <widget:Shell>(currentDisplay)<br />
frame.setText("eChat"); frame.setBounds(30, 30, 600, 300)<br />
def winDisposeListener {to widgetDisposed(event) {interp.continueAtTop()}} <br />
frame.addDisposeListener(winDisposeListener)<br />
bind chatArea := <widget:Text>(frame, <br />
(SWT.getMULTI() | SWT.getWRAP()) | (SWT.getBORDER() | SWT.getV_SCROLL()))<br />
def commandLine := <widget:Text>(frame, SWT.getSINGLE() | SWT.getBORDER())<br />
def enterKeyListener {<br />
to keyPressed (event) {<br />
if (event.getKeyCode() == 27) {<br />
if (commandLine.getText() =~ `@command @argument`) {<br />
commandLine.setText("")<br />
switch (command) {<br />
match == "save" {chatController.save(<file: argument>)}<br />
match == "load" {chatController.load(<file: argument>)}<br />
match == "send" {chatController.send(argument)}<br />
match _ {commandLine.setText("Error. Try save load, or send")}<br />
}<br />
} else {commandLine.setText("Error. Try save, load, or send")}<br />
}<br />
}<br />
match [verb, args] {}<br />
}<br />
commandLine.addKeyListener(enterKeyListener) <br />
def label := <widget:Label>(frame, SWT.getLEFT())<br />
label.setText("save, load, send. No quotes for path. Use Escape to start operation. ")<br />
swtGrid`$frame: $chatArea.X.Y<br />
$label.X<br />
$commandLine.X`<br />
frame.open()<br />
}<br />
to showMessage(initiator, text) {chatArea.append(`$initiator: $text $\n`)}<br />
}<br />
<br />
def friend<br />
bind chatController {<br />
to send(message) {<br />
when (friend<-receive(message)) -> {<br />
chatUI.showMessage("self", message)<br />
} catch prob {chatUI.showMessage("system", "connection lost")}<br />
}<br />
to receive(message) {chatUI.showMessage("friend", message)}<br />
to receiveFriend(friendRcvr) {<br />
bind friend := friendRcvr <br />
chatUI.showMessage("system", "friend has arrived")<br />
}<br />
to save(file) {file.setText(makeURIFromObject(chatController))}<br />
to load(file) {<br />
bind friend := getObjectFromURI(file.getText())<br />
friend <- receiveFriend(chatController)<br />
}<br />
}<br />
chatUI.show()<br />
# In actual code, the following line would not be commented out<br />
# interp.blockAtTop()</nowiki><br />
<br />
</code><br />
<br />
There are only 5 methods in making chat happen: sending a message to the friend, receiving a message from the friend, being informed that the friend has found you (the ''receivedFriend ''method), saving the URI where your friend can find you, and loading the URI that describes where you can find your friend.<br />
<br />
A quick run through can be done by putting the source in a file (file extension ".e-swt", this example uses SWT for user interface) and launching the file twice to get 2 chat windows. In one window, type "save ~/me.minchat" and press the Escape key. This creates a file (in your home directory) that contains a cap: URI describing where your chat session can be found (a chat session that can only be found by someone to whom this file has been given--the location cannot be found or guessed by anyone else). In the other window, type "load ~/me.minchat" and press Escape. In the first window you should see a message pop up that the "friend has arrived". Now in either window type "send hi y'all", and you will see the message appear in both windows.<br />
<br />
In minChat , every time you start up the program, it comes to life with a new uri that must be sent to the friend with whom you wish to chat; the old uri from the previous session is useless. MinChat would be far more useful if you could create a minChat session with Bob, and continue that session even after you have rebooted your computer. We look at building such a persistent chat in the chapter on Persistent Secure Distributed Computing--after first looking at minChat here through the eyes of a security reviewer (or a cybercracker) in the chapter on Secure Distributed Computing.<br />
<br />
===Patterns of Promises===<br />
<br />
====resolveAllVow====<br />
<br />
Suppose you have a computation that cannot be performed until you have received answers from multiple remote objects. Your first thought would be to use a multi-vow when-catch. But further suppose you do not know beforehand how many vows there are (i.e., suppose you have an arbitrary list of promises). In this case neither the multi-vow when-catch construct nor the nested when-catch pattern will work. For this situation, you can use the resolveAllVow utility described here.<br />
<br />
The resolveAllVow utility has another distinction compared to a multi-vow when-catch: whereas the multi-vow activates the catch clause as soon as it hits a broken promise, resolveAllVow sends no resolution until everything in the list is resolved one way or the other. So, even if several of the promises were broken, with resolveAllVow you can be sure that the rest have been fulfilled when the catch clause is activated.<br />
<br />
In this example, we use resolveAllVow to sum a list of contributions. We do not know beforehand how many contributions there are (perhaps thousands), and we want to sum them up even if some of the requests for donations return broken promises.<br />
<br />
E isBroken(obj) does not work. what does?<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
# Given a List of promises, when all the promises have been resolved,<br />
# resolve the returned vow, either fulfilling it with the list of fulfillments (if<br />
# all the promises were fulfilled) or by smashing the returned promise<br />
# with one of the broken promises (if at least one promise was broken). <br />
def resolveAllVow(promises) {<br />
def [resultVow, resolver] := Ref.promise()<br />
var count := promises.size()<br />
var resolution := promises<br />
var noneBroken := true<br />
if (count == 0) {resolver.resolve(promises)}<br />
for promise in promises {<br />
when (promise) -> {<br />
# success processed in finally clause<br />
} catch prob {<br />
resolution := prob<br />
noneBroken := false<br />
} finally {<br />
count -= 1<br />
if (count == 0) {<br />
if (noneBroken) {<br />
resolver.resolve(resolution)<br />
} else {resolver.smash(resolution)}<br />
}<br />
}<br />
}<br />
return resultVow<br />
}<br />
#now use the promiseAllResolved to sum contributions, where the<br />
#number of contributions is unknown prior to execution<br />
def printTotalContributions(amountsList) {<br />
var total := 0<br />
for each in amountsList {<br />
if (!(Ref.isBroken(each))) {total += each}<br />
}<br />
println(`Total contributions are: $total`)<br />
}<br />
# scaffold contributors: real contributors would be remote Rcvrs<br />
def makeContributer(donation) {<br />
return def contributor { to getDonation() :int {return donation} }<br />
}<br />
def contributorRcvrsList := [makeContributer(5), makeContributer(6)]<br />
def amountsVows := [].diverge()<br />
for each in contributorRcvrsList {<br />
amountsVows.push(each <- getDonation())<br />
}<br />
when (def amounts := resolveAllVow(amountsVows)) -> { <br />
printTotalContributions(amounts)<br />
} catch prob {<br />
#due to the nature of resolveAllVows, in this catch clause<br />
#we are guaranteed everything in amountsVows is resolved to <br />
#either an amount or a broken reference<br />
printTotalContributions(amountsVows)<br />
}</nowiki><br />
<br />
</pre><br />
<br />
The basic behavior of resolveAllVow is this: when initiated, the function takes a count of how many promises there are, then immediately spins off when-catches for all of them. Each time a promise resolves, the count of outstanding promises is decremented. When the counter drops to zero, implying all the promises have been resolved, the single promise initially returned by resolveAllVow is finally resolved.<br />
<br />
====dialogVowMaker====<br />
<br />
Java's standard dialog boxes, found in JOptionPane, are seriously flawed for use in a distributed <span class="e">''E''</span> system: those convenience dialogs are fully blocking. As a consequence, if your computer is part of a distributed computation, and you go home for the night, if a Java dialog box pops up, your machine is effectively offline until you return in the morning. Included in the <span class="e">''E''</span> distribution is a dialog box tool, the dialogVowMaker:<br />
<br />
<font color="#ff0000">code here</font><br />
<br />
====Recursion for send sequencing====<br />
<br />
As discussed earlier, putting a when-catch inside a for loop does not give you any guarantees on which when-catch will activate first: it only guarantees which message is sent first, which is mostly uninteresting. For general-purpose ensured sequencing of resolution, you must use recursion.<br />
<br />
Earlier, we had an example in which we told a list of cars to moveTo the same location. Suppose we wished to ensure that the cars arrived in the order in which they appear in the list:<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def moveAllCarsInSequence(carRcvrs,toX,toY) {<br />
var carI := 0<br />
def moveRemainingCars() {<br />
if (carI < carRcvrs.size()) {<br />
def nextCarRcvr := carRcvrs[carI]<br />
carI += 1<br />
def nameVow := nextCarRcvr <- getName()<br />
when (nameVow,nextCarRcvr <- moveTo(toX,toY)) -> {<br />
println(nameVow + " arrived, next car about to start moving")<br />
} catch e {<br />
println(`car died: $e`)<br />
} finally {moveRemainingCars()}<br />
}<br />
}<br />
moveRemainingCars()<br />
}<br />
# scaffold carmaker<br />
def makeCarRcvr(name) {<br />
def carRcvr {<br />
to getName() :String {return name}<br />
to moveTo(x, y) {<br />
#move the car<br />
}<br />
}<br />
return carRcvr<br />
}<br />
<br />
moveAllCarsInSequence([makeCarRcvr("car1"),makeCarRcvr("car2")],3,4) </nowiki><br />
<br />
</pre><br />
<br />
Inside the moveAllCarsInSequence function, we declare the recursive moveRemainingCars function, then simply invoke moveRemainingCars. The function moveRemainingCars tells the next car to move; once that movement has resolved, moveRemainingCars invokes itself once again.<br />
<br />
In this version of moveAllCarsInSequence, if a car is lost (i.e., its promise to move is broken), the recursion continues. If we wanted to abort after a problem occurred, we would simply delete the call to moveRemainingCars() from the finally clause, and place it in the when clause.<br />
<br />
====sendValve====<br />
<br />
As we have seen, it is possible to spin off large numbers of eventual sends in the blink of an eye. In fact, tossing off vast numbers of such sends can sometimes consume a lot of resources for no good purpose. In the eDesk program at the end of the book, it is possible for the user to request the transfer of whole directories full of files. It would be possible for eDesk to initiate transfer of all of those files simultaneously. But the processing bottleneck is probably bandwidth, so initiating them all at once won't get the whole transfer done any faster, and meanwhile each individual file transfer consumes buffer space once initiated. Starting all the transfers at once could actually slow down the transfer if enough buffers thrash virtual memory.<br />
<br />
What you want is a ''valve'', which can be opened and closed depending on the situation. The program can still set up all the operations in a single swoop, but the valve will constrain the number of such operations that are actually active at a given moment. The sendValve below performs this function.<br />
<br />
<pre><br />
<br />
<nowiki>#sendValve. If you have numerous eventual sends to initiate,<br />
# but initiating them all at once would consume vast resources<br />
# and/or would actually slow down processing, queue the actions <br />
# through a valve.<br />
#An ActionTrio is the list of [obj,"verb",[arguments]]<br />
# that can be used in an E send()<br />
#The actions are guaranteed to be initiated in the sequence in<br />
# which they are placed in the valve, though of course there is<br />
# no guarantee as to which will terminate first (unless you have<br />
# special knowledge of such sequencing outside the valve).<br />
#The numSimultaneousAllowed is the number of actions that can<br />
# be run concurrently through this valve.<br />
<br />
# E sample<br />
def makeSendValve (numSimultaneousAllowed) {<br />
var actionQueue := []<br />
var numRunning := 0<br />
def startNext() {<br />
if (!(actionQueue.size()==0)) {<br />
def [actionTrio, resolver] := actionQueue[0]<br />
actionQueue := actionQueue(1, actionQueue.size())<br />
numRunning += 1<br />
def completeVow := E.send(actionTrio[0],actionTrio[1],actionTrio[2])<br />
resolver.resolve(completeVow)<br />
when (completeVow) -> {<br />
} catch prob {<br />
} finally { <br />
numRunning -= 1 <br />
startNext()<br />
}<br />
}<br />
}<br />
def valve {<br />
to makeActionVow(actionTrio) {<br />
def [completeVow, resolver] := Ref.promise()<br />
actionQueue := actionQueue.with([actionTrio, resolver])<br />
if (numRunning < numSimultaneousAllowed) {<br />
startNext()<br />
}<br />
return completeVow<br />
}<br />
}<br />
return valve<br />
}</nowiki><br />
<br />
</pre><br />
<br />
The sendValve utility, if used with numSimultaneousAllowed==1, can also perform the send sequencing function described earlier. However, the earlier general send sequencing pattern is still useful. For example, if the moveAllCarsInSequence operation should abort upon a encountering a broken resolution, this version of sendValve would not give the correct result.<br />
<br />
====Summoning====<br />
<br />
====Transparent forwarder====<br />
<br />
It is possible to have a network of machines in which the machines do not all have direct access to one another. Suppose in the network with machine A, B, and C, A and C cannot form a direct connection because of network topology, but B can reach everything. If A needs a capability on C, we can put a transparent forwarder on B such that A sends its messages to the forwarder on B:<br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def makeTransparentForwarder(representedRcvr) {<br />
def forwarder {<br />
match [verb,args] {E.send(representedRcvr,verb,args)}<br />
}<br />
return forwarder<br />
}</nowiki><br />
<br />
</pre><br />
<br />
Create the forwarder on B, and hand the reference to the forwarder to the appropriate object on A. An example can be found in the eDesk example at the end of the book, in which a forwarder is used if the system detects that two of the file servers are unable to directly connect. Note that the "delegate" keyword does not quite work here: delegate generates immediate calls, not eventual sends. So we had to revert to the more general purpose matching process.<br />
<br />
====acceptOnlyMoreRecentVow====<br />
<br />
Suppose you are periodically requesting a particular piece of information from a far object. Suppose the far object cannot supply the answer in a single game turn, i.e., it must ask other objects for information to get the answer, and so it sends you a promise rather than a result. It is possible for the resolutions of these promises to occur out-of-order, i.e., the resolution on the second request could get to you after the resolution of the third request has already occurred. In this situation, it will appear that the answer to the second request is newer and more up-to-date than the third request.<br />
<br />
<font color="#000000">In this situation, to ensure you are getting only new information, not stale information, use the acceptOnlyMoreRecentVow utility.</font><br />
<br />
<pre><br />
<br />
def acceptOnlyMoreRecentVow<br />
<br />
</pre><br />
<br />
<font color="#ff0000">code here</font><br />
<br />
This situation, while rare, actually arises in the Marketplace example in the Secure Distributed Computing chapter.<br />
<br />
<font color="#ff0000">something about time, the race construct, timeout construct</font><br />
<br />
====eDesk overwrite copy jewel====<br />
<br />
The following is not really a pattern so much as it is an example of all the more novel (i.e., not-like-Java) elements of <span class="e">''E''</span> playing together. The problem, taken from the eDesk program in the Examples at the end of the book, is this:<br />
<br />
example<br />
<br />
===Data Lock===<br />
<br />
Though <span class="e">''E''</span> is safe from deadlock, in which several objects compete for acquisition to a set of resources, there is a related dilemma that <span class="e">''E''</span> programs can encounter. If two or more "when" clauses wait for each other to resolve before they can resolve themselves, this causes ''data lock''. A complete discussion of data lock and why it is far less of a risk than deadlock is beyond the scope of this book. Briefly, both theory and current experience suggest that data locks are more difficult to create in the wild than deadlocks. Furthermore, when datalocks do occur, they are less likely to freeze up important subsystems on a grand scale: unlike the deadlock, they only choke a few "when" clauses, not a set of "critical sections" which have been named "critical" in thread programming for good reasons. And lastly, datalocks are consistent, reproducible, and therefore fixable, unlike the deadlocks that appear mysteriously when some incredibly arcane race condition occurs.<br />
<br />
Here is a simple though foolish example of datalock. It is the E implementation of the English sentence, "This sentence is false."<br />
<br />
<pre><br />
<br />
def sentence := sentence <- not()<br />
<br />
</pre><br />
<br />
In this construction, the sentence will forever be an unresolved promise. As noted above, the failure of this to resolve will not impede the progress of the rest of the program in the least. And it is very reliable: the unresolvability of the promise will appear the first time you run the program, and the second, and in every debugging pass thereafter.<br />
<br />
At the time of this writing, data lock has been seen only once in the wild. In that instance, a widely used object (call it WUO),contained one piece of mutable state and one piece of immutable state. The object that computed new versions of WUO's mutable state needed the immutable part of the state, and requested the current version of WUO from the owner of the object. Unfortunately, the owner knew that a new version was under construction, and was only sending out promises for WUO until the update was resolved. The solution in this case was to refactor WUO. This resulted in an architecture that was cleaner even by normal object design criteria, without regard to the distributed usage behavior. Insufficient data is yet available to assess how commonly this type of solution will suffice.<br />
<br />
<br />
Next Section: [[Walnut/Secure_Distributed_Computing|Secure Distributed Computing]]</div>Ansiblehttp://wiki.erights.org/wiki/Walnut/Distributed_Computing/Testing_for_Equality_in_a_Distributed_SystemWalnut/Distributed Computing/Testing for Equality in a Distributed System2008-02-19T14:19:40Z<p>Ansible: section breakup</p>
<hr />
<div>===Testing for Equality in a Distributed System===<br />
<br />
As noted above, you can send eventual messages to both promises and far references. So if you plan to treat the fulfilled object as a far reference, using only eventual sends, there is usually no reason to use a when-catch to wait for resolution. Just go ahead and start sending messages, uncaring of whether the promise has yet been fulfilled.<br />
<br />
There are four reasons to use a when-catch construct to resolve the promise for a far object.<br />
<br />
* To find out that the original request succeeded, or otherwise, to get the problem<br />
* To flush out all previous messages sent via a reference to an object before taking an action<br />
* To use the result as a key in a hash table (a promise cannot be used as a hash key)<br />
* To test for equality, i.e., to see whether the promised object is the same object that you received from another activity.<br />
<br />
Here is a test for equality:<br />
<br />
<pre><br />
<br />
<nowiki># E syntax<br />
def polePositionCarRcvr := raceTrack <- getPolePositionCar()<br />
when (polePositionCarRcvr) -> {<br />
if (polePositionCarRcvr == myCar) {<br />
println("My car is in pole position")<br />
}<br />
} catch prob {}</nowiki><br />
<br />
</pre><br />
<br />
Note that the catch clause is empty. Because remote references across a network are unreliable, you will usually want to handle the problem that triggered the catch clause. However, if you have many pending actions with a single remote object, all the catch clauses for all those actions will start up if the connection fails, so you may want to disregard most of the catch clauses and focus on handling the larger problem (loss of connection) in one place. Often in this situation you will want to set up a whenBroken message, described later.<br />
<br />
But in this example, there is no compelling special action to take if you can't find out whether your car is in pole position, so no action is taken.<br />
<br />
===Making your own Promises===<br />
<br />
If you write a function or method that must get values from a far object before returning an answer, your function should return a promise for the answer, and fulfill that answer later. You can create your own promises using Ref.promise() in <span class="e">''E''</span><nowiki>:</nowiki><br />
<br />
<pre><br />
<br />
<nowiki># E sample<br />
def calcMilesBeforeEmptyVow(carRcvr) {<br />
def [milesBeforeEmptyPromise, milesBeforeEmptyResolver] := Ref.promise()<br />
def fuelRemainingVow := carRcvr <- getFuelRemaining()<br />
def mpgVow := carRcvr <- getEfficiency()<br />
when (fuelRemainingVow, mpgVow) -> {<br />
milesBeforeEmptyResolver.resolve(mpgVow * fuelRemainingVow)<br />
} catch prob {<br />
milesBeforeEmptyResolver.smash(`Car Lost: $prob`)<br />
}<br />
return milesBeforeEmptyPromise<br />
}<br />
<br />
#....Meanwhile, somewhere else in the program....<br />
def myCar {<br />
to getFuelRemaining() {return 5}<br />
to getEfficiency() {return 2}<br />
}<br />
def milesVow := calcMilesBeforeEmptyVow(myCar)<br />
when (milesVow) -> {<br />
println(`miles before empty = $milesVow`)<br />
} catch e {println(`Error: $e`)}</nowiki><br />
<br />
</pre><br />
<br />
This example highlights several different features of promises. The basic idea of the example is that the function calcMilesBeforeEmptyVow(carRcvr) will eventually compute the number of miles the car can still travel before it is out of fuel; later in the program, when this computation is resolved, the program will print the value. However, before we can do the computation, we must first get both the fuelRemaining and the milesPerGallon values from the remote car.<br />
<br />
The promise and the resolver for that promise are created as a pair using Ref.promise(). They are "normal" variables in the sense that they can be passed as arguments, returned from methods as answers, and sent eventual messages. Resolvers truly are ordinary objects. There are 3 restrictions on the promises: they cannot accept immediate calls, they cannot be tested for equality, and they cannot be used as keys in hash tables.<br />
<br />
In this example, the function returns the milesBeforeEmptyPromise to the caller just as it would return any other kind of value. To cause the promise to resolve, the function calls the resolver (or sends to the resolver if the resolver may be remote to your program) with the "resolve(value)" method. To break the promise (which produces a problem that will cause the catch clause of a when-catch to execute), call the resolver with the "smash(problem)" method.<br />
<br />
It is possible to chain resolutions: you can resolve a promise by handing the resolver another promise (though if you hand the resolver the promise which it is intended to resolve, <span class="e">''E''</span> will detect the problem and automatically break the promise--a promise resolved to itself can never be fulfilled). If you resolve a promise with another promise, the original promise is not yet considered resolved, i.e., the when-catch body will not be activated by such a resolution. The when-catch body will only be activated when the entire promise chain is resolved, and there is an actual reference to an actual object available.</div>Ansiblehttp://wiki.erights.org/wiki/DocumentationDocumentation2008-02-18T16:55:29Z<p>Ansible: /* Papers */</p>
<hr />
<div>== Books and Theses ==<br />
<br />
[http://www.evoluware.eu/fsp_thesis.pdf Patterns of Safe Collaboration]<br />
<br />
[http://gonzo.uni-weimar.de/~scheffl2/Diploma_MScheffler.pdf Object-Capability Security in Virtual Environments]<br />
<br />
[[Image:Ewalnut-pink.gif]]<br />
[[Walnut|'''''E''''' in a Walnut]] - This is a basic tutorial on the '''''E''''' language covering basic, distributed, and secure distributed programming.<br />
<br />
[http://www.erights.org/talks/thesis/index.html Robust Composition] - Towards a Unified Approach to Access Control and Concurrency Control. This is [[User:MarkM|Mark Miller]]'s PhD disseration, and it explains the rationale, philosophy, and goals of '''''E''''' and related systems.<br />
<br />
[[Safe Serialization Under Mutual Suspicion]] (Wiki conversion in progress)<br />
<br />
== Tutorials ==<br />
<br />
[http://www.erights.org/elang/intro/index.html Tutorials] - several short tutorials showing how to use '''''E'''''.<br />
<br />
[http://www.erights.org/elang/quick-ref.html Quick Reference Card] - Reminders of some useful patterns.<br />
<br />
[[FAQ]]<br />
<br />
== Papers ==<br />
<br />
[http://www.erights.org/elib/capability/ode/index.html Capability-based Financial Instruments] "An Ode to the [[wikipedia:Mark Granovetter|Granovetter]] Diagram" - diagramming communication relationships.<br />
<br />
[http://www.hpl.hp.com/techreports/2003/HPL-2003-222.html Paradigm Regained: Abstraction Mechanisms for Access Control] by Mark S. Miller and Jonathan S. Shapiro.<br />
<br />
[http://www.erights.org/talks/promises/paper/tgc05.pdf Concurrency Among Strangers: Programming in '''''E''''' as Plan Coordination] - by Mark S. Miller, E. Dean Tribble, Jonathan Shapiro. Explains '''''E''''''s concurrency control & distributed computing model.<br />
<br />
[http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/AALPE.pdf Authority Analysis for Least Privilege Environments] by Toby Murray and Gavin Lowe.<br />
<br />
[http://www.erights.org/elang/tools/causeway/causeway-paper.pdf Causeway: A message-oriented distributed debugger] by Terry Stanley, E. Dean Tribble, and Mark S. Miller.<br />
<br />
== Talks and Presentations ==<br />
<br />
[http://www.youtube.com/watch?v=gGw09RZjQf8 The Lively Kernel] by Dan Ingalls<br />
<br />
[http://www.youtube.com/watch?v=EGX2I31OhBE Object-Capabilities for Security] by David Wagner<br />
<br />
[http://www.youtube.com/watch?v=V13wmj88Zx8 Gears and the Mashup Problem] by Douglas Crockford<br />
<br />
[http://www.youtube.com/watch?v=vrbmMPlCp3U Desktops to Donuts: Object-Caps Across Scales] by Marc Stiegler<br />
<br />
[http://www.youtube.com/watch?v=8aedCggam4s Core Patterns for Web Permissions] by Tyler Close<br />
<br />
[http://www.youtube.com/watch?v=oE3x_gM3YFU Paradigm Regained: Abstraction Mechanisms for Access Control] by Mark Miller<br />
<br />
[http://www.youtube.com/watch?v=UH66YrzT-_M The Virus Safe Computing Initiative at HP Labs] by Alan Karp</div>Ansiblehttp://wiki.erights.org/wiki/DocumentationDocumentation2008-02-18T16:51:58Z<p>Ansible: /* Papers */ added causeway</p>
<hr />
<div>== Books and Theses ==<br />
<br />
[http://www.evoluware.eu/fsp_thesis.pdf Patterns of Safe Collaboration]<br />
<br />
[http://gonzo.uni-weimar.de/~scheffl2/Diploma_MScheffler.pdf Object-Capability Security in Virtual Environments]<br />
<br />
[[Image:Ewalnut-pink.gif]]<br />
[[Walnut|'''''E''''' in a Walnut]] - This is a basic tutorial on the '''''E''''' language covering basic, distributed, and secure distributed programming.<br />
<br />
[http://www.erights.org/talks/thesis/index.html Robust Composition] - Towards a Unified Approach to Access Control and Concurrency Control. This is [[User:MarkM|Mark Miller]]'s PhD disseration, and it explains the rationale, philosophy, and goals of '''''E''''' and related systems.<br />
<br />
[[Safe Serialization Under Mutual Suspicion]] (Wiki conversion in progress)<br />
<br />
== Tutorials ==<br />
<br />
[http://www.erights.org/elang/intro/index.html Tutorials] - several short tutorials showing how to use '''''E'''''.<br />
<br />
[http://www.erights.org/elang/quick-ref.html Quick Reference Card] - Reminders of some useful patterns.<br />
<br />
[[FAQ]]<br />
<br />
== Papers ==<br />
<br />
[http://www.erights.org/elib/capability/ode/index.html Capability-based Financial Instruments] "An Ode to the [[wikipedia:Mark Granovetter|Granovetter]] Diagram" - diagramming communication relationships.<br />
<br />
[http://www.hpl.hp.com/techreports/2003/HPL-2003-222.html Paradigm Regained: Abstraction Mechanisms for Access Control]<br />
<br />
[http://www.erights.org/talks/promises/paper/tgc05.pdf Concurrency Among Strangers: Programming in '''''E''''' as Plan Coordination] - by Mark S. Miller, E. Dean Tribble, Jonathan Shapiro. Explains '''''E''''''s concurrency control & distributed computing model.<br />
<br />
[http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/AALPE.pdf Authority Analysis for Least Privilege Environments] by Toby Murray and Gavin Lowe.<br />
<br />
[http://www.erights.org/elang/tools/causeway/causeway-paper.pdf Causeway: A message-oriented distributed debugger] by Terry Stanley, E. Dean Tribble, and Mark S. Miller.<br />
<br />
== Talks and Presentations ==<br />
<br />
[http://www.youtube.com/watch?v=gGw09RZjQf8 The Lively Kernel] by Dan Ingalls<br />
<br />
[http://www.youtube.com/watch?v=EGX2I31OhBE Object-Capabilities for Security] by David Wagner<br />
<br />
[http://www.youtube.com/watch?v=V13wmj88Zx8 Gears and the Mashup Problem] by Douglas Crockford<br />
<br />
[http://www.youtube.com/watch?v=vrbmMPlCp3U Desktops to Donuts: Object-Caps Across Scales] by Marc Stiegler<br />
<br />
[http://www.youtube.com/watch?v=8aedCggam4s Core Patterns for Web Permissions] by Tyler Close<br />
<br />
[http://www.youtube.com/watch?v=oE3x_gM3YFU Paradigm Regained: Abstraction Mechanisms for Access Control] by Mark Miller<br />
<br />
[http://www.youtube.com/watch?v=UH66YrzT-_M The Virus Safe Computing Initiative at HP Labs] by Alan Karp</div>Ansiblehttp://wiki.erights.org/wiki/User:AnsibleUser:Ansible2008-02-12T17:07:41Z<p>Ansible: </p>
<hr />
<div>This is the home page on the wiki for James Graves the administrator of this wiki.<br />
<br />
Any questions or issues with the wiki should be posted on the [http://www.eros-os.org/pipermail/e-lang/ E-lang mailing list].</div>Ansiblehttp://wiki.erights.org/wiki/Main_PageMain Page2008-02-12T17:01:27Z<p>Ansible: /* Community */ link to community portal page</p>
<hr />
<div>__NOTOC__<br />
<big>'''Welcome to the ERights.org wiki.'''</big><br />
<br />
'''''E''''' is a secure, [[wikipedia:Distributed computing|distributed]], [[wikipedia:Object-oriented programming|pure-object]] platform and [[wikipedia:Peer-to-peer|P2P]] scripting language for writing [[wikipedia:Object-capability model|''Capability-based'']] [[Smart Contracts]].<br />
<br />
== [[Getting Started]] ==<br />
<br />
[[Getting Started]] - Tips for '''''E''''' newbies<br />
<br />
== What's New? ==<br />
<br />
[http://www.erights.org/talks/index.html#google-abac Google Techtalk series on ABAC] - Authorization Based Access Control.<br />
<br />
[[Future research topics]]<br />
<br />
== [[Documentation]] ==<br />
<br />
* [[Documentation#Books|Books]]<br />
** [[Walnut|'''''E''''' in a Walnut]]<br />
* [[Documentation#Tutorials|Tutorials]]<br />
* [[FAQ]]<br />
* [[Documentation#Papers|Papers]]<br />
* [[Documentation#Talks and Presentations|Talks and Presentations]]<br />
<br />
== [[Downloads]] ==<br />
<br />
* [[Downloads#Releases|Releases]] - ready-to-install versions of '''''E'''''.<br />
* [[Downloads#Subversion|Subversion]] - development code<br />
<br />
==[[Applications]]==<br />
See [[:Category:Applications]].<br />
<br />
== [[Erights:Community Portal|Community]] ==<br />
<br />
[http://www.eros-os.org/pipermail/e-lang/ e-lang mailing list] - discussion of '''''E''''' and other capability languages.<br />
<br />
[http://www.eros-os.org/pipermail/cap-talk/ cap-talk mailing list] - discussion of general issues regarding capability security.<br />
<br />
[http://ircbrowse.com/cdates.html?channel=erights #erights IRC channel] - On the #erights IRC channel at irc.freenode.net, you can talk to a running instance of '''''E ''''' as well as elang-ers online. Try saying "? 2+3".<br />
<br />
== [[Related Sites]] ==<br />
<br />
[http://www.erights.org Main Erights.org site]<br />
<br />
[[wikipedia:E_(programming_language)|'''''E''''' on Wikipedia]]<br />
<br />
[[Object-capability languages]]<br />
<br />
[http://www.combex.com/ Combex, Inc.] - The for-profit facet of the '''''E''''' project, featuring [[CapDesk]] -- the capability secure desktop, and [[caplet]] installation and launching framework.</div>Ansible