Nabble - E Lang

Training & Jobs

2008-12-01T20:20:47Z

“Join us to make future”
[B]FOR OPT/F-1 STUDENTS[/B]
[fuchsia]FREE TRAINING
FOOD ACCOMODATION
H1B PROCESSING[/fuchsia]
[B]FOR L1/ L2/ H1/ H4/ EAD/ GC [/B]
[fuchsia]EXCELLENT OPPRTUNITIES
TRAINING
PLACEMENT[/fuchsia]
[B]Highly Competitive offers for New H1b Transfers[/B]
[B]About Us:[/B]
V2 technology inc is serving NJ since 2005, for us our employees are of utmost importance. Our highly skilled and dedicated instructors train you explicitly in market-related technologies for today and tomorrow. We will work with you in developing marketing strategies and finding the assignments of your choice.
We not only help you get a job but we build your long lasting careers!!!
[B]What are we Looking for:[/B]
[fuchsia]
[*]Excellent communication skills.
[*] Valid F1/ OPT/ CPT/ H1/ H4/ L1 or valid work status
[*] (EAD, GC).
[*] Bachelors’ degree in CS/ IT or previous IT experience.
[*] Preferably (not mandatory) Master's Degree in Computers/ Electronics or previous IT experience.
[*] Willing to relocate anywhere in USA.
[/fuchsia]
[B]What’s The Deal: [/B]
[fuchsia]
[*]H1-B sponsorship to F1/ OPT/ H4/ L1/ L2/ E3/ EAD
[*]Transfer of H1 & L1 visas.
[*]Green Card sponsorship through PERM
[*]Job focused professional training in
[/fuchsia]
[green]
[*]Java/ J2EE
[*].NET
[*]Documentum
[*]Share point
[*]Oracle
[*]Data Modeling
[/green]
[fuchsia]
[*]Relocation assistance- airfare, hotel accommodation, car rental etc
[*]Guarantee lowest bench period.
[*]Employee referral program.
[*]Effective Resume writing help, Marketing and Placement.
[*]Technical mock interviews. Preparation of In Person Interviews
[/fuchsia]
[B]100% Guaranteed placement [/B]
[B]Get in Touch:[/B]
Contact immediately to know more about the opportunities with us at:[B]609-843-0312 [/B]
or
write mail at [B]jobs@v2techinc.com[/B]
Contact person : John

Taming Java Libraries in E vs. Joe-e

2008-11-14T21:44:00Z

