headers
Kevin Reid | 2 Aug 2005 17:27

Re: newbie question: multiple vats?

On Aug 2, 2005, at 0:54, acd dfg wrote:

> I've just started learning about E (I'm reading "E in a Walnut" now) 
> and saw this question in the FAQ:
>
>> 3.2. If an E process is single-threaded, how to take advantage of 
>> parallelism (e.g. on SMP's)?
>>
>> [To be answered: micro-parallelism and/or multiple vats]
>
> I didn't see an answer for this in "E in a Walnut" or via Google, so I 
> was wondering:
>
> If I were doing a producer/consumer exercise in Java with n producers 
> and 1 consumer, I'd create n producer threads and 1 consumer thread.  
> How would this sort of thing be handled in E?

Here's a simple and silly example showing how to set up several vats to 
perform parallel computations.

#!/usr/bin/env rune

pragma.enable("easy-return")
pragma.disable("explicit-result-guard")

# Necessary for general inter-vat communication.
introducer.onTheAir()

# A simple interface for creating a vat.
def seedVat := <import:org.erights.e.elang.interp.seedVatAuthor> \
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Graves | 3 Aug 2005 18:18
Favicon
Gravatar

Common Lisp and E concepts

A long time ago, in a galaxy far, far away, we briefly discussed how far
down the road of E concepts we could go with Common Lisp, while
retaining compatability (mostly).  Here's the post from Mark Miller:

http://www.eros-os.org/pipermail/e-lang/2005-april/010572.html

Mark Miller mentioned some structural changes to Common Lisp that he
thought would be needed.  Two of these I think I understand:

The CL package system - While we have the ability to set up separate
namespaces, you can just prefix the package name for any symbol in that
package to access it, even if you didn't export the symbol.

CLOS - It is possible to define new methods for any class, no matter
where or when.  So we'd need to restrict that in a sensible fashion.

Mark also mentioned that the default CONS operation should make
immutable cons cells.

I can't think of any reason why this would be necessary.  It certainly
isn't the case for Scheme48, for example.  Could someone clue me in?

Thanks,

James Graves
Permalink | Reply | 5 comments |
headers
Mark Miller | 3 Aug 2005 02:01

[Fwd: [fc-announce] CFP FC'06: Financial Cryptography and Data Security]


-------- Original Message --------
Subject: [fc-announce] CFP FC'06: Financial Cryptography and Data Security
Date: Tue, 2 Aug 2005 13:58:29 -0400
From: Avi Rubin <rubin@...>
To: fc-announce@...

                            Call for Papers

             FC'06: Financial Cryptography and Data Security
                          http://fc06.ifca.ai/

                     Tenth International Conference
                      February 27 to March 2, 2006
                      Anguilla, British West Indies

                 Submissions Due Date: October 17, 2005

Program Chairs: Giovanni Di Crescenzo (Telcordia)
                 Avi Rubin (Johns Hopkins University)

General Chair: Patrick McDaniel (Penn State University)

Local Arrangements Chair: Rafael Hirschfeld (Unipay Technologies)

At its 10th year edition, Financial Cryptography and Data Security
(FC'06) is a well established and major international forum for
research, advanced development, education, exploration, and debate
regarding security in the context of finance and commerce. We will
continue last year's augmentation of the conference title and expansion
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 5 Aug 2005 23:55

Then Chen-Miller only-once

Hao Chen (of Berkeley) and I invented this nice little abstraction today, so,
for the record:

----------------------
# Copyright 2005 Hao Chen, Mark S. Miller under the terms of the MIT X license
# found at http://www.opensource.org/licenses/mit-license.html

pragma.enable("easy-return")

/**
  * The Chen-Miller only-once access-control abstraction.
  * <p>
  * For example, if Alice has pair = [rightToReadSecret, rightToSpeakOnNet],
  * Alice can choose to give Bob the result of makeOnlyOne(pair). Bob can
  * now employ either one, but whichever one he uses first precludes him from
  * ever using the others.
  *
  *  <at> author Hao Chen
  *  <at> author Mark S. Miller
  */
def makeOnlyOne(baseCaps :any[]) :any[] {
     var optWhich :nullOk[int] := null
     var result := []
     for i => baseCap in baseCaps {
         def wrapper {
             to __printOn(out :TextWriter) :void {
                 if (i == optWhich) {
                     baseCap.__printOn(out)
                 } else {
                     out.print(`<wrapper $i>`)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 5 Aug 2005 23:57

Then Chen-Miller only-one

[Corrected title only. Please respond to this one.]

Hao Chen (of Berkeley) and I invented this nice little abstraction today, so,
for the record:

----------------------
# Copyright 2005 Hao Chen, Mark S. Miller under the terms of the MIT X license
# found at http://www.opensource.org/licenses/mit-license.html

pragma.enable("easy-return")

/**
  * The Chen-Miller only-once access-control abstraction.
  * <p>
  * For example, if Alice has pair = [rightToReadSecret, rightToSpeakOnNet],
  * Alice can choose to give Bob the result of makeOnlyOne(pair). Bob can
  * now employ either one, but whichever one he uses first precludes him from
  * ever using the others.
  *
  *  <at> author Hao Chen
  *  <at> author Mark S. Miller
  */
def makeOnlyOne(baseCaps :any[]) :any[] {
     var optWhich :nullOk[int] := null
     var result := []
     for i => baseCap in baseCaps {
         def wrapper {
             to __printOn(out :TextWriter) :void {
                 if (i == optWhich) {
                     baseCap.__printOn(out)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 5 Aug 2005 23:59

Then Chen-Miller only-one

[Sigh, another "once" -> "one" typo fixed. Please reply to this one.]

Hao Chen (of Berkeley) and I invented this nice little abstraction today, so,
for the record:

----------------------
# Copyright 2005 Hao Chen, Mark S. Miller under the terms of the MIT X license
# found at http://www.opensource.org/licenses/mit-license.html

pragma.enable("easy-return")

/**
  * The Chen-Miller only-one access-control abstraction.
  * <p>
  * For example, if Alice has pair = [rightToReadSecret, rightToSpeakOnNet],
  * Alice can choose to give Bob the result of makeOnlyOne(pair). Bob can
  * now employ either one, but whichever one he uses first precludes him from
  * ever using the others.
  *
  *  <at> author Hao Chen
  *  <at> author Mark S. Miller
  */
def makeOnlyOne(baseCaps :any[]) :any[] {
     var optWhich :nullOk[int] := null
     var result := []
     for i => baseCap in baseCaps {
         def wrapper {
             to __printOn(out :TextWriter) :void {
                 if (i == optWhich) {
                     baseCap.__printOn(out)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 6 Aug 2005 02:27

Re: Common Lisp and E concepts

James Graves wrote:
> A long time ago, in a galaxy far, far away, we briefly discussed how far
> down the road of E concepts we could go with Common Lisp, while
> retaining compatability (mostly).  Here's the post from Mark Miller:
> 
> http://www.eros-os.org/pipermail/e-lang/2005-april/010572.html

Almost. Here's a working URL:

   http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html

> Mark Miller mentioned some structural changes to Common Lisp that he
> thought would be needed.  Two of these I think I understand:
> 
> The CL package system - While we have the ability to set up separate
> namespaces, you can just prefix the package name for any symbol in that
> package to access it, even if you didn't export the symbol.

Yes. Although it might be simpler to just kill the package system than try to 
save it.

> CLOS - It is possible to define new methods for any class, no matter
> where or when.  So we'd need to restrict that in a sensible fashion.

Yes. Although it might be simpler to just kill CLOS than to try to save it.

> Mark also mentioned that the default CONS operation should make
> immutable cons cells.
> 
> I can't think of any reason why this would be necessary.  It certainly
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Miller | 7 Aug 2005 03:03

CaPerl

I just heard that Ben Laurie is trying to make a capability-safe variant of 
Perl. A bit of web searching reveals Ben's paper 
<https://www.opengroup.org/projects/jericho/uploads/40/8299/8_-_JFChallenge_Lawrie.pdf> 
on his new language, CaPerl.

--

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
Permalink | Reply | 0 comments |
headers
Mark Miller | 7 Aug 2005 03:35

All bugs now on SourceForge

Steve Jenson has put in a rather amazing amount of work to move all our old 
bugs manually onto SourceForge, adding them at 
<https://sourceforge.net/tracker/?group_id=75274&atid=551529>
to Darius Bacon's epan project pages. Much thanks to Steve for preserving 
continuity of our bug database following the loss of its previous site!

I've already noticed and fixed various minor bugs that resulted from this 
manual move. No doubt there are more. Any that you spot, please fix, report, 
or just email me about. Thanks.

--

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
Permalink | Reply | 2 comments |
headers
Mark Miller | 7 Aug 2005 21:17

Announcing E 0.8.35f: Objects now take multiple matchers

At http://www.erights.org/download/0-8-35/index.html

As Kevin has suggested, The E syntax which allows an object definition to have 
multiple matchers is no longer expanded to a single Kernel-E matcher. Rather, 
Kernel-E now directly allows an object to have multiple matchers. The Miranda 
behaviors of __respondsTo/2 and __getAllegedType/0 have also been changed as 
Kevin suggested, so that objects with match clauses used for purposes other 
than delegation now respond to these two requests reasonably.

Since this is a structural change in Kernel-E and the ETreeVisitor API, it 
does effect Kevin & Dean. Normal E users should be unaffected by this change.

This closes out bug "__getAllegedType/0 doesn't work on objects with matchers"
http://sourceforge.net/tracker/index.php?func=detail&aid=1211088&group_id=75274&atid=551529

It also closes or addresses other bugs listed at
http://www.erights.org/download/0-8-35/highlights.html#bugs

--

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM
Permalink | Reply | 0 comments |

Gmane