Hi Nikhil -- I'm glad you're enjoying Chapel so far. Generally speaking, most of our efforts are going toward performance optimizations, improving the memory/OOP stories, and support for emerging node architectures and capabilities. Next release drops in a few weeks.
Internally to Cray, we have a tasklist for the calendar year that sets out priorities and directions for the next 6-9 months, but haven't done a great job of pushing that to the public in any good way. We'll be doing a talk at the upcoming CHIUW (Chapel Implementers and Users Workshop) meeting in which I hope to outline our priorities and plans, and those slides will be available after the meeting. We're also looking at task tracking mechanisms (like pivotal) that we could push into the public sphere, but haven't settled on any specific technology yet. If you have specific feature areas that you think should be prioritized (or are looking for something to work on :), let us know. -Brad On Tue, 1 Apr 2014, Nikhil Padmanabhan wrote: > I just verified that this has same behavior when running past EOF even > on the same locale. The fact that read etc return a boolean is very > useful (and answers a question I had when I first started looking at > this) : I somehow missed this while reading through the fileIO example > (I somehow didn't make it down far enough). > > I should add that I've been enjoying writing some initial codes in > Chapel.... one question --- is there a plan/roadmap for the next > releases? > > Thanks very much! > -- Nikhil > --------------------------------- > Nikhil Padmanabhan > [email protected] > > > On Tue, Apr 1, 2014 at 9:35 AM, Michael Ferguson <[email protected]> wrote: >> Hi Nikhil - >> >> I'm sorry I didn't notice this earlier - but your program >> works in this way because the channel.read functions taking >> in variables return true if they read something and false >> otherwise. That's because there are many cases in which >> you don't know how long your file is, so you want something >> like >> while ffr.read(x) { >> do something with x >> } >> >> The read functions taking in types already return the read >> value, and so they can't return a separate 'bool' indicating >> whether or not the read is successful. These variants halt >> the program if the read was not successful. >> >> While the language specification describes these read methods, >> they don't describe the return types. I'll see if I can fix that. >> In the mean time, the best way to learn about the I/O capabilities >> is by looking over the example primers code in >> examples/primiers/fileIO.chpl in this case. >> >> I believe you will find that this behavior has nothing >> to do with multiple locales (ie, if you replaced the >> outer loop with forj in 1..2 it would work the same). >> >> Cheers, >> >> -michael >> >> >> On 03/28/2014 09:41 PM, Nikhil Padmanabhan wrote: >>> >>> Hello, >>> >>> I'm a newbie to Chapel, so apologies if I missed seeing this issue >>> somewhere... >>> >>> I just came across an edge case that surprised me while reading in a text >>> file; see the attached code and input data. Very quickly, I was trying to >>> get the various locales to read in consecutive chunks of a text file, and >>> found that on locales other than the one I opened the file on, it lets me >>> read past the file without an error. >>> >>> This does not happen if I replace the >>> read(x,y,z); >>> with >>> (x,y,z) = read(real, real, real); >>> >>> I'm compiling the code with >>> chpl -o test_reading test_reading.chpl >>> >>> CHPL_COMM=gasnet >>> CHPL_COMM_SUBSTRATE=mpi >>> >>> This is on an OS X 10.8.5 system, with gcc 4.7. The command I ran, and the >>> output is also attached. >>> >>> An unrelated comment : >>> >>> The writef statement triggers the warnings below while compiling --- I >>> realize this is not yet in the language spec though. >>> >>> Thanks in advance! >>> -- Nikhil >>> >>> In file included from /tmp/chpl-npadmana-30889.deleteme/_main.c:39:0: >>> /tmp/chpl-npadmana-30889.deleteme/IO.c: In function '_format_reader': >>> /tmp/chpl-npadmana-30889.deleteme/IO.c:6797:7: warning: passing argument 3 >>> of 'qio_conv_parse' from incompatible pointer type [enabled by default] >>> In file included from >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/qio/qio-all.h:12:0, >>> from >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/chplio.h:16, >>> from >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/stdchpl.h:33, >>> from >>> /tmp/chpl-npadmana-30889.deleteme/chpl__header.h:31, >>> from /tmp/chpl-npadmana-30889.deleteme/_main.c:1: >>> >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/qio/qio_formatted.h:804:8: >>> note: expected 'size_t *' but argument is of type '_ref_uint64_t' >>> In file included from /tmp/chpl-npadmana-30889.deleteme/_main.c:39:0: >>> /tmp/chpl-npadmana-30889.deleteme/IO.c: In function '_extractMatch': >>> /tmp/chpl-npadmana-30889.deleteme/IO.c:13103:5: warning: passing argument >>> 6 of 'qio_channel_read_string' from incompatible pointer type [enabled by >>> default] >>> In file included from >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/qio/qio-all.h:12:0, >>> from >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/chplio.h:16, >>> from >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/stdchpl.h:33, >>> from >>> /tmp/chpl-npadmana-30889.deleteme/chpl__header.h:31, >>> from /tmp/chpl-npadmana-30889.deleteme/_main.c:1: >>> >>> /Users/npadmana/myWork/chapel/chapel-1.8.0/runtime//include/qio/qio_formatted.h:375:7: >>> note: expected 'ssize_t * restrict' but argument is of type '_ref_int64_t' >>> >>> >>> --------------------------------- >>> Nikhil Padmanabhan >>> [email protected] <mailto:[email protected]> >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-users > ------------------------------------------------------------------------------ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
