http://permalink.gmane.org/gmane.comp.lang.e.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.e.general/4776 <pre> Right, so exceptions are considered to be data (anyone can construct any exception; they convey no authority). So if I did something like: try { ... } catch ex :SQLException { ... } then there's no guarantee that "ex" really is an SQLException (the exception could have been generated by code with access only to safeScope). Seems sensible. What changes are needed to make this all work? - change exception guards to use __getAllegedType() for EBacktraceException (or whatever is used as the generic type). - change CapTP to turn exceptions into this type Would this be a good time to put the stack trace / cause / supressions into a sealed box too? </pre> Thomas Leonard 2012-05-16T08:41:22 http://permalink.gmane.org/gmane.comp.lang.e.general/4775 <pre> Just a clarification: there is certainly not a general E idea of *throwing out exception type information*, or rather, insofar as there is, it is because our exception handling is severely immature. There has not been enough (design response to) E application code which actually needs to recover from specific errors. The prototype and plans I referred to are about making exception types a matter of data rather than distinct classes, not about throwing out exception types entirely. </pre> Kevin Reid 2012-05-15T10:03:31 http://permalink.gmane.org/gmane.comp.lang.e.general/4774 <pre> Good points. Having custom logic for Throwables seems OK (since the code already special-cases Throwable in JOSSPassByConstruction.HONORARY). Losing the exception type seems OK to me, since it fits in with the general E idea of exceptions not having interesting types. And in fact, I usually turn all exceptions into RuntimeException if they might go over CapTP, since the receiver often doesn't have the exception type in its classpath. </pre> Thomas Leonard 2012-05-15T08:33:58 http://permalink.gmane.org/gmane.comp.lang.e.general/4773 <pre> [...] [...] The E-on-Java runtime assumes that arrays it encounters are used as if they are immutable, and treats them as equivalent to ConstLists. Note that getSuppressed returns an array; the problem here would seem to be (from your description) that Throwable uses a List rather than an Array in its *serialization* only. Indeed, this would seem to be wrong-in-general insofar as a RO list might be used elsewhere. However, E code should not in general be using Java collections directly, so that would be OK except for the ELib-as-Java-library aspect. Is there any possible way we could specially treat UnmodifiableList iff it is being serialized from inside the serialization of a Throwable? Well, in the long run we want to replace JOSS with Data-E, so this is a temporary workaround anyway. What I would do is write or modify a replacer to recognize Throwables and serialize them into E-friendly parts. However, we have the problem of creating appropriate subclasses rather than generic Throwable/Exception/</pre> Kevin Reid 2012-05-14T16:35:41 http://permalink.gmane.org/gmane.comp.lang.e.general/4772 <pre>With Java 7, Throwables can no longer be sent successfully over CapTP. The error is: === 2012-05-14T14:44:15.109Z (CapTPConnection.whyNoDeliverOnlyOp:CapTPConnection.java:837) WRN captp: whyNoDeliverOnlyOp(4, run, java.lang.ClassCastException: cannot assign instance of org.erights.e.elib.ref.OldFarRef to field java.lang.Throwable.suppressedExceptions of type java.util.List in instance of java.lang.ClassCastException) --vvvv-- cannot assign instance of org.erights.e.elib.ref.OldFarRef to field java.lang.Throwable.suppressedExceptions of type java.util.List in instance of java.lang.ClassCastException java.lang.ClassCastException: cannot assign instance of org.erights.e.elib.ref.OldFarRef to field java.lang.Throwable.suppressedExceptions of type java.util.List in instance of java.lang.ClassCastException at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2063) at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1241) at</pre> Thomas Leonard 2012-05-14T14:54:56 http://permalink.gmane.org/gmane.comp.lang.e.general/4771 <pre> I _totally_ forgot about that. I've edited the Apache configuration and restarted MediaWiki. I've actually had the new box sitting around for a while, so we should probably upgrade to that first. I'll be installing the new Ubuntu 12.04 LTS release on it over the weekend, and trying that out. After that I'll probably install MediaWiki using the SQLite3 backend, because it will be easier to maintain / back up. The wiki doesn't get enough traffic to need a high-performance backend. BR, James </pre> James Graves 2012-04-27T16:56:50 http://permalink.gmane.org/gmane.comp.lang.e.general/4770 <pre>wiki.erights.org still thinks its canonical hostname is its IP address, which is causing it to generate inappropriate URLs and so interfering with performing authenticated actions and spidering. Please fix. It is making the daily spam-fighting unnecessarily tedious. If it is convenient while you're working on this, please enable the MediaWiki API, as this will assist in the upcoming specification/testing project. &lt;http://wiki.erights.org/w/api.php&gt; claims that it is straightforward to do so. </pre> Kevin Reid 2012-04-27T16:19:00 http://permalink.gmane.org/gmane.comp.lang.e.general/4769 <pre> Kevin - I think your basic plan is headed in the right directions. I haven't spent much time studying them, but there is nothing on the surface that seems wrong. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Truth and love must prevail | Periwinkle (408)356-8506 | over lies and hate. | 16345 Englewood Ave www.pwpconsult.com | - Vaclav Havel | Los Gatos, CA 95032 </pre> Bill Frantz 2012-04-12T00:17:56 http://permalink.gmane.org/gmane.comp.lang.e.general/4768 <pre>People ------ (a) As far as I know, no one is currently actively working on E implementation or major public E-related projects. If I'm wrong, then please make it clear by talking about your progress on e-lang! (b) MarkM appointed me maintainer. I have been primarily occupied with schoolwork; the miscellaneous nature thereof has tended to discourage me from working on significant projects (or so I excuse myself). I hope that this situation will change after I graduate or after I start my job, which will occur in May and July of this year, respectively; however, I cannot promise where my enthusiasm will lie. Regardless, I will take the time to *review patches* should anyone else provide them. Please do let me know if I've been neglecting such. Plans ----- We have several different E implementations. (This is largely my fault.) However, they feel little pressure to converge, and innovations do not tend to be replicated/backported. Therefore, I feel that what we most need is an E specification and accompan</pre> Kevin Reid 2012-04-11T12:38:24 http://permalink.gmane.org/gmane.comp.lang.e.general/4767 <pre> Hey Peter. Thanks for the note above. Sorry to take so long to notice it. I'm not particularly active on the e-lang list. I started going through the above presentation and find it interesting to see how a modern effort to incorporate dataflow is working. I find it quite interesting to see the reference to val (I worked at LLNL while val was under development. I also interacted some with Jack Dennis in the earlier days). I wonder if you might be able to give me some information that would perk my interest more or less: I'm particularly interested in any programming language that supports data flow and could in principle run on native data flow hardware - which I happen to have some simulations of. This hardware has no random access memory. Programs are more like volume (2d or 3d) consuming data flow modules, building up bigger ones from smaller ones. Any thought on whether Scala might be able to be adapted to compile to such an architecture? Does it require random access memory/arrays? Thanks fo</pre> Jed Donnelley 2012-03-12T05:23:53 http://permalink.gmane.org/gmane.comp.lang.e.general/4766 <pre>The Ozma language extends Scala with declarative dataflow, and fits it very nicely with objects. It's explained here: http://www.info.ucl.ac.be/~pvr/QCon2011PVR.pdf Peter </pre> Peter Van Roy 2012-02-23T19:45:26 http://permalink.gmane.org/gmane.comp.lang.e.general/4765 <pre> Hmm.. As I think you know I'm a fan of data flow programming - in hardware and languages. Data flow programming is natively asynchronous but also timing independent. Still, I'm not clear how it fits with the OO scheme. --Jed </pre> Jed Donnelley 2012-02-23T16:52:10 http://permalink.gmane.org/gmane.comp.lang.e.general/4764 <pre>I had an idea last night. (It would be better to have some code for existing ideas, but I'm short on time and enthusiasm at the moment. Bear with me a few more months...) Let's call this tool willBeDeepFrozen(p :vow) with the following properties: * is DeepFrozen * is a transparent-except-for-== forwarder around p * if called before p is resolved, or if p is resolved and is not DeepFrozen, it will become permanently "ruined" -- all calls will throw. (This last property is the same thing a Proxy does if it gets an invalid resolutionSlot.) This allows us to break cycles of DeepFrozen objects: def bar def barW := willBeDeepFrozen(bar) def foo as DeepFrozen { ... barW ... } bind bar as DeepFrozen { ... foo ... } If the real bar is needed, then it can be obtained, without introducing any new facilities, as barW.__whenMoreResolved(fn x {x}) The problem this addresses is currently handled in E-on-CL by using "EventuallyDeepFrozen", a kludge which would be applied to "foo" in th</pre> Kevin Reid 2012-02-21T13:20:00 http://permalink.gmane.org/gmane.comp.lang.e.general/4763 <pre> Some of the key paragraphs were incomprehensible to me because of errors in English composition: I assume that every use of the word "even" should be read as "event". I assume that "esaly" should be "easily". The second to last sentence, starting, "And it is possible to specify..." completely eludes me. If I knew the LtU jargon better, I might be able to make a stab at parsing that sentence. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |Security, like correctness, is| Periwinkle (408)356-8506 |not an add-on feature. - Attr-| 16345 Englewood Ave www.pwpconsult.com |ibuted to Andrew Tanenbaum | Los Gatos, CA 95032 _______________________________________________ e-lang mailing list e-lang&lt; at &gt;mail.eros-os.org http://www.eros-os.org/mailman/listinfo/e-lang </pre> Bill Frantz 2012-02-20T03:32:42 http://permalink.gmane.org/gmane.comp.lang.e.general/4762 <pre>http://lambda-the-ultimate.org/node/4453 </pre> Mark S. Miller 2012-02-19T23:31:28 http://permalink.gmane.org/gmane.comp.lang.e.general/4761 <pre>I have written a long post on LtU discussing why I think that E-style actors are more powerful than Erlang style actors. http://lambda-the-ultimate.org/node/4453 Thanks, Constantine _______________________________________________ e-lang mailing list e-lang-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/e-lang </pre> Constantine Plotnikov 2012-02-19T14:30:58 http://permalink.gmane.org/gmane.comp.lang.e.general/4759 <pre> In general, people use 0install when the program they're trying to run uses it. If you want figures, it's hard to say. Each distribution has its own package in its repository with its own stats. e.g. for Debian: http://qa.debian.org/popcon.php?package=zeroinstall-injector Though what these figures mean I'm not entirely sure. I think it's estimating that 0.67% of Debian users currently have it installed. sf.net says we have had 137,362 downloads in total, but that includes all the tools too, not just the main 0install program. When you launch a program, 0install runs the "run" command by default. e.g. these run e-core's "run" command: $ 0launch http://repo.roscidus.com/e/e-core ? or $ 0alias rune http://repo.roscidus.com/e/e-core $ rune ? In e-core's XML, it looks like this: &lt;command name="run"&gt; &lt;runner interface="http://repo.roscidus.com/java/openjdk-6-jre"&gt; &lt;arg&gt;-De.home=$EHOME&lt;/arg&gt;&lt;arg&gt;org.erights.e.elang.interp.Rune&lt;/arg&gt; &lt;/runner&gt; &lt;/command&gt; Currently, this gets you a n</pre> Thomas Leonard 2011-12-10T10:50:18 http://permalink.gmane.org/gmane.comp.lang.e.general/4758 <pre> FWIW - I haven't used E to write GUI programs. I've used it for reducing data logger data, so it's read files, process, write output. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | I like the farmers' market | Periwinkle (408)356-8506 | because I can get fruits and | 16345 Englewood Ave www.pwpconsult.com | vegetables without stickers. | Los Gatos, CA 95032 </pre> Bill Frantz 2011-12-10T04:20:46 http://permalink.gmane.org/gmane.comp.lang.e.general/4757 <pre> I can't speak for anyone else, but I have in the past used the Mac SWT releases while trying to get SWT to work. This little use case would probably be better served by a little note about "where to get SWT", but see below. In theory, SWT is to be the standard GUI library for EoJ. *.e-swt scripts (such as those included in the EoJ distribution) should just work out of the box. In practice, considering that SWT is native code where the rest of E isn't, and variously platform/version-dependent, I think it would be OK to say "get SWT &lt;prominent link to specific instructions here&gt; if you want to use these GUI programs". Possibly relevant: I am in favor of simplifying EoJ's build process. Higher-level point: I think we should reconsider to what degree we want to be writing E programs that are tied to Java at all. I need some context. Who uses 0install other than you? What do you mean by 'the rune "run" command'? Rune does not have anything I would consider subcommands. My understanding of 0install is </pre> Kevin Reid 2011-12-10T03:26:31 http://permalink.gmane.org/gmane.comp.lang.e.general/4756 <pre> When I had initially brought up the machine, the wiki wasn't working. I think it was because of the Apache setup, which was referencing wiki.erights.org. However, that name was not pointing to the new IP address. And for whatever reason, even though I had the wiki.erights.org name pointing to the right IP address in the /etc/hosts file, it didn't seem to help. Now that I think of it, I think OpenBSD has a resolution order directive (similar to /etc/nsswitch.conf on Debian systems) and I do *not* have a resolution order directive in the /etc/resolv.conf file. So at the time (I was in a rush) I just changed the Apache config to use the IP address instead. Now the DNS is resolving correctly, I change change the config file back to the way it was. Next time we'll be on a more up-to-date Ubuntu box, and hopefully everything will be easier to configure. I haven't spent much time trying to migrate the wiki to the new box; it has been crazy busy at work recently. BR, James </pre> James Graves 2011-11-09T17:59:17 http://permalink.gmane.org/gmane.comp.lang.e.general/4755 <pre> The wiki appears to be confused about its hostname; for example, the feed http://wiki.erights.org/w/index.php?title=Special:Newpages&amp;feed=atom contains URLs starting with "http://50.77.162.161/". </pre> Kevin Reid 2011-11-09T17:29:54 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.e.general