Jimmy Wylie writes:
>I haven't seen anything substantial yet. For example, I looked at
>File.java. E has it tamed, but Joe-E has simply suppressed every method.
>(I'm guessing to be safe until taming decisions are made.)

Yeah.

>From reading
>the aforementioned link, I'm guessing it has something to do with the
>resolution of "..". E can wrap the class and check for "..". But, I
>don't see how Joe-E would be able to do that without shipping its own
>version of File.java.

org.joe_e.file.Filesystem is a start at this which addresses
the ".." issue; but still File needs to be tamed before that solves
the issue.

> This leads to other issue I'm having. I'm not really sure what
>classes I can make valid comparisons between. Joe-E is a subset of Java
>while E is its own language. So E has more flexibility in what it can
>do to tame classes.

Yes, there are some differences, though for most Java library classes,
I'd expect the taming issues for Joe-E and E ought to be pretty similar.
(Core types, like Boolean, may be one place where more significant
differences are to be expected.)
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Taming Java Libraries in E vs. Joe-e

2008-11-14T13:46:54Z

On Nov 14, 2008, at 15:18, Jimmy Wylie wrote:

> It seems E may use it in its implementation of its own boolean type,
> but it may also add or remove things, making a simple comparison
> between safej files incomplete.

Look at Sugarings in jsrc/org/erights/e/elib/prim/ScriptMaker.java to
find the classes which add things. This information *should* be in the
safej table but it isn't yet.

> I did actually look at Boolean.safej. In both, the method
> getBoolean()
> was suppressed because it accesses a system property. Joe-E allows
> more
> methods than E it seems, like toString() and parseBoolean(), but those
> seem like methods E wouldn't have to tame because they would be
> implemented elsewhere in the E language.

getBoolean() is probably suppressed because it would be silly in E - E
does not distinguish boxed and unboxed booleans.

toString is universally suppressed for several reasons:
- the default implementation of it exposes pointer bits
(nondeterminism)
- all the rest of java.lang.Object's protocol, including toString,
is suppressed
- E has its own to-string mechanism (E.toString) which has cycle
detection and also uses Java classes' toString when appropriate

(It's been a while since I looked at this stuff; I may be a little
off. MarkM?)

> Also, I do have one other question about the safej files. In Joe-E,
> they use the static tag and instance tag. In E's safej files, they
> use a statics tag and methods tag. Are the methods tag and instance
> tag denoting the same methods?

I don't know Joe-E, but probably yes.

> Or is E using that tag to add its own methods? I noticed in
> Boolean.safej that under "methods", E has listed some methods I
> couldn't find in the Java API like and(), not(), or(), xor(), and
> pick(obj, obj).

These are methods added by E (sugar classes, which are defined in a
table in SafeJ.java). safej files control methods *after* the E
property-mangling, name-mangling and sugaring stages have been
applied. (IMO this should not be the case, but I'm not an expert on
that aspect of the system.)

--
Kevin Reid <http://homepage.mac.com/kpreid/>

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Taming Java Libraries in E vs. Joe-e

2008-11-14T12:18:34Z

Mark Miller wrote:
> Great question! Since taming is a judgment intense process,
> potentially fraught with security-critical errors, the Joe-E folks
> decided to first tame the Java libraries independently, and then
> compare the resulting decisions. Where we largely agree, we're not
> sure what that means -- we might simply have been led into making the
> same errors. But where we disagree, at least we'll know to pay special
> attention to those places. Did you see anywhere where we were both
> taming the same class but arriving at different taming decisions?
>
I haven't seen anything substantial yet. For example, I looked at
File.java. E has it tamed, but Joe-E has simply suppressed every method.
(I'm guessing to be safe until taming decisions are made.) From reading
the aforementioned link, I'm guessing it has something to do with the
resolution of "..". E can wrap the class and check for "..". But, I
don't see how Joe-E would be able to do that without shipping its own
version of File.java.
This leads to other issue I'm having. I'm not really sure what
classes I can make valid comparisons between. Joe-E is a subset of Java
while E is its own language. So E has more flexibility in what it can
do to tame classes. Should I look at classes like Boolean.java? It
seems E may use it in its implementation of its own boolean type, but it
may also add or remove things, making a simple comparison between safej
files incomplete.

I did actually look at Boolean.safej. In both, the method getBoolean()
was suppressed because it accesses a system property. Joe-E allows more
methods than E it seems, like toString() and parseBoolean(), but those
seem like methods E wouldn't have to tame because they would be
implemented elsewhere in the E language.

Also, I do have one other question about the safej files. In Joe-E,
they use the static tag and instance tag. In E's safej files, they use
a statics tag and methods tag. Are the methods tag and instance tag
denoting the same methods? Or is E using that tag to add its own
methods? I noticed in Boolean.safej that under "methods", E has listed
some methods I couldn't find in the Java API like and(), not(), or(),
xor(), and pick(obj, obj).

Thanks again,
Jimmy

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Taming Java Libraries in E vs. Joe-e

2008-11-13T07:01:24Z

Great question! Since taming is a judgment intense process, potentially fraught with security-critical errors, the Joe-E folks decided to first tame the Java libraries independently, and then compare the resulting decisions. Where we largely agree, we're not sure what that means -- we might simply have been led into making the same errors. But where we disagree, at least we'll know to pay special attention to those places. Did you see anywhere where we were both taming the same class but arriving at different taming decisions?

On Wed, Nov 12, 2008 at 7:32 PM, Jimmy Wylie <jwylie@...> wrote:

Hi all,

I'm working on an undergraduate research project, and decided to try my
hands at taming sections of the java library.
I read the following:
http://www.erights.org/elib/legacy/taming.html
and then took a look at the tamed safej libraries in E and then in Joe-e
to see what's already been done. But surprisingly, I noticed a few
discrepancies.

Do E and Joe-e have different goals in mind when taming the libraries?
It seems like a java library tamed to the capability discipline should
work for any capability language. So why are those safej classes not
simply imported to joe-e and vice versa? The most noticeable discrepancy
I noticed was that E has parts of awt tamed while Joe-e does not, but
Joe-e seems to have a few classes that E does not have tamed in its library.

Thanks for your help,
Jimmy Wylie
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

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

Cheers,
--MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Taming Java Libraries in E vs. Joe-e

2008-11-12T19:32:47Z

Hi all,

I'm working on an undergraduate research project, and decided to try my
hands at taming sections of the java library.
I read the following:
http://www.erights.org/elib/legacy/taming.html
and then took a look at the tamed safej libraries in E and then in Joe-e
to see what's already been done. But surprisingly, I noticed a few
discrepancies.

Do E and Joe-e have different goals in mind when taming the libraries?
It seems like a java library tamed to the capability discipline should
work for any capability language. So why are those safej classes not
simply imported to joe-e and vice versa? The most noticeable discrepancy
I noticed was that E has parts of awt tamed while Joe-e does not, but
Joe-e seems to have a few classes that E does not have tamed in its library.

Thanks for your help,
Jimmy Wylie
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Newbie Joe-E questions

2008-11-12T09:45:16Z

Tyler Close wrote:

>
> The ref_send library does not provide direct access to sockets, so I
> wouldn't call it a tamed networking library, but you can use ref_send
> for networking applications. For example, you could certainly use
> ref_send and the Waterken Server to implement a program similar to
> EChat. Similar to the EChat program, you'd write the application in
> terms of methods invoked on references. You can then use the Waterken
> Server to make those references span machine boundaries, like E's
> CapTP protocol does for E references.
>
>

Thanks to all of you for your help. I really appreciate it.
It's really helped get me started. It's also sort of sparked an
interest Taming. I think I may try to explore that
further.

Thanks again,
Jimmy Wylie
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

SWT on OS X now works, better

2008-11-10T16:33:13Z

On Nov 10, 2008, at 7:13, Kevin Reid wrote:

> (For those that don't know, E+SWT+Mac OS X stopped working even as
> well as it had with the introduction of Mac OS X 10.5 Leopard.) ...
> If the main thread, that is the one which public static void
> main(String[] args) is executed in, does not exit, then SWT
> applications work. ... I suspect, even though keeping that thread
> around is *sufficient*, that the *correct* solution is to use that
> special thread as the SWTRunner's thread I will attempt to modify
> the SWTRunner to implement this when I have time.

For now, I have committed the cheap fix: Rune.main now never exits.
Since normal termination of an E JVM is by the Rune$Terminator causing
System.exit(), this does no harm.

Also, due to changes by Apple, SWT apps on Leopard do not need to be
wrapped in an application bundle; i.e. you can do rune myapp.e-swt and
the GUI will function properly, just like for AWT/Swing apps.

Please test my fix, <svn://svn.synchrona.org/erights/e/trunk> revision
513; particularly, let me know if it causes E to not exit properly in
some situations, and whether there's any remaining brokenness in SWT
on OS X or any other platform.

--
Kevin Reid <http://homepage.mac.com/kpreid/>

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Newbie Joe-E questions

2008-11-10T09:27:16Z

Hi Jimmy,

On Sun, Nov 9, 2008 at 1:18 PM, David Wagner <daw@...> wrote:
> Jimmy Wylie writes:
>>First, is there any tamed networking library for Joe-e?
>
> Nope, I don't think so. You get to do your own taming. The Joe-E
> taming database is not yet populated, except in a very minimalistic way.
> I know this is a major annoyance, and I apologize for that.
>
> I don't know whether ref_send would be an appropriate solution.
> Tyler would.

The ref_send library does not provide direct access to sockets, so I
wouldn't call it a tamed networking library, but you can use ref_send
for networking applications. For example, you could certainly use
ref_send and the Waterken Server to implement a program similar to
EChat. Similar to the EChat program, you'd write the application in
terms of methods invoked on references. You can then use the Waterken
Server to make those references span machine boundaries, like E's
CapTP protocol does for E references.

--Tyler
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Found the SWT/OS X/Leopard problem

2008-11-10T04:13:26Z

(For those that don't know, E+SWT+Mac OS X stopped working even as
well as it had with the introduction of Mac OS X 10.5 Leopard.)

I have found a solution to the problem.

If the main thread, that is the one which public static void
main(String[] args) is executed in, does not exit, then SWT
applications work.

This is not too surprising considering that SWT also requires -
XstartOnMainThread - which JVM option makes the JVM execute main() on
the thread that is initially created by the OS.

I suspect, even though keeping that thread around is *sufficient*,
that the *correct* solution is to use that special thread as the
SWTRunner's thread.

I will attempt to modify the SWTRunner to implement this when I have
time.

--
Kevin Reid <http://homepage.mac.com/kpreid/>

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Newbie Joe-E questions

2008-11-09T13:18:28Z

Jimmy Wylie writes:
>First, is there any tamed networking library for Joe-e?

Nope, I don't think so. You get to do your own taming. The Joe-E
taming database is not yet populated, except in a very minimalistic way.
I know this is a major annoyance, and I apologize for that.

I don't know whether ref_send would be an appropriate solution.
Tyler would.

>Second, is there any formal documentation on how to go about taming the
>java libraries?

Unfortunately not. Sorry.

>Third, what sort of programs use Joe-e presently given the minimal state
>of safe libraries?

Right now, Waterken uses Joe-E. That's about it.

>I can already see how the verifier is useful for
>checking for different security issues like static fields and such, but
>currently how do you bypass the library issue to write programs? Do you
>try and tame the libraries you need on your own, or just use the
>libraries you need and cross your fingers hoping java keeps you safe?

The former: tame libraries as needed. Keep in mind that right new only
a few programs have been written in Joe-E, which partly explains why
the taming database is so sparse.
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: yj.Doctor Carlo

2008-11-09T10:43:15Z

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Newbie Joe-E questions

2008-11-09T02:06:09Z

Adrian Mettler wrote:

> Thanks for your interest in Joe-E!
>
> The taming database is defined using .safej files. Placing a file in
> mypackage/ScannerWrapper.safej that lists the constructors, methods, and
> fields from ScannerWrapper class that are safe to use will allow them to
> be used by Joe-E code. I don't currently have good documentation on the
> format of .safej files, but it shouldn't be hard to infer by looking at
> the existing .safej files that are provided for some of the Joe-E
> library classes. There exists code to generate the safej file, but
> unfortunately it isn't currently exposed with a UI -- I may add one for
> the upcoming release.
>
> -Adrian
>
>

Thanks for your help. The Joe-e verifier finally accepted my program.
But I still have a couple more questions, if you don't mind, regarding
taming.

First, is there any tamed networking library for Joe-e? I was going to
try and write a chat application, with Joe-e, similar to the one in E in
a Walnut, but I'm not sure what libraries to use so that the program
will have comparable security properties. Would the ref_send API from
the Waterken server be an appropriate solution? I've only looked at it
briefly

Second, is there any formal documentation on how to go about taming the
java libraries?

Third, what sort of programs use Joe-e presently given the minimal state
of safe libraries? I can already see how the verifier is useful for
checking for different security issues like static fields and such, but
currently how do you bypass the library issue to write programs? Do you
try and tame the libraries you need on your own, or just use the
libraries you need and cross your fingers hoping java keeps you safe?

Thanks again,
Jimmy Wylie

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

DNS for erights.org

2008-11-08T10:18:13Z

Hello all,

I've had occasional failures and general slowness for DNS lookups on
wiki.erights.org. Has anyone else noticed any problems with DNS on
erights.org? I'm trying it right now and getting a timeout.

Best regards,

James
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Fwd: ES3.1 Draft: 07 Nov 2008 "Kona" version available

2008-11-06T14:33:48Z

The EcmaScript 3.1 draft standard is rapidly congealing towards an official standard. The Kona version at <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft> is the important one -- details aside, the only remaining significant unsettled controversy is whether Decimal remains or is pulled from ES3.1.

If you see any significant issues with the Kona version that need fixing, please give us your feedback now, or post to the es*-discuss lists. After the Nov 19/20 meeting, we are hoping to change only typos, bugs, and problems revealed by implementation efforts.

We are quite proud of this draft. Given the maze of bizarre legacy compatibility constraints, I'm amazed at how well we've been able to improve on ES3. The JavaScript language is about to get a lot better.

---------- Forwarded message ----------
From: Pratap Lakshman (VJ#SDK) <pratapl@...>
Date: 2008/11/6
Subject: ES3.1 Draft: 07 Nov 2008 "Kona" version available
To: "es3.x-discuss@..." <es3.x-discuss@...>, "es-discuss@..." <es-discuss@...>
Cc: "e-TC39@..." <e-TC39@...>

I have uploaded to the wiki (link) the 07 Nov 2008 draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document.

This shall be the document to use for review at the upcoming TC39 meeting (19/20 Nov, Kona, Hawaii). If there are any updates or revisions prior to the meeting, we will post them on the wiki as well as on the discuss lists.

pratap

_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

--
Cheers,
--MarkM

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Newbie Joe-E questions

2008-11-03T16:27:08Z

Thanks for your interest in Joe-E!

The taming database is defined using .safej files. Placing a file in
mypackage/ScannerWrapper.safej that lists the constructors, methods, and
fields from ScannerWrapper class that are safe to use will allow them to
be used by Joe-E code. I don't currently have good documentation on the
format of .safej files, but it shouldn't be hard to infer by looking at
the existing .safej files that are provided for some of the Joe-E
library classes. There exists code to generate the safej file, but
unfortunately it isn't currently exposed with a UI -- I may add one for
the upcoming release.

-Adrian

Jimmy Wylie wrote:

> David Wagner wrote:
>> 2) Currently, the Joe-E taming database is very minimalistic. The policy
>> is "deny-by-default", meaning that if we haven't gotten around to taming
>> a particular portion of the Java library, then that portion of the
>> library will be inaccessible to Joe-E code by default -- and we haven't
>> gotten around to taming more than a tiny fraction of the Java library.
>> You might encounter this in other cases, where Joe-E code would like to
>> access some field/method of the Java libraries and where providing
>> access to that field/method would be OK (it wouldn't contradict any
>> capability principles) but because we haven't provided a taming database
>> for that portion of the Java libraries, you can't. In those cases, the
>> only way to proceed would be to extend the taming database yourself.
>> You may be hitting this issue as well (e.g., in the warnings regarding
>> Scanner and PrintStream, which indeed have no taming policy specified
>> for them yet).
>>
>>
>> Let me comment on 1) above some more. The obvious question is:
>> If Joe-E code is never allowed to gain any capabilities on its own
>> (only to receive capabilities passed to it), where does Joe-E code
>> get interesting capabilities from in the first place? This is the
>> bootstrapping problem. The canonical way to deal with this right
>> now is probably to build your application as a combination of Java and
>> Joe-E code. The startup code (e.g., the implementation of main()) might
>> be written in Java. Java code is unconstrained by the Joe-E verifier,
>> so it can directly access System.in and System.out. The startup code
>> would then instantiate some Joe-E classes and invoke them, passing them
>> any capabilities they need to do their job. Thus you might write the
>> bulk of your application in Joe-E. Those Joe-E application classes
>> might expect you to pass them an InputStream and an OutputStream.
>> Your Java startup code could then just instantiate those classes and
>> pass System.in/System.out as an argument to their constructors.
>>
>> I realize this may be a bit confusing; I'm not sure if that made
>> sense. Sorry about that.
>>
>>
>>
> I understand the explanation, but I'm still not sure how to go about the
> solution. I don't actually want to pass an entire Scanner object to my
> UI code, so let's say I do a quick and dirty tame: ScannerWrapper, that
> only allows one or two methods. Then in the constructor for my UI code I
> would say something like:
>
> public exampleUI(ScannerWrapper s){
> myWrapper = s;
> }
>
> However even this would cause the verifier to complain, because now the
> import declaration would be something like:
>
> import mypackage.ScannerWrapper;
>
> which, of course isn't in the taming database. So how do I go about
> modifying the database to allow my own tamed classes?
>
> Thanks again for your help,
> Jimmy Wylie
> _______________________________________________
> e-lang mailing list
> e-lang@...
> http://www.eros-os.org/mailman/listinfo/e-lang

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Newbie Joe-E questions

2008-11-03T16:18:41Z

Jimmy Wylie wrote:
[ introduce a new wrapper ]
> So how do I go about modifying the database to allow my own tamed classes?

Ask Adrian for the definitive answer, but I think you modify the .safej
files (see the taming database download that you presumably installed
when you installed Joe-E).
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Newbie Joe-E questions

2008-11-03T09:00:34Z

David Wagner wrote:

> 2) Currently, the Joe-E taming database is very minimalistic. The policy
> is "deny-by-default", meaning that if we haven't gotten around to taming
> a particular portion of the Java library, then that portion of the
> library will be inaccessible to Joe-E code by default -- and we haven't
> gotten around to taming more than a tiny fraction of the Java library.
> You might encounter this in other cases, where Joe-E code would like to
> access some field/method of the Java libraries and where providing
> access to that field/method would be OK (it wouldn't contradict any
> capability principles) but because we haven't provided a taming database
> for that portion of the Java libraries, you can't. In those cases, the
> only way to proceed would be to extend the taming database yourself.
> You may be hitting this issue as well (e.g., in the warnings regarding
> Scanner and PrintStream, which indeed have no taming policy specified
> for them yet).
>
>
> Let me comment on 1) above some more. The obvious question is:
> If Joe-E code is never allowed to gain any capabilities on its own
> (only to receive capabilities passed to it), where does Joe-E code
> get interesting capabilities from in the first place? This is the
> bootstrapping problem. The canonical way to deal with this right
> now is probably to build your application as a combination of Java and
> Joe-E code. The startup code (e.g., the implementation of main()) might
> be written in Java. Java code is unconstrained by the Joe-E verifier,
> so it can directly access System.in and System.out. The startup code
> would then instantiate some Joe-E classes and invoke them, passing them
> any capabilities they need to do their job. Thus you might write the
> bulk of your application in Joe-E. Those Joe-E application classes
> might expect you to pass them an InputStream and an OutputStream.
> Your Java startup code could then just instantiate those classes and
> pass System.in/System.out as an argument to their constructors.
>
> I realize this may be a bit confusing; I'm not sure if that made
> sense. Sorry about that.
>
>
>

