You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(83) |
Aug
(46) |
Sep
(87) |
Oct
(77) |
Nov
(83) |
Dec
(53) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(121) |
Feb
(15) |
Mar
(133) |
Apr
(125) |
May
(104) |
Jun
(20) |
Jul
(21) |
Aug
(8) |
Sep
(46) |
Oct
(51) |
Nov
(37) |
Dec
(21) |
2011 |
Jan
(28) |
Feb
(12) |
Mar
(36) |
Apr
(18) |
May
(10) |
Jun
(18) |
Jul
(32) |
Aug
(16) |
Sep
(12) |
Oct
|
Nov
|
Dec
(4) |
2012 |
Jan
(1) |
Feb
(5) |
Mar
(1) |
Apr
(4) |
May
(3) |
Jun
(3) |
Jul
(19) |
Aug
(5) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
(4) |
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David C. <dc...@us...> - 2012-07-18 17:35:05
|
Good to see your progress. I will look at reintroducing throws again today. > > Maybe get rid of x.l.Exception? > > What is this? Probably not what it was, or no-longer what it was meant to be :) In java java.lang.Exception should probably be called 'NotError' i.e. exceptions are either under Error or Exception. If you want to catch everything except Error you can catch Exception. But x10.lang.Throwable fits this role precisely already, leaving x.l.Exception to be just as pointless as x.l.RuntimeException. The x10doc for x10.l.Throwable should probably be changed to be based on the current x10doc for x10.lang.RuntimeException. "The class Throwable and its subclasses are an unchecked form of CheckedThrowable that indicate conditions that a reasonable application might want to catch." I think there is a strong case for actually renaming x.l.Throwable to x.l.Exception since Java programmers might expect Throwable to be the root and Exception to be 'most exceptions'. We then have CheckedThrowable, which looks a lot like the familiar Throwable, and no other mention of Throwable anywhere. The changes to names (Throwable->CheckedThrowable, RuntimeException->Exception) would be pretty much what one would expect if the only difference between X10 and Java is the inversion of the default checkedness of exceptions (which *is* pretty much the only difference at this point). > > Disable exception wrapping in managed backend. > > NativeRep exceptions to java equivalents. > > x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, > > To use NativeRep to java equivalents, we basically not able to change > the type hierarchy. > For example, the super type of x10.lang.NullPointerException, which is > java.lang.NullPointerException in generated Java code, will be > java.lang.RuntimeException. We may be able to skip > j.l.RuntimeException and treat it as a single leaf child of > x10.lang.Exception by modifying RuntimeType and the families, but it > requires manual modification and drastic change of the exception > hierarchy from Java is not realistic. I agree the type hierarchies have to match. We can add new subtrees to any class in java that is not final, and we can omit nodes in the type hierarchy by 'skipping over them' in X10. We cannot however add a new class between A and B if A and B already exist in Java. I don't think we can do any tricks with runtime types because we need the fundamental subtype relationship in java to be compatible with the X10 one if we want to re-use its object model. Otherwise, we cannot upcast NPE to RuntimeException (without some sort of implicit conversion that breaks ==). It follows that we must have x.l.NPE extends j.l.T as you say. We don't have to kill x.l.Exception, we can just move all the important classes to be under x.l.Throwable. Anyone caring about NPE etc are very likely to be catching Throwable, not Exception. If not, they have to do some find/replace. As for the fate of x.l.Exception we have lots of options I think: 1) Kill it, tell people to find/replace Exception to Throwable in their X10 code. 2) Kill it and replace it with a deprecated typedef. Don't use it in XRX or M3R. 3) Leave it as a weird class on the site but deprecate it. Don't use it in XRX or M3R. 4) Leave it as a weird class on the site but tell people that catching it is a bad idea because it doesn't include a lot of exceptions that people will want to catch. 5-6) As 1 and 2, but rename x10.lang.Throwable to x10.lang.Exception and have x10.lang.Throwable be the class that disappears / is typedeffed. I'll try to sketch out the hierarchies here: j.l.Throwable (1) - j.l.Exception (not represented in X10) -- j.l.RuntimeException (2) --- j.l.NullPointerException --- j.l.ClassCastException --- j.l.ArrayBoundsIndexException --- j.l.StringBoundsIndexException -- j.l.Error (3) --- j.l.OutOfMemoryException x.l.CheckedThrowable (1) - x.l.Throwable (2) (perhaps renamed to x.l.Exception) -- x.l.NullPointerException -- x.l.ClassCastException -- x.l.ArrayBoundsIndexException -- x.l.StringBoundsIndexException - x.l.Error (3) -- x.l.OutOfMemoryException (There are additional types in the x10 hierarchy, under x.l.T, but we don't have to worry about those as they are not NativeRepped to java exceptions) (There are additional types in the java hierarchy, but we don't have to worry about them because they are exposed simply via interop and won't appear in code that doesn't use interop) |
From: Mikio T. <mik...@gm...> - 2012-07-18 17:31:50
|
For the change of type hierarchy, please send me the new hierarchy (something like Figure 3.3 in my Managed X10 users guide) so that I can prepare for the change in RTT and codegen side. thanks. -- Mikio On Jul 18, 2012, at 6:13, David Cunningham <dc...@us...> wrote: Time is tight, but we can punt some of this stuff. *These must be done before the release:* Syntax change: @Throws -> throws (few days of work in the type system and parser) Hierarchy change: Add CheckedThrowable. Implement in java by @NativeRep throwable. Put x.l.T under it. Make appropriate changes to c++ native code. Put x.l.Error under x.l.CheckedThrowable. Type system modifications (can throw checked throwable, etc) Maybe get rid of x.l.Exception? Definitely get rid of x.l.RuntimeException (probably a couple of weeks work here) Make XRX transparently propagate Error properly through async/finish Make XRX transparently propagate CheckedThrowable through at (complex implementation, described in previous email) (a few days to a week) *If we do not do the following before the release, we can write them up as limitations (i.e. don't write code that requires the correct behaviour)* Disable exception wrapping in managed backend. NativeRep exceptions to java equivalents. x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, Change assert codegen to throw x10.lang.AssertionError instead of java.lang.AssertionError (probably less than a week) Fix printStackTrace and related functions to rewrite to x10 exception names. (should only take a couple of days) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ X10-core mailing list X10...@li... https://lists.sourceforge.net/lists/listinfo/x10-core |
From: Mikio T. <mik...@gm...> - 2012-07-18 10:30:13
|
I have some questions and comments. 2012/7/18 David Cunningham <dc...@us...>: > Maybe get rid of x.l.Exception? What is this? > Definitely get rid of x.l.RuntimeException Done. > Disable exception wrapping in managed backend. > NativeRep exceptions to java equivalents. > x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, To use NativeRep to java equivalents, we basically not able to change the type hierarchy. For example, the super type of x10.lang.NullPointerException, which is java.lang.NullPointerException in generated Java code, will be java.lang.RuntimeException. We may be able to skip j.l.RuntimeException and treat it as a single leaf child of x10.lang.Exception by modifying RuntimeType and the families, but it requires manual modification and drastic change of the exception hierarchy from Java is not realistic. > Change assert codegen to throw x10.lang.AssertionError instead of > java.lang.AssertionError This is also done. -- Mikio |
From: Mikio T. <mik...@gm...> - 2012-07-18 09:42:27
|
I changed assert codegen to throw x10.lang.AssertionError instead of java.lang.AssertionError in r24108 (trunk) and r24109 (java-interop-exceptions branch). -- Mikio 2012/7/18 Mikio Takeuchi <mik...@gm...>: > I got rid of x.l.RuntimeException in r24107. > I will also take care of the change of Java codegen for assertions. > -- Mikio > > 2012/7/18 David Cunningham <dc...@us...>: >> Time is tight, but we can punt some of this stuff. >> >> >> These must be done before the release: >> >> Syntax change: >> @Throws -> throws >> (few days of work in the type system and parser) >> >> Hierarchy change: >> Add CheckedThrowable. >> Implement in java by @NativeRep throwable. Put x.l.T under it. Make >> appropriate changes to c++ native code. >> Put x.l.Error under x.l.CheckedThrowable. >> Type system modifications (can throw checked throwable, etc) >> Maybe get rid of x.l.Exception? >> Definitely get rid of x.l.RuntimeException >> (probably a couple of weeks work here) >> >> Make XRX transparently propagate Error properly through async/finish >> Make XRX transparently propagate CheckedThrowable through at (complex >> implementation, described in previous email) >> (a few days to a week) >> >> >> If we do not do the following before the release, we can write them up as >> limitations (i.e. don't write code that requires the correct behaviour) >> >> Disable exception wrapping in managed backend. >> NativeRep exceptions to java equivalents. >> x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, >> Change assert codegen to throw x10.lang.AssertionError instead of >> java.lang.AssertionError >> (probably less than a week) >> >> Fix printStackTrace and related functions to rewrite to x10 exception names. >> (should only take a couple of days) >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> X10-core mailing list >> X10...@li... >> https://lists.sourceforge.net/lists/listinfo/x10-core >> |
From: Mikio T. <mik...@gm...> - 2012-07-18 06:46:45
|
I got rid of x.l.RuntimeException in r24107. I will also take care of the change of Java codegen for assertions. -- Mikio 2012/7/18 David Cunningham <dc...@us...>: > Time is tight, but we can punt some of this stuff. > > > These must be done before the release: > > Syntax change: > @Throws -> throws > (few days of work in the type system and parser) > > Hierarchy change: > Add CheckedThrowable. > Implement in java by @NativeRep throwable. Put x.l.T under it. Make > appropriate changes to c++ native code. > Put x.l.Error under x.l.CheckedThrowable. > Type system modifications (can throw checked throwable, etc) > Maybe get rid of x.l.Exception? > Definitely get rid of x.l.RuntimeException > (probably a couple of weeks work here) > > Make XRX transparently propagate Error properly through async/finish > Make XRX transparently propagate CheckedThrowable through at (complex > implementation, described in previous email) > (a few days to a week) > > > If we do not do the following before the release, we can write them up as > limitations (i.e. don't write code that requires the correct behaviour) > > Disable exception wrapping in managed backend. > NativeRep exceptions to java equivalents. > x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, > Change assert codegen to throw x10.lang.AssertionError instead of > java.lang.AssertionError > (probably less than a week) > > Fix printStackTrace and related functions to rewrite to x10 exception names. > (should only take a couple of days) > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |
From: David C. <dc...@us...> - 2012-07-17 21:13:00
|
Time is tight, but we can punt some of this stuff. These must be done before the release: Syntax change: @Throws -> throws (few days of work in the type system and parser) Hierarchy change: Add CheckedThrowable. Implement in java by @NativeRep throwable. Put x.l.T under it. Make appropriate changes to c++ native code. Put x.l.Error under x.l.CheckedThrowable. Type system modifications (can throw checked throwable, etc) Maybe get rid of x.l.Exception? Definitely get rid of x.l.RuntimeException (probably a couple of weeks work here) Make XRX transparently propagate Error properly through async/finish Make XRX transparently propagate CheckedThrowable through at (complex implementation, described in previous email) (a few days to a week) If we do not do the following before the release, we can write them up as limitations (i.e. don't write code that requires the correct behaviour) Disable exception wrapping in managed backend. NativeRep exceptions to java equivalents. x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, Change assert codegen to throw x10.lang.AssertionError instead of java.lang.AssertionError (probably less than a week) Fix printStackTrace and related functions to rewrite to x10 exception names. (should only take a couple of days) |
From: Mikio T. <MT...@jp...> - 2012-07-17 09:22:54
|
Hi Dave, I wonder Avi and newer members of X10 project don't know about it, but I believe that you, Vijay, Dave G, Olivier etc. are all aware of the exception handling mechanism in managed x10 in old days :-) We have overhauled exception handling in late 2010 from the mapping based mechanism (i.e. package x10.lang; @Native("java", "java.lang.NullPointerException") class NullPointerException {} etc.) to the current wrapping based mechanism (i.e. at each try block, catch java.lang.Throwable then wrap known and unknown exceptions with corresponding x10 exception and UnknownJavaThrowable respectively, and rethrow it), and what you are *proposing* is essentially same as the old mechanism. The change was driven by the following strong request from language design side (if I remember correctly, Igor or Bard). "We should print x10 exception as proper x10 type name (e.g. x10.lang.NullPointerException etc.) not as the mapped java exception (e.g. java.lang.NullPointerException) in stack trace," We can implement typeName() to return "x10.lang.NullPointerException" but it was difficult at that time to hook the calls to fillInStackTrace() and set the fake stack trace in a robust and portable way by replacing all known java exception types with corresponding x10 exception types. This is the main reason for which we switched to the wrapping based mechanism, so we need to solve it in order to switch back to the mapping based mechanism. I understand the current double-headed exception hierarchies are painful to use for Java interop programmers and library implementers. Especially the lack of the single top throwable type in X10 requires at least two catch blocks to handle all throwable types. I actually generate such catch blocks (as x10.lang.Throwable and java.lang.Throwable) to implement sticky exception semantics in static initialization. So basically I understand your proposal to introduce a single top throwable type. But I have concern about the time frame. If we change the exception hierarchy, it must be done before we introduce Java interop in X10 2.3. However, the exception handling is delicate and the change of the machinery will have great impact to the stability of the codebase. If the mid August is the hard deadline for X10 2.3, I would say it is risky. I am on vacation on Aug. 11-19. Mikio Takeuchi IBM Research - Tokyo ---------- Forwarded message ---------- From: David Cunningham <dc...@us...> Date: 2012/7/17 Subject: Re: [X10-core] Proposal: Change X10 Exception Hierarchy For Cleaner Java Interop (please respond with comments) To: X10 core design <x10...@li...> Followup: First, a typo fix: Static initialisation will not permit an unchecked exception to escape. It will also not wrap, so x10.interop.java.Error and x10.interop.java.RuntimeException can potentially emerge. becomes Static initialisation will not permit a checked exception to escape. It will also not wrap, so x10.interop.java.Error and x10.interop.java.RuntimeException can potentially emerge. Secondly, after talking with Avi some more, I am changing the proposal slightly: It seems to be a bad idea to override printStackTrace() to hide the wrapping exception in the case of WrappedException. The existing java / X10 chained exception model should be used, or mimicked. Also, I now think we should definitely have x10.lang.Throwable @NativeRep to java.lang.RuntimeException. This means x10.interop.java.RuntimeException will go away, leaving only x10.interop.java.Error which simplifies that side of things significantly. More importantly, manyJava exceptions that we can expect to be thrown from XRX or the VM can be @NativeRep versions of X10 exceptions, thus needing no expensive catch / rethrowing as X10 exceptions, or wrapping or weird semantics around == due to such implementation trickery. * java.lang.ArithmeticException * java.lang.ArrayIndexOutOfBoundsException * java.lang.StringIndexOutOfBoundsException * java.lang.NullPointerException The following we should not see due to careful codegen: * java.lang.ClassCastException (Our own RTT system should be throwing x10.lang.ClassCastException before this can happen) * java.lang.AssertionError (X10 assertions should be front end desugaring, not compiled to java assertions) Unfortunately, the following JVM exceptions are under java.lang.Error, not java.lang.RuntimeException and will still not be caught by catch (e: x10.lang.Throwable) * java.lang.OutOfMemoryError * java.lang.StackOverflowError We could * Use the current wrap/rethrow for these (this won't work in the case of OOM since you probably can't make a new object to wrap them with) * My favourite: Remove them from the language (i.e. remove the X10 classes and not throw them in the native backend) -- these are the managed backend equivalent of a segfault or hardware error etc * Change the hierarchy in X10 so that these are not under x10.lang.Throwable: Rename x10.interop.java.Error to x10.lang.Error and put OOM and SOE under Error, so they can be @NativeRep. This means they can't be caught with catch (e:x10.lang.Throwable) but can be caught explicitly if necessary. All other exceptions should either be kept as interop exceptions (i.e. propagated into X10 without an interference) or caught in native XRJ code so that they cannot trouble an X10 programmer. This should simplify the managed backend codegen for catch a lot. Finally, we should disallow generic exceptions, as Java does, and also disallow constrained exceptions until we write the rules for them. These are other sources of current bugs and compiler complexity. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ X10-core mailing list X10...@li... https://lists.sourceforge.net/lists/listinfo/x10-core |
From: David C. <dc...@us...> - 2012-07-16 21:29:56
|
Followup: First, a typo fix: Static initialisation will not permit an unchecked exception to escape. It will also not wrap, so x10.interop.java.Error and x10.interop.java.RuntimeException can potentially emerge. becomes Static initialisation will not permit a checked exception to escape. It will also not wrap, so x10.interop.java.Error and x10.interop.java.RuntimeException can potentially emerge. Secondly, after talking with Avi some more, I am changing the proposal slightly: It seems to be a bad idea to override printStackTrace() to hide the wrapping exception in the case of WrappedException. The existing java / X10 chained exception model should be used, or mimicked. Also, I now think we should definitely have x10.lang.Throwable @NativeRep to java.lang.RuntimeException. This means x10.interop.java.RuntimeException will go away, leaving only x10.interop.java.Error which simplifies that side of things significantly. More importantly, manyJava exceptions that we can expect to be thrown from XRX or the VM can be @NativeRep versions of X10 exceptions, thus needing no expensive catch / rethrowing as X10 exceptions, or wrapping or weird semantics around == due to such implementation trickery. * java.lang.ArithmeticException * java.lang.ArrayIndexOutOfBoundsException * java.lang.StringIndexOutOfBoundsException * java.lang.NullPointerException The following we should not see due to careful codegen: * java.lang.ClassCastException (Our own RTT system should be throwing x10.lang.ClassCastException before this can happen) * java.lang.AssertionError (X10 assertions should be front end desugaring, not compiled to java assertions) Unfortunately, the following JVM exceptions are under java.lang.Error, not java.lang.RuntimeException and will still not be caught by catch (e: x10.lang.Throwable) * java.lang.OutOfMemoryError * java.lang.StackOverflowError We could * Use the current wrap/rethrow for these (this won't work in the case of OOM since you probably can't make a new object to wrap them with) * My favourite: Remove them from the language (i.e. remove the X10 classes and not throw them in the native backend) -- these are the managed backend equivalent of a segfault or hardware error etc * Change the hierarchy in X10 so that these are not under x10.lang.Throwable: Rename x10.interop.java.Error to x10.lang.Error and put OOM and SOE under Error, so they can be @NativeRep. This means they can't be caught with catch (e:x10.lang.Throwable) but can be caught explicitly if necessary. All other exceptions should either be kept as interop exceptions (i.e. propagated into X10 without an interference) or caught in native XRJ code so that they cannot trouble an X10 programmer. This should simplify the managed backend codegen for catch a lot. Finally, we should disallow generic exceptions, as Java does, and also disallow constrained exceptions until we write the rules for them. These are other sources of current bugs and compiler complexity. |
From: David C. <dc...@us...> - 2012-07-13 21:48:30
|
------- Summary ------- This is based on the email discussion we recently had, a conversation with Vijay over lunch, and various discussions with Avi over the last few weeks. We allow the following in pure X10 code (i.e. without @Native or other hacks), that can be compiled to both managed and native. 1) Catching and rethrowing all unchecked exceptions (including ones from java interop) with multiple catch blocks 2) Catching and rethrowing all exceptions (including ones from java interop) with a single catch block 3) Easy packaging of an exception that is NOT <: x10.lang.Throwable into an exception that is <: x10.lang.Throwable (this is for the boundary between interop x10 code and x10 code that only uses x10.lang.Throwable). 4) A reasonable story for at and finish/async that is implementable before the next release ---------------------- Parser & type checking ---------------------- Background: we have already re-introduced checked exceptions into the language: A checked exception is one that is NOT <: one of * x10.lang.Throwable * x10.interop.java.Error * x10.interop.java.RuntimeException Now we propose making them a core language feature that is visible to native backend programmers as well. This motivates the re-introduction of the 'throws' keyword (retiring @Throws), perhaps in a subsequent release. This is partly because it is a core language feature but also because 'throws' already exists in Java and is well-understood. We will not not allow 'throws' on function types (i.e. closures). Checked exceptions from a closure body must be caught. This could be relaxed if we compile to Java 8. Java unchecked exceptions are permitted in closures. There are some additional java types that are not valid X10 types (like java.lang.Object, which is instead accessible via x10.lang.Any). java.lang.Throwable, now accessed via x10.lang.CheckedThrowable java.lang.Error, now accessed via x10.interop.java.Error; java.lang.RuntimeException, now accessed via x10.interop.java.RuntimeException; java.lang.Exception, now accessed via x10.interop.java.Exception; (necessary because it is the parent of x10.interop.java.RuntimeException) ---------------- Standard library ---------------- Changed classes: package x10.lang; @NativeRep("java", "java.lang.Throwable", ...) class CheckedThrowable { ... } // you can throw any T <: CheckedThrowable Application programmers can extend CheckedThrowable and have a checked exception (even in native X10) but this will have to be locally caught or declared to be thrown using 'throws'. Java checked exceptions such as java.io.IOException can be caught as e:CheckedThrowable (even in native X10). class Throwable extends CheckedThrowable { ... } // Unchecked class WrappedException extends Throwable WrappedException is a simple class written in X10 that can be used to wrap an exception <: x10.lang.CheckedThrowable to force it to be <: x10.lang.Throwable. It will have printStackTrace() overridden to print the internal exception's stack trace. We will encourage people to properly handle (rather than handle and wrap) checked exceptions from interop code. But if they want, they should use this XRX exception to do it rather than roll their own. Especially if they are writing a library. package x10.interop.java; @NativeRep("java", "java.lang.Error", ...) class Error extends x10.lang.CheckedThrowable; In C++ this will be 'just another class' that you can use. @NativeRep("java", "java.lang.Exception", ...) class Exception extends x10.lang.CheckedThrowable; In C++ this will be 'just another class' that you can use. @NativeRep("java", "java.lang.RuntimeException", ...) class RuntimeException extends Exception In C++ this will be 'just another class' that you can use. These allow catching of unchecked exceptions from java without upcasting them to a checked exception. They can then be rethrown without a 'throws' annotation. x10.interop.java.Error and x10.interop.java.RuntimeException are not subtypes of x10.lang.Throwable, which is inconvenient but unavoidable given Java's design. WrappedException can however be used to wrap them, which is useful if you are being called from some legacy X10 code that only handles x10.lang.Throwable, or you just want all your exceptions under a single unchecked root. XRX libraries only throw exceptions <: x10.lang.Throwable but will handle any exception. We advertise this as best practice if the programmer is not biased between native and managed backends. ------- Runtime ------- MultipleExceptions will contain a WrappedException if an uncaught exception e is thrown by the body of an async and e is NOT <: x10.lang.Throwable. This means that Error and RuntimeException will be wrapped even though they are not checked exceptions. To me, this seems the least worst option. 'At' statements will implicitly propagate checked exceptions, i.e. at { throw new CheckedThrowable(); } may only be written if the exception is caught by the home place, or the method 'throws' CheckedThrowable. PlaceLocalHandle.make uses finish async at, and will therefore emit MultipleExceptions containing wrapped exceptions. Static initialisation will not permit an unchecked exception to escape. It will also not wrap, so x10.interop.java.Error and x10.interop.java.RuntimeException can potentially emerge. ------------------- Implementation note ------------------- Runtime.runAt will not have the 'throws' annotation, it will use Thread.stop() to throw a checked exception without needing a 'throws' annotation in the Java code. When desugaring an 'at' into a Runtime.runAt call, the java backend will have to, for each T in the expression's throws() clause, insert one call to the static method x10.runtime.Util.fakeThrows[T](), which is a method that has an empty body but has a 'throws' annotation (the call will be inlined by the JIT). This is 'the other side' of the Thread.stop() approach, where we have to tell the javac type checker that we are indeed throwing a checked exception, or it will reject any catch statements of these checked exceptions on the grounds that they are unreachable. For illustration, see the following java code: import java.io.*; public class Test { public static <E extends Throwable> void fakeThrows() throws E { } public static <E extends Throwable, T> T fakeThrows(T x) throws E { return x; } public static void main (String[] args) { try { Thread.currentThread().stop(new IOException()); Test.<IOException>fakeThrows(); String tmp = Test.<IOException,String>fakeThrows(new String()); } catch (IOException e) { System.out.println("fish"); } } } ------------ Further work ------------ @Suppress[java.io.IOException] { S } will insert a try/catch block around the statement S and rethrow the exception packaged in a WrappedException. It can be used instead of a 'throws' annotation on a method, but it applies to the method body, and therefore is not part of the signature of the method. This should also work on closures, which is useful since 'throws' cannot be used on function types. @SuppressAll { S } will insert a try/catch block around S and rethrow everything in a WrappedException if it not under x10.lang.Throwable. The implementation technique for at desugaring on the managed backend could be used for implementing function types with throws annotations. This would cost in the body of a closure, but only if it had to suppress an exception. It would not increase the cost of a call (after JIT). ---------- Discussion ---------- If you are writing a library that has to handle exceptions from user code, and you do not allow user code to throw any checked exceptions (i.e. the interface you provide for users to extend does not have any 'throws' annotation) you will need to catch all the possible unchecked exceptions. You do this with 3 catch statements, one for x10.lang.Throwable, one for x10.interop.java.Error, and one for x10.interop.java.RuntimeException. You can then either rethrow them, or package them, and rethrow that, at your discretion. If you target just native, you can still do it by catching x10.lang.Throwable, but your code will be fragile if you later decide to compile it to the managed backend. You can also catch CheckedThrowable. This has the advantage that you can allow usercode to throw any exception (i.e. the interface you provide for users to extend has 'throws CheckedThrowable'), but is more tiresome to deal with. You can: 1) Package it & rethrow -- this might confuse / irritate your user, but is very easy. 2) Return it through some other channel. 3) throw it using 'throws CheckedThrowable'. This means your users will have to catch it when they invoke your library, even if the code they supplied did not throw any checked exceptions. 4) The same as (3) but define two versions of your API, one that takes user code that does not throw checked exceptions, and one that does. So you can either deal with CheckedException or you can have 3 catch blocks -- one for x10.lang.Throwable, one for x10.interop.java.Error, and one for x10.interop.java.RuntimeException. |
From: David P G. <gr...@us...> - 2012-07-11 21:42:27
|
David Cunningham/Watson/IBM@IBMUS wrote on 07/11/2012 05:09:09 PM: > From: David Cunningham/Watson/IBM@IBMUS > To: X10 core design <x10...@li...>, > Date: 07/11/2012 05:11 PM > Subject: Re: [X10-core] Now we have nterop, what subset of the > language do we define as 'portable'? > > > This gets @NativeRep to x10.lang.Throwable for the C++ backend. > > Aren't there some issues with two x10 classes having the same > runtime type? I think it is not a soundness violation but it's also > not the current semantics. > Fair enough. I was trying to be lazy and it was probably not a good idea. Having it be @NativeRep for C++ to a distinct class that is also the parent class at the C++ level of the @NativeRep impl of x10::lang::Throwable is probably less confusing... --dave |
From: David C. <dc...@us...> - 2012-07-11 21:09:41
|
> This gets @NativeRep to x10.lang.Throwable for the C++ backend. Aren't there some issues with two x10 classes having the same runtime type? I think it is not a soundness violation but it's also not the current semantics. You could establish a new X10 type CheckedThrowable that is above java.lang.Throwable and x10.lang.Throwable, and encourage everyone to use x10.lang.Throwable (and only use that in our APIs). In other words, we have checked and unchecked exceptions in portable X10, but the default is unchecked rather than checked. Either way, I think this has many similarities with my #2 proposal because it requires @Throws anywhere the top might be thrown, i.e. it reintroduces checked exceptions into "portable X10". Where it beats my #2 is that you don't have to write 2 catch clauses, which I like. It also introduces the ability to throw a checked exception from X10 itself (including X10 that compiles to native code) as you create your own hierarchy under CheckedThrowable. This would be a backwards-compatible regression to the old X10 exception model. Phrased like that, it seems like a reasonable solution to the problem of cleanly adding java interop to X10. If mixed-mode X10 is definitely going to happen, we should plan out what we will need for that, because it may well be related and invalidate my last argument. > This at least allows a single root exception object for pieces of > the XRX runtime that want to catch everything in a "portable" fashion. I'm starting to really believe this is not just an XRX problem but something that will occur with any X10 library of significant complexity (e.g. M3R). If you are writing a library that you want to compile for the managed backend and the native backend (this covers a large proportion of our users), then you quite probably have to deal with java exceptions from user callbacks using @Native hacks. That is our current story and it's not good. |
From: David P G. <gr...@us...> - 2012-07-11 20:42:32
|
It doesn't really address the broad question you are asking, but something Olivier reminded me of after the main discussion yesterday is that we have discussed adding an x10.lang.RootNativeException to the standard library. This gets @NativeRep to java.lang.Throwable for Managed X10 and to x10.lang.Throwable for the C++ backend. This at least allows a single root exception object for pieces of the XRX runtime that want to catch everything in a "portable" fashion. --dave |
From: David C. <dc...@us...> - 2012-07-11 19:56:47
|
This is a writeup of some of my thoughts relating to (parts of) yesterdays discussion. Right now it is possible to write code that only makes sense in the managed backend (e.g. M3R Hadoop compatability layer), the question is what exactly is allowed when you want to target both backends (writing portable X10). (As an aside, it would be good to have a compiler switch that would throw a front end error if the code is not portable. Currently such code compiles fine in the managed backend and causes post compiler errors in the native backend.) This is coming up right now in the context of exception handling. If we are fixed on a design where there are 2 roots to the exception hierarchy (it seems this is necessary because otherwise the managed runtime would have to have x10.lang.Throwble be @NativeRep("java.lang.Throwable") and thus a checked exception) then we have the following options: The simplest (and current) definition no types that come from pre-existing class files (or java standard library) are allowed in portable X10. This makes it hard to write frameworks that can execute user code, such as this one: class FrameWork { static interface Job { def run () : void; } def runJob (j:Job) : Throwable { // asynchronously run j somehow, catching any errors if (j.ranOK()) return null; return j.exception(); } } Examples of this pattern are: * XRX implementations of at, async, next, perhaps some others * PlaceLocalHandle.make * M3R core engine (must catch all exceptions to avoid barrier deadlock) * Some sort of resillient 're-execute this code' framework? * potentially some high level user code? Effect 1 Anyone using this library in an interop context must catch java.lang.Error and java.lang.Runtime exception and package them in their own ExceptionWrapper class that extends x10.lang.Throwable. Otherwise the exceptions will 'escape' . You don't even get an error when this happens, you usually get a deadlock or some other bizarre behaviour. It could be argued that since managed X10 allows interop, that all frameworks that have this property are error-prone unless compiled natively. Effect 2 You have to catch and package all your checked exceptions too, because Job.run does not have a @Throws annotation. If you do this, you are also accounting for effect 1, because you have to catch java.lang.Throwable which includes the unchecked exceptions from effect 1. Alternative -- allow java types in catch clauses The type-theoretical point here is that in native X10, instances of such types will not arise so the whole block can be ignored at codegen time. It would be possible for a predetermined (and documented) list of types to be available, i.e. probably java.lang.Throwable, java.lang.Error, java.lang.RuntimeException and maybe some others. This means that we can simply provide these types in the XRC runtime and existing codegen works fine. That makes implementing this a 5 minute job. This permits using @Throws and catching and rethrowing java.lang.Throwable, which allows the above code to be rewritten: class FrameWork { static interface Job { def run () : void @Throws[java.lang.Throwable] ; } def runJob (j:Job) : Any { // Any is the only type that is above both java.lang.Throwable and x10.lang.Throwable // asynchronously run j somehow, catching all kinds of possible errors if (j.ranOK()) return null; return j.exception(); } } Effect User doesn't have to worry about effect1 and effect2 from the previous section. Note This is actually possible right now using @Native blocks to stop code reaching the native backend, but such code is ugly. We could use it inside XRX classes but it should not be the story for our users. So we don't have to do this if we believe that examples of the above framework will not occur in user code and we don't mind writing ugly difficult code ourselves instead of going for a language solution. Even more power but harder to implement We can actually allow all sorts of references to java types in portable code, as long as these uses are only for threading. I.e. we do not extend, implement, access static methods / fields, or create new instances of such types. We can, however, take parameters of such types, define variables and assign such values, and rethrow them. In fact I think for mixed mode some degree of this will actually be *necessary* because both managed and native 'sides' of the computation will be run through the same frontend and will reach both backends. This requires the codegen on the native side to cleverly ignore such types. E.g instanceof MyJavaClass is always false. Casting always fails, etc. The only value of such a type in the native backend is null, which could be used for optmisations. But 99% of the time this will just be code that is part of a larger portable program but is never even executed on the native backend, but has to be present because it is needed on the managed backend. |
From: Mikio T. <mik...@gm...> - 2012-06-18 14:56:25
|
Hi, To catch java.io.IOException, catch(x10.lang.Exception) is not enough. Java backend actually generates catch (java.lang.Throwable). If java.io.IOException occur, it is wrapped with UnknownJavaThrowable and rethrown. Since UnknownJavaThrowable is subtype of java.lang.RuntimeException, it actually compiles but you cannot catch java.io.IOException. The problem you mentioned here is same as XTENLANG-2989 and XTENLANG-3062. Many people have been complaining about it, but it has not been solved yet. As a workaround, what about writing a simple utility function which takes a closure, then evaluates the closure and returns its return value within a try to ignore all Java exceptions? e.g., return withThingTable( (tt:HTableInterface) => ExceptionUtil.invokeIgnoringException(tt.get(get)) ) -- Mikio 2012/6/9 Bard Bloom <ba...@us...>: > Here's a little X10 puzzle. > > I've got a *Java* method I need to call from X10: > table.get(get); > This method can throw java.io.IOException, so I have to wrap calls to it in > a > try/catch block. If I don't, I get Java compilation errors: > > x10c: ---------- > 1. ERROR in clsss/xjj/HTabler.java (at line 474) > thingTable.get(((org.apache.hadoop.hbase.client.Get)(this. > get))); > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Unhandled exception type IOException > ---------- > 1 problem (1 error) > x10c: Non-zero return code: 255 > > So I have to put a try/catch around it: > try { > return thingTable.get(get); > } > catch(e:x10.lang.Exception) { > e.printStackTrace(); > throw new RuntimeException("Oh no from > HTabler.retrieveThingRecord! " + e); > } > > And that compiles fine. (I'm a bit confused about why, since I didn't think > java.io.IOException was consistent with x10.lang.Exception.) > > But what I really want to do is write a method that behaves like various > things named 'with' in LISP and Python and such. > public static def withThingTable[T]( body : (HTableInterface) => T ) {T > haszero} : T > So that withThingTable(useThingTable) will call the function useThingTable > on > a properly-opened Thing Table, and, after it's done (even exceptionally) > will > properly close it. > > withThingTable is pretty careful with catching exceptions, so it should run > OK. It's a convenience method, encapsulating a required programming > pattern. > > The point of a convenience method is that it be convenient. I *want* to > write: > return withThingTable( (tt:HTableInterface) => tt.get(get) ) > > But X10 and Java don't know that I'm being careful with exceptions. So I > have > to write the try/catch block inside the closure: > > return withThingTable[Result]((thingTable:HTableInterface) => { > try { > return thingTable.get(get); > } > catch(e:x10.lang.Exception) { > e.printStackTrace(); > throw new RuntimeException("Oh no from > HTabler.retrieveThingRecord! " + e); > } > }); > > And this makes my convenience method not so convenient. > > Any suggestions about how I could avoid having to write the try/catch block > in > the closure? Preferably without having to write my own 'get' (and all N > other > HBase methods)? > > Thanks, > > Bard > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |
From: Vijay S. <vi...@sa...> - 2012-06-16 12:14:28
|
Can someone remind me of the password to approve. And also take care of this waiting request. -------- Original Message -------- Subject: 1 X10-core moderator request(s) waiting Date: Sat, 16 Jun 2012 08:53:42 +0000 From: x10...@li... To: x10...@li... The X10...@li... mailing list has 1 request(s) waiting for your consideration at: https://lists.sourceforge.net/lists/admindb/x10-core Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: ba...@us... on Fri Jun 8 21:08:01 2012 Subject: Java Interop Puzzle Cause: Post by non-member to a members-only list |
From: Bard B. <ba...@us...> - 2012-06-08 21:08:00
|
Here's a little X10 puzzle. I've got a *Java* method I need to call from X10: table.get(get); This method can throw java.io.IOException, so I have to wrap calls to it in a try/catch block. If I don't, I get Java compilation errors: x10c: ---------- 1. ERROR in clsss/xjj/HTabler.java (at line 474) thingTable.get(((org.apache.hadoop.hbase.client.Get)(this. get))); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Unhandled exception type IOException ---------- 1 problem (1 error) x10c: Non-zero return code: 255 So I have to put a try/catch around it: try { return thingTable.get(get); } catch(e:x10.lang.Exception) { e.printStackTrace(); throw new RuntimeException("Oh no from HTabler.retrieveThingRecord! " + e); } And that compiles fine. (I'm a bit confused about why, since I didn't think java.io.IOException was consistent with x10.lang.Exception.) But what I really want to do is write a method that behaves like various things named 'with' in LISP and Python and such. public static def withThingTable[T]( body : (HTableInterface) => T ) {T haszero} : T So that withThingTable(useThingTable) will call the function useThingTable on a properly-opened Thing Table, and, after it's done (even exceptionally) will properly close it. withThingTable is pretty careful with catching exceptions, so it should run OK. It's a convenience method, encapsulating a required programming pattern. The point of a convenience method is that it be convenient. I *want* to write: return withThingTable( (tt:HTableInterface) => tt.get(get) ) But X10 and Java don't know that I'm being careful with exceptions. So I have to write the try/catch block inside the closure: return withThingTable[Result]((thingTable:HTableInterface) => { try { return thingTable.get(get); } catch(e:x10.lang.Exception) { e.printStackTrace(); throw new RuntimeException("Oh no from HTabler.retrieveThingRecord! " + e); } }); And this makes my convenience method not so convenient. Any suggestions about how I could avoid having to write the try/catch block in the closure? Preferably without having to write my own 'get' (and all N other HBase methods)? Thanks, Bard |
From: David P G. <gr...@us...> - 2012-05-09 18:00:38
|
Bard Bloom/Watson/IBM@IBMUS wrote on 05/09/2012 01:31:12 PM: > > I've been trying to hook up scripting languages to X10 --- both > Jython and JRuby. In both cases, the Hello World program runs fine > in Java, but not in X10. I get > java.lang.UnsatisfiedLinkError: dlopen(libmsvcrt.dylib, 1) > > This seems to kill Jython. For JRuby, I g a bunch of other errors, > for libsocket.dylib and liblibc.so, but after a few pages of error > messages the minimal JRuby program runs fine. > > Any hints? I presume I need to tell x10 to include something on > some path somewhere, but what? > One random guess would be that there is some confusion between 32 and 64 bit versions of the libraries. -Djava.library.path=<path> is how to tell the JVM where to look for native code. The x10 script is already doing something with this; perhaps that is conflicting or otherwise causing problems. Take all this with a few grains of salt....my grasp of how dynamic linking works on MacOS is sometimes faulty... --dave |
From: Bard B. <ba...@us...> - 2012-05-09 17:32:27
|
I've been trying to hook up scripting languages to X10 --- both Jython and JRuby. In both cases, the Hello World program runs fine in Java, but not in X10. I get java.lang.UnsatisfiedLinkError: dlopen(libmsvcrt.dylib, 1) This seems to kill Jython. For JRuby, I g a bunch of other errors, for libsocket.dylib and liblibc.so, but after a few pages of error messages the minimal JRuby program runs fine. Any hints? I presume I need to tell x10 to include something on some path somewhere, but what? Thanks, Bard |
From: David C. <dc...@us...> - 2012-05-03 19:49:43
|
I just committed a change to svn that adds the following feature to X10Launcher (and native X10 executables) For example: $ X10_SCRATCH_CWD=1 X10_NPLACES=4 `which X10Launcher` pwd /tmp/x10_scratch_1fd54a14 /tmp/x10_scratch_4336f695 /tmp/x10_scratch_5f8b7d57 /tmp/x10_scratch_342957d8 This causes each place to be executed with the current working directory set to a unique, empty temporary directory in /tmp (or wherever your system usually puts temporary files) with 700 permissions. The current working directory when invoking X10launcher does not influence the execution when in this mode. All I/O outside of this scratch space must be performed using absolute paths, e.g. in cmdline options for input/output files. The directory names are chosen using random 8 letter hex strings, (seeded using getpid()), and if mkdir fails due to a file already existing with this name, then the operation is retried up to 1000 times. Other failures (e.g. disk space, permissions, etc) cause execution to abort. Note that it is not possible to implement X10_SCRATCH_CWD within the X10 application because JVMs do not allow one to change the current working directory. It is also very difficult to do it before running X10launcher because you may not know on which machines the execution will run, as well as it being much harder to avoid race conditions between filesystem operations. The directories are *NOT* cleaned up on exit. If you use this mode, you should clean up your current working directory in your X10 code, on program exit (or not, if you wish to inspect its contents after the run completes). It is difficult to make X10launcher clean up the directories itself when there is no management process watching the X10 process (e.g. with a single place localhost execution). |
From: Vijay S. <vi...@sa...> - 2012-04-24 09:14:18
|
On 3/23/2012 8:45 AM, Matthias Braun wrote: > Hi, > > I'm having trouble with X10ParseClassType. When I have a generic class > with type parameters filled in like Array[Int] and I call fields() or > methods() then I get a FieldInstance/MethodInstance with container() > being Array[Int] as expected. > But when calling properties() I get FieldInstances with container() > being Array[T]. When looking at fields() or methods() they do perform > subst().reinstantiate(...) for the stuff they return, properties() does > not appear to do so. Is this intentional or a bug? > > Greetings, > Matthias Braun > > This looks like a bug to me. Can you file a jira please. Specific X10 source code that triggers this would be most valuable. |
From: Vijay S. <vi...@sa...> - 2012-04-24 08:03:16
|
Yes you are correct this part of the system has not been worked on in a while. (Doesn't mean that it would be difficult to get this to work again. Would be a good project for someone wanting to work with the compiler.) What are you trying to do? May be there is some other way of doing it. Best, Vijay On 4/23/2012 7:32 AM, Manuel Mohr wrote: > Hi, > > > I am trying to serialize and later deserialize a type-annotated X10 AST. > I stumbled upon "README-externalize-ASTs.txt" in the X10.compiler > directory, which talks about my exact problem. However, the > "-EXTERNALIZE_ASTS=true" option does not work anymore. After some > digging in subversion logs and the X10 bug tracker, I came to the > conclusion that this feature is no longer supported. The X10 AST > externalizer plugin still exists in the stuff/ subdirectory of > x10.compiler, however, its code seems to be unmaintained and out of sync > with the rest of the code. > > > Is there an easy way to make the externalizer plugin work again? If > not, is there currently any other way of achieving the same effect, > i.e., serializing an AST? > > > Thanks, > Manuel > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |
From: David P G. <gr...@us...> - 2012-04-24 01:22:35
|
Manuel Mohr <man...@ki...> wrote on 04/23/2012 07:32:42 AM: > > I am trying to serialize and later deserialize a type-annotated X10 AST. > I stumbled upon "README-externalize-ASTs.txt" in the X10.compiler > directory, which talks about my exact problem. However, the > "-EXTERNALIZE_ASTS=true" option does not work anymore. After some > digging in subversion logs and the X10 bug tracker, I came to the > conclusion that this feature is no longer supported. The X10 AST > externalizer plugin still exists in the stuff/ subdirectory of > x10.compiler, however, its code seems to be unmaintained and out of sync > with the rest of the code. > > > Is there an easy way to make the externalizer plugin work again? If > not, is there currently any other way of achieving the same effect, > i.e., serializing an AST? > > Hi, You are correct; this functionality has fallen into disrepair and no longer works. I don't think there is an easy way to make it work again, but this is a part of the compiler I'm only roughly familiar with. --dave |
From: Manuel M. <man...@ki...> - 2012-04-23 21:13:48
|
Hi, I am trying to serialize and later deserialize a type-annotated X10 AST. I stumbled upon "README-externalize-ASTs.txt" in the X10.compiler directory, which talks about my exact problem. However, the "-EXTERNALIZE_ASTS=true" option does not work anymore. After some digging in subversion logs and the X10 bug tracker, I came to the conclusion that this feature is no longer supported. The X10 AST externalizer plugin still exists in the stuff/ subdirectory of x10.compiler, however, its code seems to be unmaintained and out of sync with the rest of the code. Is there an easy way to make the externalizer plugin work again? If not, is there currently any other way of achieving the same effect, i.e., serializing an AST? Thanks, Manuel |
From: Matthias B. <mat...@ki...> - 2012-03-23 12:45:16
|
Hi, I'm having trouble with X10ParseClassType. When I have a generic class with type parameters filled in like Array[Int] and I call fields() or methods() then I get a FieldInstance/MethodInstance with container() being Array[Int] as expected. But when calling properties() I get FieldInstances with container() being Array[T]. When looking at fields() or methods() they do perform subst().reinstantiate(...) for the stuff they return, properties() does not appear to do so. Is this intentional or a bug? Greetings, Matthias Braun |
From: Mikio T. <mik...@gm...> - 2012-02-16 04:18:56
|
Dave, XTENLANG-2999 is a problem of custom serialization of Hadoop Writable objects. The fixes (r23571 and r23572) are contained very much and you can safely merge them into 2.2.2.1. XTENLANG-2998 is a problem of interface that extends interface. It was also reported by Avi, but I am not sure it is related with M3R. The fix (in r23579) may look like a bit large but the change is Java type corresponding to T for parameters of dispatch method. In X10, single dispatch method handles multiple actual methods with different Ts, therefore we should use Object (or the upperbound of all Ts) instead of a particular T. I believe the change of unbound T with Object does not have impact since this is what javac does. -- Mikio 2012/2/16 David P Grove <gr...@us...>: > The memory corruption problem for Native X10 I just fixed is severe enough > that I want to do a 2.2.2.1 release next week to get it out to users. We > already had a branch in place for a 2.2.2.1, since we have had a couple PAMI > and debug map fixes that we wanted to be able to release. > > Are there other critical fixes to 2.2.2 that should be considered for > 2.2.2.1? > > For example, I know we had a Java codegen problem that shows up in M3R when > building with 2.2.2 that was fixed in trunk. Is that a contained enough fix > to consider merging to 2.2.2.1? > > --dave > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |