I'd describe the rationale behind readln() as doing its best to be the dual of writeln(). writeln() writes out all of its arguments and then prints a newline. readln() reads all of its arguments and then reads thru the newline.
In general, reading strings with read() is challenging if those strings contain spaces (with or without the -ln). This feels to me like something to make clear in documentation though, not by making it an error. -Brad ________________________________________ From: Michael Ferguson [[email protected]] Sent: Monday, September 14, 2015 6:57 AM To: Ian Bertolacci; [email protected] Subject: Re: Bug: cannot use iostyle in read/readln Hi Ian - Thanks for pointing out this bug and its solution. Of course, for this kind of thing, you are welcome to just create a pull request yourself... I've created a bug fix patch here: https://github.com/chapel-lang/chapel/pull/2505 That bug fix patch includes a version of your test case that I have adjusted to work correctly. See https://github.com/mppf/chapel/blob/fix-read-style/test/io/ferguson/read-s tyle.chpl This readln behavior is a common stumbling block. It is something that Chapel has had for quite some time. The design is that readln(a, b, c) reads a, b, c (whatever they are) and then reads anything at all up to a newline. I believe that the motivation for this design is that it enables easy skipping of input fields you don't want. Do you think that we should make readln(s) an error when s is a string? In particular, readln(a,b,c) or readln(myInt) would still work as it does now, but readln(myString) would cause a compilation error and suggest using readline(myString) instead. In any case, the functionality you probably want is already implemented in readline. We have implemented a two variants of readline - one for a string argument and one for a []:uint(8) argument. I recommend using these. See: http://chapel.cray.com/docs/latest/modules/standard/IO.html#IO.channel.rea dline Thanks, -michael On 9/13/15, 7:55 PM, "Ian Bertolacci" <[email protected]> wrote: >In the attached program, compilation results in: > > >$CHPL_HOME/modules/standard/IO.chpl:3794: In function 'read': > >$CHPL_HOME/modules/standard/IO.chpl:3797: error: unresolved call >'channel(false,dynamic,true).read(string, style=type iostyle, >error=syserr)' > ><<< list of attempted function matches >>> > > > > > > > >Looking around IO.chpl:3797, I find the function declaration: > > > >pragma "no doc" > >proc channel.read(ref args ...?k, > > style:iostyle):bool { > > var e:syserr = ENOERR; > > this.read((...args), style=iostyle, error=e); // this is line 3797 > > if !e then return true; > > else if e == EEOF then return false; > > else { > > this._ch_ioerror(e, "in channel.read(" + > > _args_to_proto((...args), preArg="ref ") + > > "style:iostyle)"); > > return false; > > } > >} > > > > > > > >I believe that the call at 3797: > > > >this.read((...args), style=iostyle, error=e); // this is line 3797 > > > > >is in error, since it passes iostyle (which is a type) to read, when it >is expecting an instance of iostyle. > > > >I believe this to be incorrect behavior because the specification of >readln >(http://chapel.cray.com/docs/latest/modules/standard/IO.html#IO.channel.re >adln) >shows that I should be able to pass an instance of an iostyle object to >style: > > > >proc channel.readln(ref args ...?k, style: iostyle, out error: syserr): >bool > > > > >Changing line 3797 to be: > > >this.read((...args), style=style, error=e); > > >seems to solve this error. > > >Also, is there a straight-forward way to read a full line from a channel >into a variable? >I cannot seem to form an iostyle that will read all bytes of a line. > > >-Ian J. Bertolacci > > > > > > ------------------------------------------------------------------------------ _______________________________________________ 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
