hi kevin---I would be happy to open an issue, but I would prefer if the "honor" was left to someone (you?) who can articulate it better. I am a true novice here.
if I understand it right, the fix is easy. is a "Handle" change complex and/or needed? just overload all functions that expect a Pipe to work also with the (Pipe,Process) tuple. otoh, maybe doing this with a Handle simply automates this everywhere?! not sure. I can't weigh in on a discussion. I just don't know enough. regards, /iaw ---- Ivo Welch ([email protected]) http://www.ivo-welch.info/ J. Fred Weston Distinguished Professor of Finance Anderson School at UCLA, C519 Director, UCLA Anderson Fink Center for Finance and Investments Free Finance Textbook, http://book.ivo-welch.info/ Exec Editor, Critical Finance Review, http://www.critical-finance-review.org/ Editor and Publisher, FAMe, http://www.fame-jagazine.com/ On Mon, Jan 5, 2015 at 6:09 AM, Kevin Squire <[email protected]> wrote: > > >>> another strange definition from a novice perspective: close(x1) is >>> not defined. close(x1[1]) is. >> >> >> close() is defined for a stream, not a tuple (stream, process). >> >>> >>> julia is the first language I have >>> seen where a close(open("file")) is wrong. > > > FWIW, I believe that there was concern that the behavior of open(process) > might cause confusion when it was defined in this way. (A quick search > didn't locate the issue.) > > The goal was to minimize the number of methods, but it might be worth > exploring alternative interface. A simple change would be to create and > return a typed object (say, Handle), instead of a tuple, which would both > allow easy closing directly and give access to the opened process. > > Ivo, would you be willing to open an issue regarding your confusion here > (and point back to this thread)? > > Cheers, > Kevin > > >> >> close(open("filenamestring")) is fine, close(open(command)) is not because >> open(command) returns a tuple of two things, not just the stream. This is >> Julia's primary paradigm, multi-dispatch means that the same named function >> can have several methods that do different things depending on the *type* of >> the arguments to the call, string or command. > > > > >> >> >>> >>> this is esp surprising >>> because julia has the dispatch ability to understand what it could do >>> with a close(Pipe,Process) tuple. >> >> >> But only if such a close() method is defined, which it is not. Maybe it >> should be, but open(command) is significantly less used than open(file). >> >> Cheers >> Lex >> >> >>> >>> the same holds true for other >>> functions that expect a part of open. julia should be smart enough to >>> know this. >>> >>> regards, >>> >>> /iaw >>> >>> ---- >>> Ivo Welch ([email protected]) >>> http://www.ivo-welch.info/ >>> J. Fred Weston Distinguished Professor of Finance >>> Anderson School at UCLA, C519 >>> Director, UCLA Anderson Fink Center for Finance and Investments >>> Free Finance Textbook, http://book.ivo-welch.info/ >>> Exec Editor, Critical Finance Review, >>> http://www.critical-finance-review.org/ >>> Editor and Publisher, FAMe, http://www.fame-jagazine.com/ >>> >>> >>> On Sun, Jan 4, 2015 at 6:29 PM, Todd Leo <[email protected]> wrote: >>> > An intuitive thought is, uncompress your csv file via bash utility >>> > zcat, >>> > pipe it to STDIN and use readline(STDIN) in julia. >>> > >>> > >>> > >>> > On Monday, January 5, 2015 7:51:18 AM UTC+8, ivo welch wrote: >>> >> >>> >> >>> >> dear julia users: beginner's question (apologies, more will be >>> >> coming). >>> >> it's probably obvious. >>> >> >>> >> I am storing files in compressed csv form. I want to use the built-in >>> >> julia readcsv() function. but I also need to pipe through a >>> >> decompressor >>> >> first. so, I tried a variety of forms, like >>> >> >>> >> d= readcsv("/usr/bin/gzcat ./myfile.csv.gz |") >>> >> d= readcsv("`/usr/bin/gzcat ./myfile.csv.gz`") >>> >> >>> >> I can type the file with run(`/usr/bin/gzcat ./crsp90.csv.gz"), but >>> >> wrapping a readcsv around it does not capture it. how does one do >>> >> this? >>> >> >>> >> regards, >>> >> >>> >> /iaw >>> >> >>> >