I understand the explanation, but I'm still not sure how to go about the
solution. I don't actually want to pass an entire Scanner object to my
UI code, so let's say I do a quick and dirty tame: ScannerWrapper, that
only allows one or two methods. Then in the constructor for my UI code I
would say something like:

public exampleUI(ScannerWrapper s){
myWrapper = s;
}

However even this would cause the verifier to complain, because now the
import declaration would be something like:

import mypackage.ScannerWrapper;

which, of course isn't in the taming database. So how do I go about
modifying the database to allow my own tamed classes?

Thanks again for your help,
Jimmy Wylie
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: [Caja] Re: Handling infinite loops; browser crashing behavior

2008-10-31T00:01:53Z

On Thu, Oct 30, 2008 at 11:07 PM, Mark S. Miller <erights@...> wrote:
> Oops, I did mean "outside", but I hadn't realized how confusing it
> would be. I meant, as opposed to doing engineering *inside* the
> browser, as Chrome does by placing separate tabs in separately
> killable processes. Browser vendors are in a position to provide
> better protection against denial of service than *outside* systems
> like ADsafe, Jacaranda, MSWebSandbox, FBJS, or Caja.

Scott Isaacs, architect of MS WebSandbox, cc'ed, explained to me their
approach, which we like:

Because JavaScript provides only a single stack, the only choices are
1) Continuation passing transform, such as provided by Narrative
JavaScript <http://www.neilmix.com/narrativejs/doc/>, to effectively
create multiple virtual stacks on the heap.
2) Separate the *killing* of a runaway gadget during a long event from
the pausing and resumption of a gadget at event boundaries.

Neither MS WebSandbox nor Caja are willing to pay the costs of a
pervasive continuation passing transform, so we choose option #2. This
involves

a) instrumenting various flow of control points in the program, such
as loops, so that runaways can be caught.
b) intermediating all asynchronous event notifications, so that
further event processing by a gadget can be suspended and resumed.

>From within an instrumentation point (#a), when the protection
mechanism suspects it has a runaway, it asks the user whether they
want to kill it using a synchronous alert, blocking the entire page.
If the user does decide to kill it, an error (uncatchable by the
gadget's code) is thrown from that instrumentation point. When the
trusted framework code catches this error, it kills this gadget. This
is the only safe choice, since the gadget must now be assumed to be in
an inconsistent state.

This is similar to the Joe-E/Waterken protections from thrown Java
Errors. Joe-E code <http://code.google.com/p/joe-e/> is allowed to
catch only Java Exceptions, not Errors. When the Waterken framework
<http://waterken.sourceforge.net/> catches one of these Errors, if it
decides to continue, it will not resume the Joe-E computation which
threw the Error, since it must be assumed to be in an inconsistent
state.

Scott's excellent talk at <http://channel9.msdn.com/pdc2008/TL29/>
demos their protections against accidental denial of service.

Scott, please correct anything I've got wrong in the above summary. Thanks.

--
Cheers,
--MarkM
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: [Caja] Handling infinite loops; browser crashing behavior

2008-10-30T20:56:43Z

Edward Z. Yang wrote:
> Hello all,
>
> I was wondering what safeguards Caja has against disruptive JavaScript
> (both malicious and non-malicious), such as infinite loops, timeout
> bombs and memory hogs?

None. It's not feasible to do this without the cooperation of the
underlying JavaScript implementation. Perhaps something like that might
come out of the "Secure ECMAScript" work; I'll raise this issue at the
next TC39 meeting on Secure ECMAScript (on November 18th).

Firefox (any other browsers?) will disable JavaScript in a frame if
seems to be unresponsive (I don't know exactly what the criterion is).
However AFAICS from the perspective of a heavy Firefox user, this doesn't
seem to be very effective in preventing severe denial-of-sevice from
JavaScript (even just buggy, not malicious code). In any case this is
independent of Caja.

Facebook/FBJS implements the useful idea of preventing JavaScript from
running at all in a particular gadget until a user clicks on it. Caja
would be able to support this.

The 'e-lang' list <http://www.eros-os.org/mailman/listinfo/e-lang> would
a good place to discuss language-level mechanisms for limiting
denial-of-service. Cc: set.

--
David-Sarah Hopwood

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: YAP: The first deployed object-capability public application platform

2008-10-29T11:56:05Z

On Wed, Oct 29, 2008 at 10:30 AM, Toby Murray
<toby.murray@...> wrote:

> On Wed, 2008-10-29 at 16:48 +0000, Ben Laurie wrote:
>> On Wed, Oct 29, 2008 at 4:20 PM, Toby Murray
>> > A question for the Caja folks: Can I therefore write YAP gadgets in
>> > Cajita, which has always felt like a much nicer language than Caja to
>> > me?
>>
>> I think the answer is currently "no" but will soon be "yes". Right now
>> we don't have a way to switch between Cajita and Valija modes without
>> a flag to the compiler. We're thinking about how to fix that.
>
> On Wed, 2008-10-29 at 09:56 -0700, stay wrote:
>> You can certainly *write* it in cajita, but you won't get all of the
>> benefits yet--it'll still be treated as valija.
>
> Valija? What's that? (Sorry, I've not been following Caja development
> closely. All of my understanding comes from the June version of the spec
> document which I've not read now since.. June.)
>
> Is there a more up-to-date document to which I can refer to make sense
> of the above?

No, we haven't updated that document yet. I intend to start on that this week.

> I thought that Cajita was a subset of everything else. How, then, would
> I not get the benefits of it? Is this Valija thing not a superset of
> Cajita or am I misreading "benefits" above?

Valija is a simulation of (very nearly) ES3.1 strict mode on top of
cajita. A Valija program is rewritten *twice*, once from Valija to
Cajita, and again from Cajita to Javascript. The intermediate
language we'd been calling Caja has been abandoned and "Caja" now
refers to the project as a whole.

If you write your code in Cajita and run it on YAP today, it will
(unnecessarily) be rewritten twice, so it will be slower.
--
Mike Stay
stay@...
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: YAP: The first deployed object-capability public application platform

2008-10-29T10:30:26Z

On Wed, 2008-10-29 at 16:48 +0000, Ben Laurie wrote:
> On Wed, Oct 29, 2008 at 4:20 PM, Toby Murray
> > A question for the Caja folks: Can I therefore write YAP gadgets in
> > Cajita, which has always felt like a much nicer language than Caja to
> > me?
>
> I think the answer is currently "no" but will soon be "yes". Right now
> we don't have a way to switch between Cajita and Valija modes without
> a flag to the compiler. We're thinking about how to fix that.

On Wed, 2008-10-29 at 09:56 -0700, stay wrote:
> You can certainly *write* it in cajita, but you won't get all of the
> benefits yet--it'll still be treated as valija.

Valija? What's that? (Sorry, I've not been following Caja development
closely. All of my understanding comes from the June version of the spec
document which I've not read now since.. June.)

Is there a more up-to-date document to which I can refer to make sense
of the above?

I thought that Cajita was a subset of everything else. How, then, would
I not get the benefits of it? Is this Valija thing not a superset of
Cajita or am I misreading "benefits" above?

Cheers

Toby
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: YAP: The first deployed object-capability public application platform

2008-10-29T09:56:50Z

On Wed, Oct 29, 2008 at 9:48 AM, Ben Laurie <benl@...> wrote:
> On Wed, Oct 29, 2008 at 4:20 PM, Toby Murray
> <toby.murray@...> wrote:
>> A question for the Caja folks: Can I therefore write YAP gadgets in
>> Cajita, which has always felt like a much nicer language than Caja to
>> me?
>
> I think the answer is currently "no" but will soon be "yes". Right now
> we don't have a way to switch between Cajita and Valija modes without
> a flag to the compiler. We're thinking about how to fix that.

You can certainly *write* it in cajita, but you won't get all of the
benefits yet--it'll still be treated as valija.

--
Mike Stay
stay@...
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: YAP: The first deployed object-capability public application platform

2008-10-29T09:48:01Z

On Wed, Oct 29, 2008 at 4:20 PM, Toby Murray
<toby.murray@...> wrote:

> Hi all,
>
> People may be interested to know that YAP (the Yahoo! Application
> Platform) seems to have become the first public object-capability
> application platform. Users can write object-capability applications
> (termed "gadgets") in Caja that can be deployed on the Yahoo!
> Application Platform. From Ben Laurie's blog:
>
> http://www.links.org/?p=410
>
>> Yahoo! require all gadgets to use Caja so that they can be sure the
>> gadgets behave themselves without review. Caja allows the container
>> (i.e. Yahoo!'s platform, in this case) to completely confine the
>> untrusted Javascript (i.e. the gadget, in this case), only allowing it
>> to perform "safe" operations. All other platforms either have to
>> manually review gadgets or take the risk that the gadgets will do
>> something evil to their users.
>
> A question for the Caja folks: Can I therefore write YAP gadgets in
> Cajita, which has always felt like a much nicer language than Caja to
> me?

I think the answer is currently "no" but will soon be "yes". Right now
we don't have a way to switch between Cajita and Valija modes without
a flag to the compiler. We're thinking about how to fix that.

>
> Congrats and cheers
>
> Toby
> _______________________________________________
> e-lang mailing list
> e-lang@...
> http://www.eros-os.org/mailman/listinfo/e-lang
>
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

YAP: The first deployed object-capability public application platform

2008-10-29T09:20:11Z

Hi all,

People may be interested to know that YAP (the Yahoo! Application
Platform) seems to have become the first public object-capability
application platform. Users can write object-capability applications
(termed "gadgets") in Caja that can be deployed on the Yahoo!
Application Platform. From Ben Laurie's blog:

http://www.links.org/?p=410

> Yahoo! require all gadgets to use Caja so that they can be sure the
> gadgets behave themselves without review. Caja allows the container
> (i.e. Yahoo!’s platform, in this case) to completely confine the
> untrusted Javascript (i.e. the gadget, in this case), only allowing it
> to perform “safe” operations. All other platforms either have to
> manually review gadgets or take the risk that the gadgets will do
> something evil to their users.

A question for the Caja folks: Can I therefore write YAP gadgets in
Cajita, which has always felt like a much nicer language than Caja to
me?

Congrats and cheers

Toby
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

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

2008-10-28T12:51:09Z

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

No, it doesn't prevent that sort of problem.

I should have mentioned that you shouldn't use my Lockbox example for
anything real; it's a lame expository example thrown together off the
top of my head without any real thought put to it, and intended only
to illustrate a particular point. If you want to build something for
real it's probably better to instead use a Sealer/Unsealer/Brand that
someone has put some thought into and that has been reviewed (see, e.g.,
the implementations that Tyler has built in Waterken). Sorry that I
failed to include that disclaimer in my original email.

As David Hopwood points out, one serious flaw in the Lockbox example is
that the Lockbox class is not marked as final. There may be other
flaws as well.

If the Lockbox class were marked final, then you could presumably
convince yourself that the particular implementation of Lockbox.unlock()
doesn't actually retain tokens, by reviewing the code. Even better, if
the Lockbox class were marked as final and Immutable, then I think you'd
be able to have some confidence that Lockbox.unlock() doesn't retain
stolen tokens, because the unlock() method would not have access to any
mutable state where it could preserve those tokens after it returns.
In the latter case the Joe-E static type system would be helping (by
reducing the burden on code review).
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: LockBox and static typing

2008-10-28T10:11:46Z

Toby Murray wrote:

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

Note that analogous security abstractions in the real world are subject
to similar attacks. For example, if I put my credit card in a fake ATM
or a fake PIN Entry Device, then that device can steal my credit card
details. So one might hope that users of this kind of abstraction are
aware of that class of attacks, and do not automatically assume that an
arbitrary alleged-Lockbox cannot steal the token.

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

No, because Lockbox is not a final class. If it were a final class, and
if its code had been security reviewed, then a client of an object of
type Lockbox (in the correct package) could depend on the properties
established by that review.

--
David-Sarah Hopwood

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

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

2008-10-28T03:49:07Z

On Mon, 2008-10-27 at 21:55 -0700, David Wagner wrote:

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

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

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

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

Cheers

Toby

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Newbie Joe-E questions

2008-10-27T21:55:07Z

Jimmy Wylie writes:

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

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

There are two potential issues here:

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

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

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

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

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

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

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

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

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

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

Nope.

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

Nope. Just write your mutable classes like normal (ignore Token,
and don't do anything special -- you don't have to subclass any
preexisting special class or anythign like that).
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Newbie Joe-E questions

2008-10-27T20:47:01Z

Hi all,

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

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

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

Thanks for your help,
Jimmy Wylie
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

VIAGRA ® Official Site

2008-10-24T18:19:33Z

CBSNews.com

	» Unsubscribe / Delivery Options
October 22, 2008 \| Morning Edition

Contact: Email Administrator, CBSNews.com, 524 W. 57th St., Room 514/1, New York, NY, 10019
©MMVIII, CBS Interactive Inc. All Rights Reserved.
To unsubscribe or change your subscription options, click here.

» Help »Advertise »Terms of Service »Privacy Policy

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Sending files with E?

2008-10-11T06:26:38Z

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

I propose this classification of solutions:

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

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

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

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

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

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

Comments? Missed options?

--
Kevin Reid <http://homepage.mac.com/kpreid/>

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: AST view of E program

2008-10-11T05:19:21Z

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

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

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

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

This is the method you want, for basic usage:

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

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

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

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

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

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

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

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

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

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

--
Kevin Reid <http://homepage.mac.com/kpreid/>

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Re: Clueless with Joe-E and Eclipse

2008-10-10T16:31:23Z

Thanks for your interest in Joe-E!

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

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

Dominique Quatravaux wrote:

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

_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang

Clueless with Joe-E and Eclipse

2008-10-10T09:12:45Z

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

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

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

--
Dominique Quatravaux
+41 79 609 40 72
_______________________________________________
e-lang mailing list
e-lang@...
http://www.eros-os.org/mailman/listinfo/e-lang