I'd like to have this to be used in, e.g., demo() and example(). Currently, source() parse()s the entire file and then evaluates expression by expression. ``Of course'', parse() already loses the comments. An (much slower) alternative might be to the readLine() the file, echo what we read, and try to parse() ``the current chunk''. when parse() fails (when the current expression is incomplete), we silently read the next line, etc, until the expression is complete and hence parse() succeeds, then we eval() and print(). What do people think? Would there be volunteers to write this? [I think it should finalize as an optional argument to source(), but for experimentation it might be easier to try with a function sourceLinewise(.) ]. Martin Maechler <maechler@stat.math.ethz.ch> http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <>< -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
a version of source() which keeps comments ?
6 messages · Martin Maechler, Friedrich Leisch, Peter Dalgaard +3 more
On Thu, 20 Jun 2002 12:13:33 +0200, Martin Maechler (MM) wrote:
> I'd like to have this to be used in, e.g., > demo() and example(). > Currently, source() parse()s the entire file and then evaluates > expression by expression. ``Of course'', parse() already loses > the comments. > An (much slower) alternative might be to the readLine() the > file, echo what we read, > and try to parse() ``the current chunk''. > when parse() fails (when the current expression is incomplete), > we silently read the next line, etc, until the expression is complete and hence > parse() succeeds, then we eval() and print(). > What do people think? > Would there be volunteers to write this? > [I think it should finalize as an optional argument to source(), > but for experimentation it might be easier to try with a > function sourceLinewise(.) > ]. I'm not a volunteer but the feature would also be extremely useful for Sweave (and probably most other dynamic report approaches), where we currently loose all comments in code chunks. .f -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Martin Maechler <maechler@stat.math.ethz.ch> writes:
I'd like to have this to be used in, e.g., demo() and example(). Currently, source() parse()s the entire file and then evaluates expression by expression. ``Of course'', parse() already loses the comments. An (much slower) alternative might be to the readLine() the file, echo what we read, and try to parse() ``the current chunk''. when parse() fails (when the current expression is incomplete), we silently read the next line, etc, until the expression is complete and hence parse() succeeds, then we eval() and print(). What do people think? Would there be volunteers to write this? [I think it should finalize as an optional argument to source(), but for experimentation it might be easier to try with a function sourceLinewise(.) ].
Historically, this is what source() should have done all the time if it were to be in keeping with other Unix programs (shift input from stdin temporarily). The source() that we have is really "evaluate file". I don't think we can source() an infinite stream like a pipe or a socket, can we? Actually, I think it can be done with a little careful file descriptor switching. (Turn of readline processing, etc., switch stdin to file, run till eof or error, switch back and reestablish readline.) We'd still have the reparse-on-incomplete thing, since that also happens on stdin -- something I suspect isn't necessary, but it takes a fairly hard look at the grammar itself to find out. (This kind of stuff has long been on my might-do list of projects, along with (re)fixing the comment issue and providing better information on parse/eval errors. I'd better not feel possessive about the ideas...)
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On 20 Jun 2002, Peter Dalgaard BSA wrote:
Martin Maechler <maechler@stat.math.ethz.ch> writes:
I'd like to have this to be used in, e.g., demo() and example(). Currently, source() parse()s the entire file and then evaluates expression by expression. ``Of course'', parse() already loses the comments. An (much slower) alternative might be to the readLine() the file, echo what we read, and try to parse() ``the current chunk''. when parse() fails (when the current expression is incomplete), we silently read the next line, etc, until the expression is complete and hence parse() succeeds, then we eval() and print(). What do people think? Would there be volunteers to write this? [I think it should finalize as an optional argument to source(), but for experimentation it might be easier to try with a function sourceLinewise(.) ].
Historically, this is what source() should have done all the time if it were to be in keeping with other Unix programs (shift input from stdin temporarily). The source() that we have is really "evaluate file". I don't think we can source() an infinite stream like a pipe or a socket, can we? Actually, I think it can be done with a little careful file descriptor switching. (Turn of readline processing, etc., switch stdin to file, run till eof or error, switch back and reestablish readline.) We'd
Rather, connection-switching. The Green book describes sink() as being capable of switching the input connection, but it isn't like that in any version of S-PLUS I have ever seen. I haven't thought through the ramifications.
still have the reparse-on-incomplete thing, since that also happens on stdin -- something I suspect isn't necessary, but it takes a fairly hard look at the grammar itself to find out. (This kind of stuff has long been on my might-do list of projects, along with (re)fixing the comment issue and providing better information on parse/eval errors. I'd better not feel possessive about the ideas...) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
ripley@stats.ox.ac.uk wrote:
On 20 Jun 2002, Peter Dalgaard BSA wrote:
Martin Maechler <maechler@stat.math.ethz.ch> writes:
I'd like to have this to be used in, e.g., demo() and example(). Currently, source() parse()s the entire file and then evaluates expression by expression. ``Of course'', parse() already loses the comments. An (much slower) alternative might be to the readLine() the file, echo what we read, and try to parse() ``the current chunk''. when parse() fails (when the current expression is incomplete), we silently read the next line, etc, until the expression is complete and hence parse() succeeds, then we eval() and print(). What do people think? Would there be volunteers to write this? [I think it should finalize as an optional argument to source(), but for experimentation it might be easier to try with a function sourceLinewise(.) ].
Historically, this is what source() should have done all the time if it were to be in keeping with other Unix programs (shift input from stdin temporarily). The source() that we have is really "evaluate file". I don't think we can source() an infinite stream like a pipe or a socket, can we? Actually, I think it can be done with a little careful file descriptor switching. (Turn of readline processing, etc., switch stdin to file, run till eof or error, switch back and reestablish readline.) We'd
Rather, connection-switching. The Green book describes sink() as being capable of switching the input connection, but it isn't like that in any version of S-PLUS I have ever seen. I haven't thought through the ramifications.
And I'll make a further distinction (again based on S4 and hopefully very soon to be R): specifically we should be able to switch `reader' on a connection. In S4 one can associate an S function with a connection so that when input becomes available on the connection's file descriptor, the S function is invoked. This is a reader. We can support this on Unix using the AddInputHandler, but we need to add a method to the C level connection structure to get its file descriptor. Additionally, I'm in the middle of experimenting with different event loops (e.g. those of Tcl/Tk and Gtk) and allowing them to be run as the main R event loop. We get timers (monitors in S4) and file descriptor notification for "free" in both of these. I intend to have an RFC for this and an implementation for sliding it into R next week. (Anyone's welcome to the code now if they are interested.)
still have the reparse-on-incomplete thing, since that also happens on stdin -- something I suspect isn't necessary, but it takes a fairly hard look at the grammar itself to find out. (This kind of stuff has long been on my might-do list of projects, along with (re)fixing the comment issue and providing better information on parse/eval errors. I'd better not feel possessive about the ideas...) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
-- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
_______________________________________________________________
Duncan Temple Lang duncan@research.bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-3217
700 Mountain Avenue, Room 2C-259 fax: (908)582-3340
Murray Hill, NJ 07974-2070
http://cm.bell-labs.com/stat/duncan
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On 20 Jun 2002 13:21:00 +0200, you wrote:
(This kind of stuff has long been on my might-do list of projects, along with (re)fixing the comment issue and providing better information on parse/eval errors. I'd better not feel possessive about the ideas...)
If this were done, it would be nice to do it in a way that would allow better debugging hooks sometime in the future. Specifically: - the error mechanism should know the filename and line number that was being parsed when the error occurred, and should report them. - as functions are being defined the filename and line numbers corresponding to (the start of) each statement should be saveable, so a debugger could work on the source file, instead of on the deparsed version. - it should be possible to set a (conditional?) breakpoint on a line number in a file. I'm not saying that we should hold off on getting source() right until we can do all of the above, just that if possible those things should be kept in mind as source is being fixed. Duncan Murdoch -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._