Michael, Thats actually a pretty straight-forward solution. I just wrote a small string.reader() procedure to do the leg work (though its not as sophisticated as the file.reader() and may be a bit leaky)
-Ian On Mon, Sep 14, 2015 at 1:02 PM, Michael Ferguson <[email protected]> wrote: > Hi Ian - > > In the future, I hope that we can better integrate strings > and channels. In the mean time, you can 'read' from a string > like this: > > - start with a string > - open an in-memory file (openmem) > - write the string to the in-memory file > - open a channel for the in-memory file > - read whatever you want with readf etc > - close the channel and the file > > The future work I imagine would > - make it easier to write (fewer calls, more direct support, > it might have e.g. openstring ) > - avoid copying the string data into the channel > > > Cheers, > > -michael > > On 9/14/15, 2:57 PM, "Ian Bertolacci" <[email protected]> wrote: > > >Ok so the functionality I was looking for was in readline(). > >I'll try that. > > > >I was also wondering, is there a way to perform read() on strings? > > > >For example, if you read an entire something into a string, and then > >wanted to parse over that string, how would that be accomplished? > >It seems that the only way to take advantage of read()'s parsing > >capability is through the channels, which seem to require that they > >write/read to/from files. > > > > > >-Ian > > > > > >On Mon, Sep 14, 2015 at 8:57 AM, Brad Chamberlain > ><[email protected]> wrote: > > > >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.r > >>e > >>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
