Re: [Rd] serial connection patch
Simon, Thanks for reviewing it! All the modified files are under the GPL version 2 (except the configure script). According to the GPLv2, I am granted permission to modify and redistribute the code as long as I make a notice in the files of their modification and the date (which I have not done yet). As I understand (I'm not lawyer), the copyright is necessary for, and does not alter the terms of the GPLv2. Is there something specific you're thinking of that invalidates this? I updated the patch to open with O_NOCTTY to prevent opening the tty as the controlling terminal. Looks like this is default in BSD and GNU but maybe not in OS X. I'd like to hear how it goes if you try it again. I see the rationale for a tty (in scope) connection. As you observed, there are lots of options. However, some of them are designed to be used when the terminal IS the controlling terminal, for example, if you were writing a program like getty, so barring the use of R as a job control shell (which would be cool also, but probably not in the scope of R), some of the options need not be exposed. For instance, canonical mode may never be necessary/appropriate. But it would be cool to use RTS/CTS, XON/XOFF, blocking, and some of the other stuff that is not there yet. I have some ideas on how to expose these features concisely. I'll continue to work on this as time permits (i.e. probably at weekend), with consideration for your suggestions. Thanks again, -Matt On Mon, 2010-04-26 at 14:18 -0400, Simon Urbanek wrote: Matt, thanks for you efforts. We cannot directly use your patch due to licensing issues (please note the licenses in the files you are modifying - I don't think anyone can currently use the patch and redistribute the resulting R; also/or we may possibly need to clarify that the work is either done on behalf of the R-foundation or the copyright is assigned to R-foundation or something similar so future licensing issues can be solved by the Foundation since that is the copyright holder of most of R). Apart from that, the overall structure looks good, but the devil is in the details. It does not quite work for me on OS X (any read/writes just hang in the same way that it would if you used a file connection on the tty device) - I don't think it is as simple (AFAIR you have to make sure you open it such that it doesn't become the controlling terminal). Also it would definitely need blocking argument like most other connections have. In general I don't think serial is the right name (and scope) here - what we're really looking for a is a tty connection (and serial just an application of it). What you have so far is a file connection with setserial functionality on it - and I think that may be more easily done by really using setserial on the already implemented file connection. The difference with tty is the other parts such as flow control, modes etc. It's much more work to expose those, but I think that is what the direction would be. In fact it could well be that tty is simply file connection + termio so you don't have to re-invent the wheel (under the hood). Also that would give you many aspects for free since you could inherit from file at the R level. I hope it helps. I was thinking about the above but in the end decided to back off once I was looking at the flood of parameters you have to take care of in tty. But it would be nice if someone did that ;). Cheers, Simon On Apr 26, 2010, at 12:28 PM, Matt Shotwell wrote: All, Our discussion of serial interfaces last week motivated me to dig into the R connections API. In short, I spent the weekend writing a patch for version 2.11.0 that adds a serial connection. I posted a blog entry that gives instructions for applying, configuring, and compiling the patched version http://biostatmatt.com/archives/112. The patch currently only enables a serial connection for POSIX compliant OSs. It should NOT be considered well tested, though I feel it is fairly safe. I would really like to hear from someone who can try it on Mac OS X (and Windows to ensure that it has the correct 'null' behavior). Briefly, the connection utilizes (and checks for) the termios.h header. I opted not to extend the 'file' connection in a manner similar to the 'pipe' connection because this might not be suitable under Win32. Hence, there are new read, write, flush, open, and close methods and a struct serialconn for the serial connection. Opens are non-blocking and binary only. Serial parameters can be passed when the connection is created. I overloaded the summary method in order for the user to see the serial settings. I've done my best to be consistent and conforming with the connections API and coding style. However, I would be great if someone with more experience with the R API (Simon? :)) would take a critical look at the design and coding of the new connection. If this is
Re: [Rd] serial connection patch
On 27/04/2010 8:32 AM, Matt Shotwell wrote: Simon, Thanks for reviewing it! All the modified files are under the GPL version 2 (except the configure script). According to the GPLv2, I am granted permission to modify and redistribute the code as long as I make a notice in the files of their modification and the date (which I have not done yet). As I understand (I'm not lawyer), the copyright is necessary for, and does not alter the terms of the GPLv2. Is there something specific you're thinking of that invalidates this? I don't know what Simon noticed, but I saw that you had indicated a GPL v3 license on the web page. GPL2 is not compatible with GPL3, so that makes your contribution unusable by us. Duncan Murdoch I updated the patch to open with O_NOCTTY to prevent opening the tty as the controlling terminal. Looks like this is default in BSD and GNU but maybe not in OS X. I'd like to hear how it goes if you try it again. I see the rationale for a tty (in scope) connection. As you observed, there are lots of options. However, some of them are designed to be used when the terminal IS the controlling terminal, for example, if you were writing a program like getty, so barring the use of R as a job control shell (which would be cool also, but probably not in the scope of R), some of the options need not be exposed. For instance, canonical mode may never be necessary/appropriate. But it would be cool to use RTS/CTS, XON/XOFF, blocking, and some of the other stuff that is not there yet. I have some ideas on how to expose these features concisely. I'll continue to work on this as time permits (i.e. probably at weekend), with consideration for your suggestions. Thanks again, -Matt On Mon, 2010-04-26 at 14:18 -0400, Simon Urbanek wrote: Matt, thanks for you efforts. We cannot directly use your patch due to licensing issues (please note the licenses in the files you are modifying - I don't think anyone can currently use the patch and redistribute the resulting R; also/or we may possibly need to clarify that the work is either done on behalf of the R-foundation or the copyright is assigned to R-foundation or something similar so future licensing issues can be solved by the Foundation since that is the copyright holder of most of R). Apart from that, the overall structure looks good, but the devil is in the details. It does not quite work for me on OS X (any read/writes just hang in the same way that it would if you used a file connection on the tty device) - I don't think it is as simple (AFAIR you have to make sure you open it such that it doesn't become the controlling terminal). Also it would definitely need blocking argument like most other connections have. In general I don't think serial is the right name (and scope) here - what we're really looking for a is a tty connection (and serial just an application of it). What you have so far is a file connection with setserial functionality on it - and I think that may be more easily done by really using setserial on the already implemented file connection. The difference with tty is the other parts such as flow control, modes etc. It's much more work to expose those, but I think that is what the direction would be. In fact it could well be that tty is simply file connection + termio so you don't have to re-invent the wheel (under the hood). Also that would give you many aspects for free since you could inherit from file at the R level. I hope it helps. I was thinking about the above but in the end decided to back off once I was looking at the flood of parameters you have to take care of in tty. But it would be nice if someone did that ;). Cheers, Simon On Apr 26, 2010, at 12:28 PM, Matt Shotwell wrote: All, Our discussion of serial interfaces last week motivated me to dig into the R connections API. In short, I spent the weekend writing a patch for version 2.11.0 that adds a serial connection. I posted a blog entry that gives instructions for applying, configuring, and compiling the patched version http://biostatmatt.com/archives/112. The patch currently only enables a serial connection for POSIX compliant OSs. It should NOT be considered well tested, though I feel it is fairly safe. I would really like to hear from someone who can try it on Mac OS X (and Windows to ensure that it has the correct 'null' behavior). Briefly, the connection utilizes (and checks for) the termios.h header. I opted not to extend the 'file' connection in a manner similar to the 'pipe' connection because this might not be suitable under Win32. Hence, there are new read, write, flush, open, and close methods and a struct serialconn for the serial connection. Opens are non-blocking and binary only. Serial parameters can be passed when the connection is created. I overloaded the summary method in order for the user to see the serial settings. I've done my best to be consistent and conforming with
Re: [Rd] serial connection patch
On Apr 27, 2010, at 2:42 PM, Duncan Murdoch wrote: On 27/04/2010 8:32 AM, Matt Shotwell wrote: Simon, Thanks for reviewing it! All the modified files are under the GPL version 2 (except the configure script). According to the GPLv2, I am granted permission to modify and redistribute the code as long as I make a notice in the files of their modification and the date (which I have not done yet). As I understand (I'm not lawyer), the copyright is necessary for, and does not alter the terms of the GPLv2. Is there something specific you're thinking of that invalidates this? I don't know what Simon noticed, but I saw that you had indicated a GPL v3 license on the web page. GPL2 is not compatible with GPL3, so that makes your contribution unusable by us. Yes, this is a bit messy, but some got sufficiently annoyed by the added restrictions of GPL3 that they insist on keeping their contributions GPL2, so adding GPL3-only stuff is off limits. I don't think we have a problem with merging user contributions that are licensed GPL2 or later. A copyright transfer gives some legal clarification, but is only really required in case the R Foundation wants to (dual-) relicense under a GPL incompatible license, or need to be able to legally defend users' code against infringement. The former is highly unlikely, and it would require major disentanglement in other areas anyway, and I don't see contributions of this order of magnitude as a target of legal dispute either. Duncan Murdoch -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serial connection patch
Oh, I just put that there for the bit about WITHOUT ANY WARRANTY :). I am satisfied with GPLv2 and have updated the license notice to reflect a change from GPLv3 to GPLv2 or later. -Matt On Tue, 2010-04-27 at 09:33 -0400, Peter Dalgaard wrote: On Apr 27, 2010, at 2:42 PM, Duncan Murdoch wrote: On 27/04/2010 8:32 AM, Matt Shotwell wrote: Simon, Thanks for reviewing it! All the modified files are under the GPL version 2 (except the configure script). According to the GPLv2, I am granted permission to modify and redistribute the code as long as I make a notice in the files of their modification and the date (which I have not done yet). As I understand (I'm not lawyer), the copyright is necessary for, and does not alter the terms of the GPLv2. Is there something specific you're thinking of that invalidates this? I don't know what Simon noticed, but I saw that you had indicated a GPL v3 license on the web page. GPL2 is not compatible with GPL3, so that makes your contribution unusable by us. Yes, this is a bit messy, but some got sufficiently annoyed by the added restrictions of GPL3 that they insist on keeping their contributions GPL2, so adding GPL3-only stuff is off limits. I don't think we have a problem with merging user contributions that are licensed GPL2 or later. A copyright transfer gives some legal clarification, but is only really required in case the R Foundation wants to (dual-) relicense under a GPL incompatible license, or need to be able to legally defend users' code against infringement. The former is highly unlikely, and it would require major disentanglement in other areas anyway, and I don't see contributions of this order of magnitude as a target of legal dispute either. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serial connection patch
Matt, thanks for you efforts. We cannot directly use your patch due to licensing issues (please note the licenses in the files you are modifying - I don't think anyone can currently use the patch and redistribute the resulting R; also/or we may possibly need to clarify that the work is either done on behalf of the R-foundation or the copyright is assigned to R-foundation or something similar so future licensing issues can be solved by the Foundation since that is the copyright holder of most of R). Apart from that, the overall structure looks good, but the devil is in the details. It does not quite work for me on OS X (any read/writes just hang in the same way that it would if you used a file connection on the tty device) - I don't think it is as simple (AFAIR you have to make sure you open it such that it doesn't become the controlling terminal). Also it would definitely need blocking argument like most other connections have. In general I don't think serial is the right name (and scope) here - what we're really looking for a is a tty connection (and serial just an application of it). What you have so far is a file connection with setserial functionality on it - and I think that may be more easily done by really using setserial on the already implemented file connection. The difference with tty is the other parts such as flow control, modes etc. It's much more work to expose those, but I think that is what the direction would be. In fact it could well be that tty is simply file connection + termio so you don't have to re-invent the wheel (under the hood). Also that would give you many aspects for free since you could inherit from file at the R level. I hope it helps. I was thinking about the above but in the end decided to back off once I was looking at the flood of parameters you have to take care of in tty. But it would be nice if someone did that ;). Cheers, Simon On Apr 26, 2010, at 12:28 PM, Matt Shotwell wrote: All, Our discussion of serial interfaces last week motivated me to dig into the R connections API. In short, I spent the weekend writing a patch for version 2.11.0 that adds a serial connection. I posted a blog entry that gives instructions for applying, configuring, and compiling the patched version http://biostatmatt.com/archives/112. The patch currently only enables a serial connection for POSIX compliant OSs. It should NOT be considered well tested, though I feel it is fairly safe. I would really like to hear from someone who can try it on Mac OS X (and Windows to ensure that it has the correct 'null' behavior). Briefly, the connection utilizes (and checks for) the termios.h header. I opted not to extend the 'file' connection in a manner similar to the 'pipe' connection because this might not be suitable under Win32. Hence, there are new read, write, flush, open, and close methods and a struct serialconn for the serial connection. Opens are non-blocking and binary only. Serial parameters can be passed when the connection is created. I overloaded the summary method in order for the user to see the serial settings. I've done my best to be consistent and conforming with the connections API and coding style. However, I would be great if someone with more experience with the R API (Simon? :)) would take a critical look at the design and coding of the new connection. If this is something that the R community would like to pursue, I'd like to work on support for Windows serial interfaces. Below is a link to the patch file and the output of diffstat. http://biostatmatt.com/R/R-2.11.0-serial.patch file| modins del configure.ac|21 + 1 - src/include/Internal.h |22 + 0 - src/library/base/R/connections.R| 1010 +0 - src/library/base/man/connections.Rd | 6049 +11 - src/main/connections.c | 379379 + 0 - src/main/names.c|22 + 0 - P.S. connections.c is the largest file in src/main/, before and after the patch. Making the 379 additions increased the file size by 6.9% (10.7kB). Adding Windows support should increase the file size by a lesser amount. -Matt On Wed, 2010-04-21 at 08:07 -0400, Simon Urbanek wrote: Philippe, unfortunately that approach has one major drawback - it does not give you a connection. As I said in the previous e-mail it is fairly easy to talk to a tty directly, but the challenge is to turn it into a connection. I don't like the Tcl approach for several reasons, one of them being that it's entirely unnatural since you have to construct strings of code -- you could as well use rJava and Java serial connections which has a little more friendly syntax (but I wouldn't recommend that, either) or any other language R interfaces to. I was thinking
