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-02-15 21:19:32
|
The fix for the issue reported by David Hudak on x10-users Without this the examples in the samples dir do not compile with the latest CUDA release from nvidia ------------------------------------------------------------------------ r23587 | sparksparkspark | 2012-02-14 15:46:21 -0500 (Tue, 14 Feb 2012) | 2 lines Stop building for CUDA sm_30 target ------------------------------------------------------------------------ David P Grove/Watson/IBM@IBMUS wrote on 02/15/2012 02:30:53 PM: > David P Grove/Watson/IBM@IBMUS > 02/15/2012 02:30 PM > > Please respond to > X10 core design <x10...@li...> > > To > > x10...@li... > > cc > > Subject > > [X10-core] other fixes to merge to 2.2.2.1 branch? > > 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 |
From: David P G. <gr...@us...> - 2012-02-15 19:31:29
|
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 |
From: David P G. <gr...@us...> - 2012-02-01 20:59:08
|
Andreas Zwinkau <zw...@ki...> wrote on 02/01/2012 05:04:43 AM: > > What is the purpose of having TRUE and FALSE as fields within the > x10.lang.Boolean struct? This would make sense, if you want to remove > the 'true' and 'false' keywords from the syntax. > I think just as a parallel to Java. java.lang.Boolean.TRUE and FALSE. Less useful that in Java in version 2.0 and later of X10 because Boolean is a struct. --dave |
From: Andreas Z. <zw...@ki...> - 2012-02-01 10:04:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is the purpose of having TRUE and FALSE as fields within the x10.lang.Boolean struct? This would make sense, if you want to remove the 'true' and 'false' keywords from the syntax. Greetings! - -- Andreas Zwinkau Karlsruhe Institute of Technology (KIT) Institut für Programmstrukturen und Datenorganisation (IPD) Lehrstuhl Prof. Snelting Adenauerring 20a 76131 Karlsruhe Phone: +49 721 608 48351 Fax: +49 721 608 48457 Email: zw...@ki... Web: http://pp.info.uni-karlsruhe.de/person.php?id=107 KIT ? University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPKQ47AAoJEKm3M8a3pi2iVEAIAIrMYudyxO3tE3rVi66q5afV g463VA0TXzFvLl1M8v7XO0T7QamkI9XKN/JJxeHLBaLki4TCiNMCDVK0TXBE7jBt lz+vEERykOCiW17B7+6n2Op4KiqESRtkWNZMZOSve+xJS9vbWA7gf4AlNtLlQCsB 9byya/dI8kEhZgx8hxOFv2WIZlBLstisLmw5tkFbyt3MEZHjq2DysIr5FkPNcneE utAdgOchC9ptA/tdQxeie1yfKwwk5yeAhCOC5En02Ht6w+2KbO/ICp0XmY4KtmWY zWA+7nM7RD435+Ct8kz/oknkNgU4I6YC5d/1HP3mZT5NKrM7ARAKPE9AeB0N2kA= =MB// -----END PGP SIGNATURE----- |
From: David P G. <gr...@us...> - 2012-01-23 15:40:11
|
I plan to branch x10 for the 2.2.2 release Tuesday morning; shooting for a release about 10 days later (second half of next week). --dave |
From: chenny x. <xie...@gm...> - 2011-12-27 07:42:41
|
Hi, I want to write some program in x10 that need to use some cpp library the library is generally added in makefile or compiled like " gcc .....-I/path/ -L/path/...." , so how can I add it when write code in x10? PS: I am now linking the cpp file into x10 use : @NativeCPPInclude("*.h") @NativeCPPCompilationUnit("*.cc") by Xie |
From: Igor P. <ig...@ac...> - 2011-12-08 14:34:44
|
[+x10-users, bcc:x10-core] X10 supports reading files as streams of basic types (bytes, chars) or line-by-line. It does not have libraries for any specific file format. See the X10doc documentation for x10.io.Reader for more details: http://x10.sourceforge.net/x10doc/2.2.1/x10/io/Reader.html . For future queries of this sort, x10...@li... is the appropriate list. Igor On Wed, Dec 7, 2011 at 5:41 PM, yun zou <yun...@gm...> wrote: > Hi all, > > I am trying to read a netCDF file, does X10 support the file i/o for netCDF > file. If so, how can I get the interface to process the netcdf file? If not, > what are the files that x10 can handle? > > Thanks, > Yun > > ------------------------------------------------------------------------------ > Cloud Services Checklist: Pricing and Packaging Optimization > This white paper is intended to serve as a reference, checklist and point of > discussion for anyone considering optimizing the pricing and packaging model > of a cloud services business. Read Now! > http://www.accelacomm.com/jaw/sfnl/114/51491232/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |
From: yun z. <yun...@gm...> - 2011-12-07 22:41:17
|
Hi all, I am trying to read a netCDF file, does X10 support the file i/o for netCDF file. If so, how can I get the interface to process the netcdf file? If not, what are the files that x10 can handle? Thanks, Yun |
From: David P G. <gr...@us...> - 2011-12-02 20:23:17
|
A few points related to our next release: X10 2.2.2. (1) We're going to slip the X10 2.2.2 release target to the end of January instead of trying to get it done by mid-December as planned when we laid out the 2011 roadmap. We'll create the release branch in mid-January and aim to release by January 31. (2) As in previous releases, we'll be using JIRA fairly heavily to keep track of what needs to get done and coordinate the work. (a) I've created an X10 2.2.3 release in JIRA. By default, items defered from 2.2.2 should be targeted at 2.2.3 unless you are making an explicit decision to push them out further than the next release. (b) At Vijay's request I've created an umbrella issue (http://jira.codehaus.org/browse/XTENLANG-2971) for language design and front-end issues. I made an initial pass through and linked in all blocker/critical issues in these components and some of the major issues that I think should also be at least looked at for 2.2.2. If I've missed your favorite language or front-end issue, please go ahead and link it in as well (subject to the obvious that we probably won't be able to resolve everything, so only link it in if you think it is important that the issue be resolved for this release). (c) Leads for other components can either create umbrella JIRAs to track issues or update the fix-for targets of issues to indicate what they are planning to resolve for 2.2.2. For the C++ backend and optimizer I am planning the later approach since the number of issues targeted for 2.2.2 for these components is small enough to track without an umbrella item. (d) It would be helpful if people could put in a little time in the next week to look through their 2.2.2 targeted issues, defer any deferrable issues that are not going to be done, and knock off any easy ones that clearly should be fixed. We have 226 issues targeted at 2.2.2 right now. We'll need to get that well under 100 before the end of December to meet a mid-January branch target. (3) According to cattrack, we have about 10 test cases that have regressed on one or the other backend since 2.2.1. Native X10: 9 regressions. http://legato.watson.ibm.com/cattrack/compare?firstRun=8346&secondRun=8714 Managed X10: 4 regressions. http://legato.watson.ibm.com/cattrack/compare?firstRun=8346&secondRun=8714 We also have the new AIX/lapi failures to look at as well. I haven't create JIRA entries for any of these individual test failures yet, but will do so in about two weeks if they haven't been cleared up before then. (4) I plan to enable the internal Toronto test suite for the C++ backend over the weekend. That will increase the failure count (and test time), but will get us a more complete view of where we are relative to the 2.2.0 release. --dave |
From: Bard B. <ba...@us...> - 2011-09-20 14:59:27
|
Do we yet have a network library? If so, where is it? Thanks, Bard |
From: Yonghong Y. <ya...@cs...> - 2011-09-14 14:26:59
|
[Apologies if you got multiple copies of this email. If you'd like to opt out of these announcements, information on how to unsubscribe is available at the bottom of this email.] The Fifth Conference on Partitioned Global Space Programming Models (PGAS 2011) Galveston Island, Texas, USA, October 15-18, 2011 http://pgas11.rice.edu *** Please note important deadlines for early registration and hotel reservations. Registration: Registration is currently open. Please see http://pgas11.rice.edu for details. **Early Registration Deadline and Discount Hotel Rate Cutoff date is September 24, 2011** Keynote Speakers: Pete Beckman (Argonne National Laboratory) Mitsuhisa Sato (University of Tsukuba) Conference Program There are 15 papers accepted for the conference and the detailed program is available online. Tutorials: There will be two tutorials for PGAS11 with detailed information online. Panels: Two panels are scheduled during the conference. Student Travel Grant Application: With grant from the NSF, we will be able to provide student travel grants for PGAS 2011. Please note the deadline of applications is Sep 19th. The application details are at http://pgas11.rice.edu Location Information PGAS2011 will take place at the Tremont House in Galveston, Texas. It is a Wyndham Grand hotel located near the Strand in the historic part of the city. A block of hotel rooms has been reserved at a special rate at the Hotel Galvez and Tremont House. Hotel reservations can be made on-line or by phoning the hotel directly. Information regarding room reservations and rates is available at http://pgas11.rice.edu **Discounted Hotel Reservation deadline: September 24, 2011** Thanks Yonghong Yan |
From: Igor P. <ig...@ac...> - 2011-09-08 17:23:45
|
Shouldn't we just delete it, then? Igor On Thu, Sep 8, 2011 at 6:50 AM, Mikio Takeuchi <mik...@gm...> wrote: > I merged java-interop branch to trunk in r22872. > Please don't update java-interop branch anymore. > > -- Mikio > > 2011/9/8 Mikio Takeuchi <mik...@gm...>: >> The merge from trunk to java-interop branch has been committed just >> before this mail. >> I am going to merge java-interop branch to trunk later today. >> >> -- Mikio >> >> 2011/9/8 David P Grove <gr...@us...>: >>> I created the 2.2.1 branch this morning and enabled release branch >>> regression testing. >>> >>> As usual, if there are bug fixes/changes made to the trunk that need to get >>> merged to the 2.2.1 branch please let me know the svn revision number of the >>> change to merge. >>> >>> We can now go ahead and merge the java-interop branch to trunk anytime that >>> the Managed X10 team feel they are ready to do so. >>> >>> --dave >>> >>> ------------------------------------------------------------------------------ >>> Using storage to extend the benefits of virtualization and iSCSI >>> Virtualization increases hardware utilization and delivers a new level of >>> agility. Learn what those decisions are and how to modernize your storage >>> and backup environments for virtualization. >>> http://www.accelacomm.com/jaw/sfnl/114/51434361/ >>> _______________________________________________ >>> X10-core mailing list >>> X10...@li... >>> https://lists.sourceforge.net/lists/listinfo/x10-core >>> >>> >> > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |
From: Igor P. <ig...@ac...> - 2011-09-08 17:22:23
|
Actually, Def objects don't override .equals(), so the two are equivalent. Unless you are OK with identity comparison, don't use Def objects as map keys. In fact, the compiler may change not just the identity of Defs in the AST, but also other attributes of those Defs, e.g., type, which would make .equals() unreliable as well. Igor On Wed, Sep 7, 2011 at 10:17 PM, David P Grove <gr...@us...> wrote: > Andreas Zwinkau <zw...@ki...> wrote on 09/05/2011 08:21:32 AM: > >> >> We must map FieldDefs and MethodInstances to other objects. However, >> using a hash map directly does not work, because various lowering phases >> (e.g. ClosureVisitor and StaticInitializer) in the X10 compiler produce >> equal, but not identical FieldDef/MethodInstance objects. >> >> Can this be considered a (minor) bug? In this case we could try to fix >> the lowering phases and send you a patch. Otherwise, we have to find >> another (less efficient) way to maintain a mapping, like using the name >> string to compute a hash code. >> > > Hi, > > As I understand it, this is an intentional part of the way polyglot (the > compiler framework used by X10) is designed. You have to do .equals to > compare Instances, not ==. Sorry. > > --dave > > ------------------------------------------------------------------------------ > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > > |
From: Igor P. <igo...@gm...> - 2011-09-08 11:32:05
|
Actually, Def objects don't override .equals(), so the two are equivalent. Unless you are OK with identity comparison, don't use Def objects as map keys. In fact, the compiler may change not just the identity of Defs in the AST, but also other attributes of those Defs, e.g., type, which would make .equals() unreliable as well. Igor On Sep 8, 2011 3:29 AM, "David P Grove" <gr...@us...> wrote: > > > Andreas Zwinkau <zw...@ki...> wrote on 09/05/2011 08:21:32 AM: >> >> We must map FieldDefs and MethodInstances to other objects. However, >> using a hash map directly does not work, because various lowering phases >> (e.g. ClosureVisitor and StaticInitializer) in the X10 compiler produce >> equal, but not identical FieldDef/MethodInstance objects. >> >> Can this be considered a (minor) bug? In this case we could try to fix >> the lowering phases and send you a patch. Otherwise, we have to find >> another (less efficient) way to maintain a mapping, like using the name >> string to compute a hash code. >> > > Hi, > > As I understand it, this is an intentional part of the way polyglot > (the compiler framework used by X10) is designed. You have to do .equals > to compare Instances, not ==. Sorry. > > --dave |
From: Mikio T. <mik...@gm...> - 2011-09-08 10:50:14
|
I merged java-interop branch to trunk in r22872. Please don't update java-interop branch anymore. -- Mikio 2011/9/8 Mikio Takeuchi <mik...@gm...>: > The merge from trunk to java-interop branch has been committed just > before this mail. > I am going to merge java-interop branch to trunk later today. > > -- Mikio > > 2011/9/8 David P Grove <gr...@us...>: >> I created the 2.2.1 branch this morning and enabled release branch >> regression testing. >> >> As usual, if there are bug fixes/changes made to the trunk that need to get >> merged to the 2.2.1 branch please let me know the svn revision number of the >> change to merge. >> >> We can now go ahead and merge the java-interop branch to trunk anytime that >> the Managed X10 team feel they are ready to do so. >> >> --dave >> >> ------------------------------------------------------------------------------ >> Using storage to extend the benefits of virtualization and iSCSI >> Virtualization increases hardware utilization and delivers a new level of >> agility. Learn what those decisions are and how to modernize your storage >> and backup environments for virtualization. >> http://www.accelacomm.com/jaw/sfnl/114/51434361/ >> _______________________________________________ >> X10-core mailing list >> X10...@li... >> https://lists.sourceforge.net/lists/listinfo/x10-core >> >> > |
From: Andreas Z. <zw...@ki...> - 2011-09-08 10:43:43
|
Am 08.09.2011 04:17, schrieb David P Grove: > Andreas Zwinkau <zw...@ki...> wrote on 09/05/2011 08:21:32 AM: > > > > We must map FieldDefs and MethodInstances to other objects. However, > > using a hash map directly does not work, because various lowering phases > > (e.g. ClosureVisitor and StaticInitializer) in the X10 compiler produce > > equal, but not identical FieldDef/MethodInstance objects. > > > > Can this be considered a (minor) bug? In this case we could try to fix > > the lowering phases and send you a patch. Otherwise, we have to find > > another (less efficient) way to maintain a mapping, like using the name > > string to compute a hash code. > > > > Hi, > > As I understand it, this is an intentional part of the way polyglot (the > compiler framework used by X10) is designed. You have to do .equals to > compare Instances, not ==. Sorry. But .equals just comes down to ==: TypeObject_c.equals(Object o) { return o instanceof TypeObject && ts.equals(this, (TypeObject) o); } TypeSystem_c.equals(TypeObject type1, TypeObject type2) { assert_(type1); assert_(type2); if (type1 == type2) return true; if (type1 == null || type2 == null) return false; return type1.equalsImpl(type2); } TypeObject_c.equalsImpl(TypeObject t) { return t == this; } -- Andreas Zwinkau Karlsruhe Institute of Technology (KIT) Institut für Programmstrukturen und Datenorganisation (IPD) Lehrstuhl Prof. Snelting Adenauerring 20a 76131 Karlsruhe Phone: +49 721 608 48351 Fax: +49 721 608 48457 Email: zw...@ki... Web: http://pp.info.uni-karlsruhe.de/person.php?id=107 KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association |
From: Mikio T. <mik...@gm...> - 2011-09-08 03:10:38
|
The merge from trunk to java-interop branch has been committed just before this mail. I am going to merge java-interop branch to trunk later today. -- Mikio 2011/9/8 David P Grove <gr...@us...>: > I created the 2.2.1 branch this morning and enabled release branch > regression testing. > > As usual, if there are bug fixes/changes made to the trunk that need to get > merged to the 2.2.1 branch please let me know the svn revision number of the > change to merge. > > We can now go ahead and merge the java-interop branch to trunk anytime that > the Managed X10 team feel they are ready to do so. > > --dave > > ------------------------------------------------------------------------------ > Using storage to extend the benefits of virtualization and iSCSI > Virtualization increases hardware utilization and delivers a new level of > agility. Learn what those decisions are and how to modernize your storage > and backup environments for virtualization. > http://www.accelacomm.com/jaw/sfnl/114/51434361/ > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > > |
From: David P G. <gr...@us...> - 2011-09-08 02:18:17
|
Andreas Zwinkau <zw...@ki...> wrote on 09/05/2011 08:21:32 AM: > > We must map FieldDefs and MethodInstances to other objects. However, > using a hash map directly does not work, because various lowering phases > (e.g. ClosureVisitor and StaticInitializer) in the X10 compiler produce > equal, but not identical FieldDef/MethodInstance objects. > > Can this be considered a (minor) bug? In this case we could try to fix > the lowering phases and send you a patch. Otherwise, we have to find > another (less efficient) way to maintain a mapping, like using the name > string to compute a hash code. > Hi, As I understand it, this is an intentional part of the way polyglot (the compiler framework used by X10) is designed. You have to do .equals to compare Instances, not ==. Sorry. --dave |
From: David P G. <gr...@us...> - 2011-09-07 15:53:19
|
I created the 2.2.1 branch this morning and enabled release branch regression testing. As usual, if there are bug fixes/changes made to the trunk that need to get merged to the 2.2.1 branch please let me know the svn revision number of the change to merge. We can now go ahead and merge the java-interop branch to trunk anytime that the Managed X10 team feel they are ready to do so. --dave |
From: Andreas Z. <zw...@ki...> - 2011-09-05 12:21:40
|
We must map FieldDefs and MethodInstances to other objects. However, using a hash map directly does not work, because various lowering phases (e.g. ClosureVisitor and StaticInitializer) in the X10 compiler produce equal, but not identical FieldDef/MethodInstance objects. Can this be considered a (minor) bug? In this case we could try to fix the lowering phases and send you a patch. Otherwise, we have to find another (less efficient) way to maintain a mapping, like using the name string to compute a hash code. -- Andreas Zwinkau Karlsruhe Institute of Technology (KIT) Institut für Programmstrukturen und Datenorganisation (IPD) Lehrstuhl Prof. Snelting Adenauerring 20a 76131 Karlsruhe Phone: +49 721 608 48351 Fax: +49 721 608 48457 Email: zw...@ki... Web: http://pp.info.uni-karlsruhe.de/person.php?id=107 KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association |
From: Andreas Z. <zw...@ki...> - 2011-09-05 12:12:24
|
The X10 2.2.0 specification states for static initialization (§8.6) that field initialization happens in parallel. If one static field access another one it blocks, because an access to a field f is transformed to a call read_f(). However, the current C++ backend produces something slightly different. Consider the following class: class Test { static val x = 42; static val y = x + 1; static val z = initZ(); static def initZ() = x + 1; } According to the spec y and z must wait for x to finish initialization. However, only y uses a blocking read_x() call, because the transformation is not applied to the contents of the initZ method. Forcing the wait behaviour means that static methods must be compiled to two variants, one for initializer use and an efficient one for later. Is parallelism in the initializer really desirable? It might speed up the process for some expensive initializations, but slows it down for others due to synchronisation overhead. Since the expensive ones are probably rare and the programmer may insert async manually, i believe the parallelism requirement could be dropped. On the other hand, the specified behavior is an improvement over Java, where the initializer are executed from top to bottom, whereas the X10 runtime system chooses the "right" order itself or deadlocks if there is none. I think it would be even better to let the compiler compute the "right" order and output an error, if it detects a cycle. The specification could be reduced to something like "there must be an order for initialization, otherwise an errors is printed or the program deadlocks". greetings -- Andreas Zwinkau Karlsruhe Institute of Technology (KIT) Institut für Programmstrukturen und Datenorganisation (IPD) Lehrstuhl Prof. Snelting Adenauerring 20a 76131 Karlsruhe Phone: +49 721 608 48351 Fax: +49 721 608 48457 Email: zw...@ki... Web: http://pp.info.uni-karlsruhe.de/person.php?id=107 KIT – University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association |
From: Igor P. <ig...@ac...> - 2011-08-25 17:44:44
|
We are missing any API for appending to files. Igor On Thu, Aug 25, 2011 at 12:53 PM, Bard Bloom <bar...@gm...> wrote: > I'm trying to append to a file from X10. I can't find anything in x10.io > that mentions appending. What am I missing OR what are we missing? > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > > |
From: Bard B. <bar...@gm...> - 2011-08-25 16:54:24
|
I'm trying to append to a file from X10. I can't find anything in x10.iothat mentions appending. What am I missing OR what are we missing? |
From: Yoav Z. <yoa...@gm...> - 2011-08-25 16:38:21
|
Interfaces would also work if you mirror the hierarchy with the interface hierarchy, so ErasedArrayList will extend ErasedCollection. You can retrieve the type parameter is we allow dynamic type parameter matching, e.g., def test(o:Any, o2:Any) { if (o instanceof Array) { handleArray(o as Array); // there can be at most one erased type handleArray2(o as Array, o2 as Array); // ERR, because they might have different T. } } def handleArray[T](o:Array[T]) { } def handleArray2[T](o1:Array[T],o2:Array[T]) { } (This is another reason why it's better to use erased types directly, and not via interfaces.) On Thu, Aug 25, 2011 at 12:05 PM, Igor Peshansky <ig...@ac...> wrote: > You can use the automatic technique to inject interfaces as well. > That's even more useful for interop because the interfaces map > directly to the corresponding raw Java APIs without name mangling. > > You still have a problem that once you erase a generic type, there is > no going back unless you know the exact type argument(s). > Igor > > On Thu, Aug 25, 2011 at 11:40 AM, Yoav Zibin <yoa...@gm...> wrote: > > It is unsound because CURRENTLY > > x as T > > is unsound. > > But there is a plan to add constraints solving at runtime, so "x as T" > will > > be sound, and this will be sound as well. > > Yes, you can use interfaces if you want to do it yourself. > > I'm proposing an automatic technique that will allow you to work with > > generic classes by using casts at runtime (without using generics). > > It is useful for interop (because one could use the non-generic version), > > and it handles most of the cases where you need existentials. > > > > On Thu, Aug 25, 2011 at 11:34 AM, Igor Peshansky <ig...@ac...> wrote: > >> > >> The "get" method will work. The "set" method will lose constraints in > >> the cast (a known unsoundness of generics). > >> > >> FWIW, what you suggested can also be realized by making all generic > >> classes implement the corresponding erased interface and using > >> covariant return types, i.e., > >> > >> interface ErasedCell { > >> def get():Any; > >> // cannot have set, as it's unsound > >> } > >> class Cell[T] implements ErasedCell { > >> def set(t:T):void {...} > >> def get():T {...} > >> } > >> > >> def test(o:Any) { > >> if (o instanceof ErasedCell) { > >> val cell = o as ErasedCell; > >> val x = cell.get(); > >> ... > >> } > >> } > >> > >> Igor > >> > >> On Thu, Aug 25, 2011 at 10:42 AM, Yoav Zibin <yoa...@gm...> > wrote: > >> > I don't see why it won't work in X10. > >> > We won't allow field access for erased types (only method calls). > >> > Give an example of where it fails... > >> > > >> > On Thu, Aug 25, 2011 at 10:36 AM, Igor Peshansky <ig...@ac...> > wrote: > >> >> > >> >> On Thu, Aug 25, 2011 at 10:24 AM, Yoav Zibin <yoa...@gm...> > >> >> wrote: > >> >> > I have several ideas: > >> >> > 1) Good also for java interop as well (because we have problems > with > >> >> > generics there): > >> >> > For every method with generic parameters (in an interface/class), > we > >> >> > create > >> >> > a bridge method that receives/returns Any instead and delegates to > >> >> > the > >> >> > correct method. > >> >> > For example: > >> >> > class Cell[T] { > >> >> > def set(t:T):void {...} > >> >> > def get():T {...} > >> >> > // also automatically defines: > >> >> > def _set(t:Any):void { set(t as T); } > >> >> > def _get():Any = get() as T; > >> >> > } > >> >> > def test(o:Any) { > >> >> > if (o instanceof Cell) { > >> >> > val cell = o as Cell; > >> >> > val x = cell._get(); > >> >> > ... > >> >> > } > >> >> > } > >> >> > We could give a warning if the user uses a generic class in such a > >> >> > way. > >> >> > It is a very limited form of existentials. > >> >> > >> >> This woks for Java generics, which are exposed as erased, but not for > >> >> X10 generics. Each instantiation of Cell in X10 is a separate type. > >> >> > >> >> > 2) Add reflection to the language: > >> >> > Object.getType():Type > >> >> > Type.getClass() .getConstraint() .getTypeParameters() > >> >> > .isSubtype(Type) > >> >> > Class.isSubclass(Class) > >> >> > >> >> This is introspection, not reflection. Yes, we've discussed this > >> >> before. However, this does not help with casts. > >> >> Igor > >> >> > >> >> > On Thu, Aug 25, 2011 at 9:24 AM, Igor Peshansky <ig...@ac...> > >> >> > wrote: > >> >> >> > >> >> >> It would be hard to limit the usage to just the cast -- would > >> >> >> require > >> >> >> a fairly hacky change to the parser. Besides, Bard was also > asking > >> >> >> for instanceof, not just a cast. > >> >> >> > >> >> >> The problem is that Bard's proposed usage would really imply that > >> >> >> the > >> >> >> type parameter is bound by the instanceof, e.g., > >> >> >> > >> >> >> if (a instanceof X^Array[X]) { // bind X here! > >> >> >> val z:Array[X] = a as Array[X]; // X is already bound and > visible > >> >> >> return jsonArray[X](z); // making type argument explicit here > >> >> >> } > >> >> >> > >> >> >> The above is non-trivial to do in general, e.g., when the > expression > >> >> >> is factored out into a variable -- what's the scope of the > binding? > >> >> >> > >> >> >> An alternative is to add a typecase (with pretty much the same > >> >> >> behavior, except we know the binding is only defined for that > >> >> >> particular block, and cannot be moved out. For example, something > >> >> >> like > >> >> >> > >> >> >> typecase (a) { > >> >> >> case X^Array[X]: { > >> >> >> val z:Array[X] = a as Array[X]; > >> >> >> return jsonArray[X](z); > >> >> >> } } > >> >> >> > >> >> >> In both approaches, one would eventually need a way of > constraining > >> >> >> X, > >> >> >> e.g., X^Array[X]{X<:x10.lang.Ordered}. > >> >> >> > >> >> >> Finally, "^" is ambiguous -- we need a different separator. > >> >> >> Igor > >> >> >> > >> >> >> On Thu, Aug 25, 2011 at 8:18 AM, Vijay Saraswat < > vi...@sa...> > >> >> >> wrote: > >> >> >> > I think it should be possible to provide a cast of the form e as > >> >> >> > X^Array[X], > >> >> >> > and give it a static type Array[F123], for F123 a new type > >> >> >> > parameter > >> >> >> > in > >> >> >> > that > >> >> >> > environment. > >> >> >> > > >> >> >> > A half step towards having the real existential type X^Array[X] > in > >> >> >> > the > >> >> >> > language. > >> >> >> > > >> >> >> > Igor? Avi? > >> >> >> > > >> >> >> > On 8/24/2011 12:48 PM, Bard Bloom wrote: > >> >> >> > > >> >> >> > I'm trying to write X10->JSON code. It's a stringifier which, > >> >> >> > ideally, > >> >> >> > would take any suitably structured object, and produce a > portable > >> >> >> > string > >> >> >> > representation of it (see json.org for more details). The JSON > >> >> >> > world > >> >> >> > is > >> >> >> > dynamically typed, and X10 is statically typed, so there's some > >> >> >> > conceptual > >> >> >> > mismatch here. > >> >> >> > > >> >> >> > So, I'd like: > >> >> >> > val m : Map[String, Int] = /* "yes"->1, "fish"->2 */ > >> >> >> > json([1, ["tu"], [[true, m]]]) = "[1, ["tu"], [[true, {"yes":1, > >> >> >> > "fish":2}]]] > >> >> >> > > >> >> >> > > >> >> >> > So, I'm writing a big typecase over the various types which > happen > >> >> >> > to > >> >> >> > make > >> >> >> > sense in JSON: int, string, boolean, list/array, and map. The > >> >> >> > composite > >> >> >> > types can be combined arbitrarily -- JSON doesn't have a type > >> >> >> > system. > >> >> >> > Ideally, the X10 code could take any suitable value and JSONize > >> >> >> > it. > >> >> >> > > >> >> >> > I can't figure out how to do that with the X10 type system. If > >> >> >> > we > >> >> >> > had, > >> >> >> > say, Java-ish wildcards or the ability to talk about "Array" as > a > >> >> >> > type > >> >> >> > rather than requiring "Array[T]", I could do it easily: > >> >> >> > > >> >> >> > public static def json(a:Any) { > >> >> >> > if (a instanceof String) return jsonString(a as String); > >> >> >> > if (a instanceof Int) return a.toString(); > >> >> >> > if (a instanceof Long) return a.toString(); > >> >> >> > if (a instanceof Boolean) return a.toString(); > >> >> >> > if (a == null) return "null"; > >> >> >> > if (a instanceof Array[?]) return jsonArray(a); > >> >> >> > if (a instanceof Map[?,?]) return jsonMap(a); > >> >> >> > } > >> >> >> > > >> >> >> > We don't have those language features -- and I am not > recommending > >> >> >> > that > >> >> >> > we > >> >> >> > add them; I know perfectly well why they're troublesome. > >> >> >> > > >> >> >> > What's the best that we can do along those lines in current X10? > >> >> >> > E.g., > >> >> >> > can > >> >> >> > I have a dynamic test for "It's an array of something" and an > >> >> >> > expression > >> >> >> > "given that it's an array of something, give me the type and the > >> >> >> > value > >> >> >> > as an > >> >> >> > array"? > >> >> >> > > >> >> >> > Thanks! > >> >> >> > -- Bard > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > ------------------------------------------------------------------------------ > >> >> >> > EMC VNX: the world's simplest storage, starting under $10K > >> >> >> > The only unified storage solution that offers unified management > >> >> >> > Up to 160% more powerful than alternatives and 25% more > efficient. > >> >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > X10-core mailing list > >> >> >> > X10...@li... > >> >> >> > https://lists.sourceforge.net/lists/listinfo/x10-core > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > ------------------------------------------------------------------------------ > >> >> >> > EMC VNX: the world's simplest storage, starting under $10K > >> >> >> > The only unified storage solution that offers unified management > >> >> >> > Up to 160% more powerful than alternatives and 25% more > efficient. > >> >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> >> >> > _______________________________________________ > >> >> >> > X10-core mailing list > >> >> >> > X10...@li... > >> >> >> > https://lists.sourceforge.net/lists/listinfo/x10-core > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > ------------------------------------------------------------------------------ > >> >> >> EMC VNX: the world's simplest storage, starting under $10K > >> >> >> The only unified storage solution that offers unified management > >> >> >> Up to 160% more powerful than alternatives and 25% more efficient. > >> >> >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> >> >> _______________________________________________ > >> >> >> X10-core mailing list > >> >> >> X10...@li... > >> >> >> https://lists.sourceforge.net/lists/listinfo/x10-core > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > ------------------------------------------------------------------------------ > >> >> > EMC VNX: the world's simplest storage, starting under $10K > >> >> > The only unified storage solution that offers unified management > >> >> > Up to 160% more powerful than alternatives and 25% more efficient. > >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> >> > _______________________________________________ > >> >> > X10-core mailing list > >> >> > X10...@li... > >> >> > https://lists.sourceforge.net/lists/listinfo/x10-core > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ > >> >> EMC VNX: the world's simplest storage, starting under $10K > >> >> The only unified storage solution that offers unified management > >> >> Up to 160% more powerful than alternatives and 25% more efficient. > >> >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> >> _______________________________________________ > >> >> X10-core mailing list > >> >> X10...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/x10-core > >> > > >> > > >> > > >> > > ------------------------------------------------------------------------------ > >> > EMC VNX: the world's simplest storage, starting under $10K > >> > The only unified storage solution that offers unified management > >> > Up to 160% more powerful than alternatives and 25% more efficient. > >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> > _______________________________________________ > >> > X10-core mailing list > >> > X10...@li... > >> > https://lists.sourceforge.net/lists/listinfo/x10-core > >> > > >> > > >> > >> > >> > ------------------------------------------------------------------------------ > >> EMC VNX: the world's simplest storage, starting under $10K > >> The only unified storage solution that offers unified management > >> Up to 160% more powerful than alternatives and 25% more efficient. > >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > >> _______________________________________________ > >> X10-core mailing list > >> X10...@li... > >> https://lists.sourceforge.net/lists/listinfo/x10-core > > > > > > > ------------------------------------------------------------------------------ > > EMC VNX: the world's simplest storage, starting under $10K > > The only unified storage solution that offers unified management > > Up to 160% more powerful than alternatives and 25% more efficient. > > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > > _______________________________________________ > > X10-core mailing list > > X10...@li... > > https://lists.sourceforge.net/lists/listinfo/x10-core > > > > > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > |
From: Igor P. <ig...@ac...> - 2011-08-25 16:06:05
|
You can use the automatic technique to inject interfaces as well. That's even more useful for interop because the interfaces map directly to the corresponding raw Java APIs without name mangling. You still have a problem that once you erase a generic type, there is no going back unless you know the exact type argument(s). Igor On Thu, Aug 25, 2011 at 11:40 AM, Yoav Zibin <yoa...@gm...> wrote: > It is unsound because CURRENTLY > x as T > is unsound. > But there is a plan to add constraints solving at runtime, so "x as T" will > be sound, and this will be sound as well. > Yes, you can use interfaces if you want to do it yourself. > I'm proposing an automatic technique that will allow you to work with > generic classes by using casts at runtime (without using generics). > It is useful for interop (because one could use the non-generic version), > and it handles most of the cases where you need existentials. > > On Thu, Aug 25, 2011 at 11:34 AM, Igor Peshansky <ig...@ac...> wrote: >> >> The "get" method will work. The "set" method will lose constraints in >> the cast (a known unsoundness of generics). >> >> FWIW, what you suggested can also be realized by making all generic >> classes implement the corresponding erased interface and using >> covariant return types, i.e., >> >> interface ErasedCell { >> def get():Any; >> // cannot have set, as it's unsound >> } >> class Cell[T] implements ErasedCell { >> def set(t:T):void {...} >> def get():T {...} >> } >> >> def test(o:Any) { >> if (o instanceof ErasedCell) { >> val cell = o as ErasedCell; >> val x = cell.get(); >> ... >> } >> } >> >> Igor >> >> On Thu, Aug 25, 2011 at 10:42 AM, Yoav Zibin <yoa...@gm...> wrote: >> > I don't see why it won't work in X10. >> > We won't allow field access for erased types (only method calls). >> > Give an example of where it fails... >> > >> > On Thu, Aug 25, 2011 at 10:36 AM, Igor Peshansky <ig...@ac...> wrote: >> >> >> >> On Thu, Aug 25, 2011 at 10:24 AM, Yoav Zibin <yoa...@gm...> >> >> wrote: >> >> > I have several ideas: >> >> > 1) Good also for java interop as well (because we have problems with >> >> > generics there): >> >> > For every method with generic parameters (in an interface/class), we >> >> > create >> >> > a bridge method that receives/returns Any instead and delegates to >> >> > the >> >> > correct method. >> >> > For example: >> >> > class Cell[T] { >> >> > def set(t:T):void {...} >> >> > def get():T {...} >> >> > // also automatically defines: >> >> > def _set(t:Any):void { set(t as T); } >> >> > def _get():Any = get() as T; >> >> > } >> >> > def test(o:Any) { >> >> > if (o instanceof Cell) { >> >> > val cell = o as Cell; >> >> > val x = cell._get(); >> >> > ... >> >> > } >> >> > } >> >> > We could give a warning if the user uses a generic class in such a >> >> > way. >> >> > It is a very limited form of existentials. >> >> >> >> This woks for Java generics, which are exposed as erased, but not for >> >> X10 generics. Each instantiation of Cell in X10 is a separate type. >> >> >> >> > 2) Add reflection to the language: >> >> > Object.getType():Type >> >> > Type.getClass() .getConstraint() .getTypeParameters() >> >> > .isSubtype(Type) >> >> > Class.isSubclass(Class) >> >> >> >> This is introspection, not reflection. Yes, we've discussed this >> >> before. However, this does not help with casts. >> >> Igor >> >> >> >> > On Thu, Aug 25, 2011 at 9:24 AM, Igor Peshansky <ig...@ac...> >> >> > wrote: >> >> >> >> >> >> It would be hard to limit the usage to just the cast -- would >> >> >> require >> >> >> a fairly hacky change to the parser. Besides, Bard was also asking >> >> >> for instanceof, not just a cast. >> >> >> >> >> >> The problem is that Bard's proposed usage would really imply that >> >> >> the >> >> >> type parameter is bound by the instanceof, e.g., >> >> >> >> >> >> if (a instanceof X^Array[X]) { // bind X here! >> >> >> val z:Array[X] = a as Array[X]; // X is already bound and visible >> >> >> return jsonArray[X](z); // making type argument explicit here >> >> >> } >> >> >> >> >> >> The above is non-trivial to do in general, e.g., when the expression >> >> >> is factored out into a variable -- what's the scope of the binding? >> >> >> >> >> >> An alternative is to add a typecase (with pretty much the same >> >> >> behavior, except we know the binding is only defined for that >> >> >> particular block, and cannot be moved out. For example, something >> >> >> like >> >> >> >> >> >> typecase (a) { >> >> >> case X^Array[X]: { >> >> >> val z:Array[X] = a as Array[X]; >> >> >> return jsonArray[X](z); >> >> >> } } >> >> >> >> >> >> In both approaches, one would eventually need a way of constraining >> >> >> X, >> >> >> e.g., X^Array[X]{X<:x10.lang.Ordered}. >> >> >> >> >> >> Finally, "^" is ambiguous -- we need a different separator. >> >> >> Igor >> >> >> >> >> >> On Thu, Aug 25, 2011 at 8:18 AM, Vijay Saraswat <vi...@sa...> >> >> >> wrote: >> >> >> > I think it should be possible to provide a cast of the form e as >> >> >> > X^Array[X], >> >> >> > and give it a static type Array[F123], for F123 a new type >> >> >> > parameter >> >> >> > in >> >> >> > that >> >> >> > environment. >> >> >> > >> >> >> > A half step towards having the real existential type X^Array[X] in >> >> >> > the >> >> >> > language. >> >> >> > >> >> >> > Igor? Avi? >> >> >> > >> >> >> > On 8/24/2011 12:48 PM, Bard Bloom wrote: >> >> >> > >> >> >> > I'm trying to write X10->JSON code. It's a stringifier which, >> >> >> > ideally, >> >> >> > would take any suitably structured object, and produce a portable >> >> >> > string >> >> >> > representation of it (see json.org for more details). The JSON >> >> >> > world >> >> >> > is >> >> >> > dynamically typed, and X10 is statically typed, so there's some >> >> >> > conceptual >> >> >> > mismatch here. >> >> >> > >> >> >> > So, I'd like: >> >> >> > val m : Map[String, Int] = /* "yes"->1, "fish"->2 */ >> >> >> > json([1, ["tu"], [[true, m]]]) = "[1, ["tu"], [[true, {"yes":1, >> >> >> > "fish":2}]]] >> >> >> > >> >> >> > >> >> >> > So, I'm writing a big typecase over the various types which happen >> >> >> > to >> >> >> > make >> >> >> > sense in JSON: int, string, boolean, list/array, and map. The >> >> >> > composite >> >> >> > types can be combined arbitrarily -- JSON doesn't have a type >> >> >> > system. >> >> >> > Ideally, the X10 code could take any suitable value and JSONize >> >> >> > it. >> >> >> > >> >> >> > I can't figure out how to do that with the X10 type system. If >> >> >> > we >> >> >> > had, >> >> >> > say, Java-ish wildcards or the ability to talk about "Array" as a >> >> >> > type >> >> >> > rather than requiring "Array[T]", I could do it easily: >> >> >> > >> >> >> > public static def json(a:Any) { >> >> >> > if (a instanceof String) return jsonString(a as String); >> >> >> > if (a instanceof Int) return a.toString(); >> >> >> > if (a instanceof Long) return a.toString(); >> >> >> > if (a instanceof Boolean) return a.toString(); >> >> >> > if (a == null) return "null"; >> >> >> > if (a instanceof Array[?]) return jsonArray(a); >> >> >> > if (a instanceof Map[?,?]) return jsonMap(a); >> >> >> > } >> >> >> > >> >> >> > We don't have those language features -- and I am not recommending >> >> >> > that >> >> >> > we >> >> >> > add them; I know perfectly well why they're troublesome. >> >> >> > >> >> >> > What's the best that we can do along those lines in current X10? >> >> >> > E.g., >> >> >> > can >> >> >> > I have a dynamic test for "It's an array of something" and an >> >> >> > expression >> >> >> > "given that it's an array of something, give me the type and the >> >> >> > value >> >> >> > as an >> >> >> > array"? >> >> >> > >> >> >> > Thanks! >> >> >> > -- Bard >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > ------------------------------------------------------------------------------ >> >> >> > EMC VNX: the world's simplest storage, starting under $10K >> >> >> > The only unified storage solution that offers unified management >> >> >> > Up to 160% more powerful than alternatives and 25% more efficient. >> >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> >> >> > >> >> >> > _______________________________________________ >> >> >> > X10-core mailing list >> >> >> > X10...@li... >> >> >> > https://lists.sourceforge.net/lists/listinfo/x10-core >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > ------------------------------------------------------------------------------ >> >> >> > EMC VNX: the world's simplest storage, starting under $10K >> >> >> > The only unified storage solution that offers unified management >> >> >> > Up to 160% more powerful than alternatives and 25% more efficient. >> >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> >> >> > _______________________________________________ >> >> >> > X10-core mailing list >> >> >> > X10...@li... >> >> >> > https://lists.sourceforge.net/lists/listinfo/x10-core >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> EMC VNX: the world's simplest storage, starting under $10K >> >> >> The only unified storage solution that offers unified management >> >> >> Up to 160% more powerful than alternatives and 25% more efficient. >> >> >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> >> >> _______________________________________________ >> >> >> X10-core mailing list >> >> >> X10...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/x10-core >> >> > >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > EMC VNX: the world's simplest storage, starting under $10K >> >> > The only unified storage solution that offers unified management >> >> > Up to 160% more powerful than alternatives and 25% more efficient. >> >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> >> > _______________________________________________ >> >> > X10-core mailing list >> >> > X10...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/x10-core >> >> > >> >> > >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> EMC VNX: the world's simplest storage, starting under $10K >> >> The only unified storage solution that offers unified management >> >> Up to 160% more powerful than alternatives and 25% more efficient. >> >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> >> _______________________________________________ >> >> X10-core mailing list >> >> X10...@li... >> >> https://lists.sourceforge.net/lists/listinfo/x10-core >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > EMC VNX: the world's simplest storage, starting under $10K >> > The only unified storage solution that offers unified management >> > Up to 160% more powerful than alternatives and 25% more efficient. >> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> > _______________________________________________ >> > X10-core mailing list >> > X10...@li... >> > https://lists.sourceforge.net/lists/listinfo/x10-core >> > >> > >> >> >> ------------------------------------------------------------------------------ >> EMC VNX: the world's simplest storage, starting under $10K >> The only unified storage solution that offers unified management >> Up to 160% more powerful than alternatives and 25% more efficient. >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> _______________________________________________ >> X10-core mailing list >> X10...@li... >> https://lists.sourceforge.net/lists/listinfo/x10-core > > > ------------------------------------------------------------------------------ > EMC VNX: the world's simplest storage, starting under $10K > The only unified storage solution that offers unified management > Up to 160% more powerful than alternatives and 25% more efficient. > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev > _______________________________________________ > X10-core mailing list > X10...@li... > https://lists.sourceforge.net/lists/listinfo/x10-core > > |