gmane.comp.lang.e.general

v8ken: orthogonally persistent JavaScript

Tom Van Cutsem — 2013-03-29T17:00:49

Hi,

As some of you may know, my student Gillis has been working for some
time on v8-ken, which integrates the CKen [1] library with the v8
Javascript engine. The result is an orthogonally-persistent Javascript
engine. This is a key piece of the larger Dr. SES [3] puzzle.

I thought I'd send an update of how this work is progressing.

A couple of weeks ago, Gillis managed to overcome a few critical bugs
that now allow us to successfully restore a JS session from a heap
state file. I wouldn't use v8-ken for anything serious at this point,
but this is a huge milestone: it's now possible to crash a v8ken
process and restart it without loss of either local data, or messages
in-flight.

v8ken's messaging system is based on that of Ken (reliable,
FIFO-ordered messages carried over UDP). The message-passing interface
is fairly primitive at this point: simple unidirectional send and
receive of JSON-serialized messages, directed to vat IDs. No E-style
far references or promises, although that can probably all be laye

Fwd: a future caller alternative ?

Mark Miller — 2013-03-10T01:56:52

Brendan is the inventor of JavaScript, leader of the EcmaScript standards
efforts, and CTO of Mozilla. This clear unequivocal statement from him
shows how far we've come. This is one to frame -- I will.

Thanks Brendan!

---------- Forwarded message ----------
From: Brendan Eich <brendan-4eJtQOnFJqFBDgjK7y7TUQ< at >public.gmane.org>
Date: Sat, Mar 9, 2013 at 5:02 PM
Subject: Re: a future caller alternative ?
To: "Mark S. Miller" <erights-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org>
Cc: "es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org" <es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org>

Mark S. Miller wrote:

Any access control system with hand-coded access monitoring in a big C++
codebase will be.

In SpiderMonkey + Gecko in Firefox, and probably in other browsers, we
actually use OCap under the hood and have for years. In HTML5, the
WindowProxy/Window distinction was finally specified, as an ad-hoc instance
of OCap membranes.

Any time we deviate from OCap, we regret it for both security bug and
access-checki

Re: Pessimistic STM

Raoul Duke — 2013-02-20T00:26:14

makes me think of node.js

Pessimistic STM

Sandro Magi — 2013-02-19T06:24:41

This paper may interest those who follow E and other event loop systems. 
Some recent results in the STM world indicate that single-threaded 
pessimistic STM is competitive with optimistic STMs due to the lower 
incidence of aborts and reduced thread sync required:

http://transact2012.cse.lehigh.edu/papers/matveev.pdf

Event loops are similarly single threaded due to the possibility of 
writes. A language that tracks side-effects could implement an E-style 
event loop and execute all enqueued read-only messages in parallel.

Sandro

Re: Wiki URL configuration

Kevin Reid — 2012-12-01T16:46:25


Great! I've poked around and haven't found any URL-related problem (but I can reproduce the related-changes error).

By the way, I noticed that the interwiki link table seems to have been lost (e.g. links to wikipedia:foo are showing up as local), and I don't see a page to edit it from. Could you restore the original interwiki table?

Re: Wiki URL configuration

James Graves — 2012-12-01T16:00:15

Hello All,

I got another chance to look at the Apache2 setup for the wiki.  I
believe I've got the rewrite rules configured correctly.

All is not perfect (of course).  I clicked on the related changes
link, and got an SQL syntax error.  I briefly turned on SQL error
reporting to see see this:

----------------------------------------------------------------------------


A database query syntax error has occurred. This may indicate a bug in
the software. The last attempted database query was:

    (SELECT recentchanges.*,wl_user,ts_tags FROM recentchanges LEFT
JOIN watchlist ON ((wl_user=2 AND wl_title=rc_title AND
wl_namespace=rc_namespace)) LEFT JOIN tag_summary ON
((ts_rc_id=rc_id)) INNER JOIN pagelinks ON ((rc_namespace =
pl_namespace AND rc_title = pl_title)) WHERE (rc_timestamp >=
'20121124000000') AND rc_bot = '0' AND pl_from = '1583' ORDER BY
rc_timestamp DESC LIMIT 50 ) UNION (SELECT
recentchanges.*,wl_user,ts_tags FROM recentchanges LEFT JOIN watchlist
ON ((wl_user=2 AND wl_title=rc_title AND wl_

Catalog of ERights project services and dependencies

Kevin Reid — 2012-11-25T19:04:30

I have sketched out a wiki page with information about centralized services that are part of the ERights project. The goal is to document who can be contacted about a service being down, and to provide an overview of our current robustness and possible desirable migrations.

current bogus url: http://wiki.erights.org/mediawiki/index.php/Services
broken proper url: http://wiki.erights.org/wiki/Services

If you have any additional information, please post it to the wiki (if you don't have a wiki account I can make one for you), or reply to this message.

Wiki URL configuration

Kevin Reid — 2012-11-25T18:41:04

This is your irregularly-scheduled reminder that wiki.erights.org needs its pretty-URL configuration done.

Re: Idle musings on doing E over again

Lex Spoon — 2012-11-18T13:42:33

Paul raised the question of an ocap version of Scala about a month and
a half ago. Here's a very late reply with some thoughts on that.

Here are two overall strategies to keep in mind:

1. Use a compiler plugin to restrict the language to what is allowed.
This is one of the two places where a compiler plugin shines (the
other one being to refine the type system).

2. Start with Joe-E, modified for the Scala syntax. That will already
be a very reasonable language, and you could work out from there,
adding one restricted feature at a time after you analyze it for
ambient authority.


Here are some thoughts on the language itself:

1. It looks valuable to restrict case classes be real data holders, at
least unless they have some kind of < at >Unsafe annotation on them (do
other ocap variants have such an escape hatch?). I recall there was
some exploration in E of various kinds of frozen and transparent
data-holder objects. Similar things can be done in Scala-E by
restricting case classes: no mutable vars, no non-se

Re: cap-talk

Mark S. Miller — 2012-11-09T16:36:51

No. It's just not very active at the moment. Feel free to restart by making
provocative posts there ;).


On Thu, Nov 8, 2012 at 10:39 PM, Rob Meijer <capibara-qWit8jRvyhVmR6Xm/wNWPw< at >public.gmane.org> wrote:

cap-talk

Rob Meijer — 2012-11-09T06:39:29

I know its off-topic, but given that many people are on both this and the
cap-talk mailing-list, maybe someone here knows.

Has the cap-talk mailinglist been discontinued?

Re: “Verb tuples” for properties, faceting, and namespacing methods

Norman Hardy — 2012-11-04T01:44:09

On 2012 Nov 3, at 15:53 , Kevin Reid wrote:


Consider the standard Scheme code:
(define cc (lambda () (let ((c 0)) (cons
    (lambda () (set! c (+ c 1))) ; incrementer
    (lambda () c))))) ; getter
It returns a pair of functions which I presume you would call 'properties'.
One difference is that the neither party need name the properties.
That difference is sometimes good and sometimes bad.
(I dislike language constructs that force you to name something before you can use it. A minor annoyance.)
The caller of cc can disseminate them to others as a pair or individually.
This latter is an advantage over most OO systems where you can only attenuate the 'object' by defining new objects.

Said another way does "foo.bar(13)" mean "(foo.bar)(13)"?
If so then the language is easier to understand and you have this possibility of direct dissemination.
You can use "foo.bar" as an argument; it is a mere function.

All this raises the issue of sibling communication.
In C++ and several other OO languages the text "A.b"

“Verb tuples” for properties, faceting, and namespacing methods

Kevin Reid — 2012-11-03T22:53:36

Properties: the motivating use case
-----------------------------------

There are a number of uses for having “properties” in a language. By properties, I mean that an object's interface presents explicitly named references to other objects, which may be able to be replaced or otherwise operated on. Some other languages have idioms for defining properties, (Java)
  class Foo {
    String getBar() { ... }
    void setBar(String s) { ... }
  }
and some provide properties as a fundamental element, even giving them priority, including Python and (JavaScript)
  var foo = {
    bar: "initial value"
  };

Properties can be seen as in opposition to object-oriented programming, because they encourage the view of an object as state without behavior, as being not an active participant in the system. However, object-orientedness is not all there is to be had, and here are some use cases for properties which I see as relevant:

* Record types. The difference between a map and a record is that a
  record's interface

Re: Idle musings on doing E over again

Kevin Reid — 2012-10-31T02:56:36


Yes.


This is a particular case of the general distributed programming problem. It should be possible that if you have two instances of the same 'application' in two vats, then a record delivered between them preserves its type; on the other hand, it should be possible to not have 'the same application' on the other end and get an untyped record.

Here is one possible strategy, described in terms of current E:

Let us assume that CapTP uses Data-E serialization, with one customization: on the receiving end, if any given *call* (i.e. object construction/lookup) fail, then instead of aborting the unserialization, a broken reference is substituted. (This is probably a good idea for robustness, anyway: you would like to be able to make use of the parts of the message you understand.)

Then, suppose that the Portrayal of a typed record is a call to

 toTypedRecord(type :RecordGuard, values :UntypedRecord)

which has this behavior: if the _type_ argument is a broken reference, then it returns an untyped record.

Wiki URLs

Kevin Reid — 2012-10-28T22:05:56

This is your irregularly-scheduled nag mail. How's setting up the pretty MediaWiki URLs on wiki.erights.org coming?

I notice that /wiki/* is redirecting to Main_Page, not even the specific page URL, so all external "deep" links to the wiki are currently broken, which is bad.

Re: Semicolon wrangling (was Re: [friam] Minutes)

Jonathan S. Shapiro — 2012-10-21T07:56:51

In most languages, support for "trailing separators" (that is: terminators)
tends to be very *ad hoc*. For example, a trailing ',' eventually came to
be permitted in C/C++ enumerations, but not in arguments.

introduce parse ambiguities that can take a fair bit of grammar complexity
to work around. That seems like a high price to pay.

In later versions of BitC, the issue was resolved by making many separators
optional in much the way that was done in Haskell and similar languages. A
stateful intermediate pass is injected between the parser and the lexer
that inserts missing tokens (in our case mainly based on indentation). In
the usual algorithm, most such separators end up turning into terminators
(i.e. the last one is no longer optional by the time the parser is seeing
the token stream). The intermediate pass is stateful mainly because it
needs to keep track of various forms of brackets, and because the main
grammar requires two-token lookahead to identify missing tokens in certain
cases and can end up pu

Re: Semicolon wrangling (was Re: [friam] Minutes)

Lex Spoon — 2012-10-21T05:14:03

On Fri, Oct 19, 2012 at 10:10 PM, William ML Leslie
<william.leslie.ttg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Python is one such.  In Python, for most any form of sequence in the
syntax, you can optionally add an extra separator at the end of the
list. This rule includes arguments to function calls; f(x,y,z,) in is
the same as f(x,y,z).

The trailing commas help with code generation, and also for humans
editing code. For example, consider the following code in Python or
JavaScript:

names = [
  "Fred",
  "Wilma",
  "Bam Bam",
]

The trailing comma makes the code more regular, which makes it easier
to edit. For example, you can swap any two lines in the list without
having to fix up the commas afterwards.

Once you allow a trailing comma for lists, it is hard to resist
allowing it for function calls (Python only):

set_names(
  "Fred",
  "Wilma",
  "Bam Bam",
)

It gets worse if you have nesting. Consider the following example of
JSON, which does not permit trailing commas:

{
  "name": "Fred",
  "

Re: Semicolon wrangling (was Re: [friam] Minutes)

William ML Leslie — 2012-10-20T02:10:08

Some languages do support this in function arguments, I don't think it
is such a bad thing.  It means one less thing to have to worry about
when generating code from a language that doesn't have a sensible
reduce/join, or generating code from within emacs (it would be
/really/ useful in SQL).

If the meaning of the comma there can be confused with some other
usage of commas within the language, there's probably a deeper issue.


This point seems the most interesting to me.  If the target language
doesn't have implicit return (from functions/methods) the issue is
somewhat mitigated because you can see immediately if the value is
being discarded or used somehow.


Something I find unclear in the remaining discussion is the precedence
of the operations mentioned.  I took it that a newline was supposed to
be just like a semicolon, but then I wonder if

^def foo := makeFoo(); foo.setBar(baz)

binds foo to the result of makeFoo() or foo.setBar(baz).

I mean that, if this last-value feature of semicolon has any us

Semicolon wrangling (was Re: [friam] Minutes)

Kevin Reid — 2012-10-20T00:11:57


Thank you for writing this down! I'll try to fill in my own notes on the topic, using yours as a skeleton.


For what it's worth, as a general rule in such languages, this is only permitted, or at least only used in practice, in uniform/variable-length things such as collection literals, not function arguments.


This is a fair summary of the issue. I raised today's syntactic topics mostly in search of a nice answer (nicer than E's current ones) to the accidental return value problem, which is critical when your values are authority-bearing.

An elegant yet horrible approach to keep the semicolon operator is that

    foo(); bar(); baz()

yields the value of baz whereas

    foo(); bar(); baz();

does not.


That is,

  foo(); bar(); ^baz()

yields baz(); or as generalized by Alan Karp,

  foo(); ^bar(); baz()

yields the value of bar() but also still evaluates baz() after bar(). Alan thought this would be useful, and I slightly agree; a simple use case is where you wish to initialize some object in an imp

Re: Idle musings on doing E over again

Karp, Alan H — 2012-10-15T15:00:56

That's exactly what Stiegler and I did for SCoopFS.  The UI running in the browser uses the waterken back end for persistence.  We used this approach to avoid Marc having to change the Java code every time I decided I needed to stash a new piece of information.  The downside is that the map field is essentially untyped, so you lose the advantages (Well, I think they are advantages.) of compile-time type checking.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp

Re: Idle musings on doing E over again

Thomas Leonard — 2012-10-15T10:46:19

Is the type of a record visible to E?

If not, records are basically just Maps, and the guards just verify the 
structure. Not running the guards repeatedly is simply an optimisation.

However, that's a bit odd, because the guards will only be called when 
passing record between vats, not within a vat, and this difference will be 
visible. It's not necessarily a problem, but a bit un-E-like. Unless record 
guards are more limited than regular guards (e.g. pure functions which 
verify but do not coerce).

If the type of a record is visible to E (e.g. a User behaves differently to 
a NewUser), then sending a record to a remote vat must also send its type 
information. Again, that will be tricky with user-specified guards, since 
they can't travel in general.

How are you planning to implement them?