Re: [Rd] Any plans for commenting out region via something like " /* */ "?
On Tue, Apr 26, 2005 at 05:22:42PM -0400, Roger D. Peng wrote:
> I realize this thread is a bit old, but it only just came to my
> mind. What about using a function like
>
> commentOut <- function(expr) { invisible() }
>
> and then
>
> commentOut({
> a <- 10
> bladfkljasdlkfj()
> blah blah blah
> })
>
> Lazy evaluation prevents the expression from being evaluated so
> you don't have to worry about syntatic correctness. And it nests
> too (I believe).
This doesn't work too well, unfortunately. Firstly the argument(s) of
commentOut are still parsed, so if there is a syntax error (which creates
a problem during parsing), execution is halted. Furthermore, while
a series of statements (separated by newlines or semicolons) is not
acceptable as a function argument, so this approach is limited to
commenting out pieces that represent single expressions.
Best regards, Jan
--
+- Jan T. Kim ---+
|*NEW*email: [EMAIL PROTECTED] |
|*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Objects in R
On Thu, Apr 21, 2005 at 01:01:54PM -0400, Roger D. Peng wrote: > One important thing to remember, which I think some more > experienced programmers may forget, is that R is two things---a > programming language and an *interactive* system for statistics > and graphics. Maintaining the "interactive-ableness" of R may > have imposed certain design choices. I personally think the > current S4 system of generics/methods is quite suitable for both > the "programming" and "interactive" sides of R. That's certainly a valid point. A more "standard" kind of object orientation does not necessarily impair interactive use, however. Python is no less usable interactively than R, for example. Best regards, Jan > Just $0.02. > > -roger > > Nathan Whitehouse wrote: > >Hi, > > A few comments from a fairly experienced R user who > >worked for several years on a R-based bioinformatics > >analysis framework. > > > > I don't want to misrepresent anyone's views, but... > > > > There are real disadvantages to the > >"objects-as-C-structs" and functions/methods which > >"mutate" based on argument type. i.e. S4. > > > > (1)Novices simply don't understand it. Students are > >trained in "standard" object-oriented technique and > >this wonkish offshoot(puritanical functional > >programming) just increases the information costs to > >using R and thus decreases the demand. -- +- Jan T. Kim ---+ |*NEW*email: [EMAIL PROTECTED] | |*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: hexadecimal constants and decimal points
On Sun, Apr 17, 2005 at 12:38:10PM +0100, Prof Brian Ripley wrote:
> These are some points stimulated by reading about C history (and
> related in their implementation).
>
>
> 1) On some platforms
>
> >as.integer("0xA")
> [1] 10
>
> but not all (not on Solaris nor Windows). We do not define what is
> allowed, and rely on the OS's implementation of strtod (yes, not strtol).
> It seems that glibc does allow hex: C99 mandates it but C89 seems not to
> allow it.
>
> I think that was a mistake, and strtol should have been used. Then C89
> does mandate the handling of hex constants and also octal ones. So
> changing to strtol would change the meaning of as.integer("011").
I think interpretation of a leading "0" as a prefix indicating an octal
representation should indeed be avoided. People not familiar to C will
have a hard time understanding and getting used to this concept, and
in addition, it happens way too often that numeric data are provided left-
padded with zeros.
> Proposal: we handle this ourselves and define what values are acceptable,
> namely for as.integer:
>
> [+|-][0-9]+
> NA
> 0[x|X][0-9A-fa-f]+
It can be a somewhat mixed blessing if the string representation of numeric
values contain information about their base, in the form of the 0x prefix
in this case.
The base argument (#3) of C's strtol function can be set to to a base
explicitly or to 0, which gives the prefix-based "auto-selection"
behaviour. On the R level, such a base argument (to as.integer) could be
included and a default could be set.
Personally, I would be equally happy with the default being 0 (auto-select)
or 10. Considering the perhaps limited spread of familiarity with C's
"0x" idiom, I somewhat favour a consistent and "stubborn" decimal behaviour
(base defaults to 10), though.
Best regards, Jan
--
+- Jan T. Kim ---+
|*NEW*email: [EMAIL PROTECTED] |
|*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How allocate STRSXP outside of gc
On Tue, Apr 12, 2005 at 12:31:03PM -0700, Vadim Ogranovich wrote:
> Hi,
>
> I am trying to figure a way to allocate a string SEXP so that gc() won't
> ever collect it.
>
> Here is a little bit of a background. Suppose I want to write a
> .Call-callable function that upon each call returns the same value, say
> mkChar("foo"):
>
> SEXP getFoo() {
>return mkChar("foo");
> }
>
> The above implementation doesn't take advantage of the fact that
> mkChar("foo") could be pre-computed only once, and then the function
> would return the pre-computed value. So the question is how to create
> this precomputed value.
>
>
> The closest thing I could find in the sources is R_NaString, but I was
> not able to trace down how it comes about.
For being unaffected by R's memory management, it may be the best to
not use a SEXP for storing the pre-computed result at all. Rather, use
a static variable "private" to your code, as in
SEXP getFoo()
{
static char *foo = NULL;
if (foo == NULL)
{
foo = the_difficult_to_compute_value_of_foo();
}
return mkChar(foo);
}
This way, getFoo indeed invokes mkChar each time, but in your scenario,
that might be an overhead which is negligible compared to the actual
computation of the foo value.
Best regards, Jan
--
+- Jan T. Kim ---+
|*NEW*email: [EMAIL PROTECTED] |
|*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Connection Programming API (was: R 2.1.0 scheduled for April 18)
On Wed, Mar 02, 2005 at 10:35:51PM +0100, Peter Dalgaard wrote: > The release schedule has now been set with a release date on April 18. > > The detailed procedure can be found at http://developer.r-project.org/ > (it is not quite there yet, but will appear after a short propagation > delay.) Are there any plans on providing an API that would allow packages to create and handle connections, before the "grand feature freeze"? The reason I ask is that I recently submitted a patch that adds filtering data through pipes to the core code. I had to write this as a patch because connection handling is done in a static array in src/main/connections.c and there is no API allowing packages to operate on that array. Will R 2.1.0 include filtering? And perhaps also forking, while we're at this? Best regards, Jan -- +- Jan T. Kim ---+ |*NEW*email: [EMAIL PROTECTED] | |*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pipe / Fork: Partial Solution / Providing Connections from C?
On Fri, Feb 11, 2005 at 02:32:20PM +0100, Peter Dalgaard wrote:
> "Jan T. Kim" <[EMAIL PROTECTED]> writes:
>
> > > Well, that is probably reasonably easy, but (not the least due to that
> > > fact) I'm still surprised that it has not been done already. I can hardly
> > > imagine that I'm the first one to want to use some external utility from
> > > an R program in this way.
> > >
> > > So, what do you R-devel folks do in this case, and what would you
> > > recommend?
> >
> > I'm still curious about this one. If there really is no way of running
> > stuff through external filter processes in R, I'd volunteer to add
> > that.
> >
> > Best regards & thanks in advance, Jan
>
> If you know how, please do. I have a suspicion it might not be as easy
> as it sounds because of the producer/consumer aspects. Notice, though,
> that in most cases you can get by with system() or pipe() and a
> temporary file for either the input or the output.
Personally, I see filtering as a process, and the sequence of collecting
input in a file, then filtering that into an output file, then reading
that and carrying on with it as a more complex process that involves
filtering as a part of it. Additional complexity means that there's more
that can go wrong, which is why I dislike temporary files.
Specifically. I've seen it happen too often (including to myself) that
things went wrong because other processes were interfering with the
temporary files (in most cases, other processes running the same program).
> I remember speculating about these matters when I was first introduced
> to pipes in C: They'd show you how to open a pipe for reading and how
> to do it for writing, but not how to do both with the same process.
> Took me a while to realize that there is a nontrivial deadlock issue
> if you try to write to a process that itself is blocked trying to
> write its output. Now that is of course not to say that it cannot be
> done with clever multiplexing and buffering techniques -- or
> multithreading, except that R isn't threaded.
It's clear to me that for real dynamic filtering, you need two processes
(or threads). This requires that the operating system supports forking,
i.e. that the fork package works. Without that, filtering is not
possible, at least I'm not in any way I'm aware of.
So, my plan would be to add some function to src/main/connections.c for
setting up a pipe running through an external command and returning the
write and read connections for use in the R program. Then, one could do
something like (modelled after the pipe example in the base docs):
library(fork);
data2 <- c(
"450, 390, 467, 654, 30, 542, 334, 432, 421,",
"357, 497, 493, 550, 549, 467, 575, 578, 342,",
"446, 547, 534, 495, 979, 479");
fp <- filterpipe("sed -e s/,$//");
{
pid <- fork(slave = NULL)
if (pid == 0)
{
close(fp$read);
write(data2, file = fp$write);
close(fp$write);
exit();
}
else
{
close(fp$write);
x <- scan(fp$read);
close(fp$read);
wait(pid);
}
}
Thinking about your buffering suggestion, it occurs to me that it *may*
be possible to create two anonymous files (of the file("") type) and
to connect these to the stdin and the stdout of an external process.
In fact, a couple of days ago I checked whether pipe() would perhaps
accept optional file arguments for specifying the external process'
stdin and stdout, so I could e.g.
f <- file("");
p <- pipe("sed -e s/,$//", stdin = f);
write(data2, file = f);
scan(p);
but that turned out to be another detour on the way that took me here...
Best regards, Jan
--
+- Jan T. Kim ---+
|*NEW*email: [EMAIL PROTECTED] |
|*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pipe / Fork: Partial Solution / Providing Connections from C?
Dear All, On Tue, Feb 01, 2005 at 07:50:17PM +, Jan T. Kim wrote: > On Tue, Feb 01, 2005 at 01:44:37PM +, Prof Brian Ripley wrote: > > If we only had to consider standard Unices, pipe() would allow read-write > > modes. As it is, it is easy for you to write an OS-specific extension. I've looked into this and tried to write a function that would start an external process and return two connections, one for writing to the external process and one for reading from it. Unfortunately, I haven't found a way to implement this in a package, without altering the R source code itself (details below). As an alternative / workaround, I coded up a function xpipe(cmd, input) that takes a command to start the external process (cmd) and a character containing the lines to be written (input), and returns a character vector containing the output produced by the external process. The xpipe package is available at http://www2.cmp.uea.ac.uk/~jtk/software/xpipe_0.0-1.tar.gz To an extent, this provides the functionality I was looking for, but it is not satisfactory because the output cannot be processed by R on line -- xpipe accumulates the entire output and returns it only after the external process has terminated. Also technically, it's cumbersome to use: For obtaining something else than a character value, it seems one has to write the output into an anonymous file and then use scan, read.table or whatever to read from that file. Therefore, I still look for a way to implement the design where the pipe ends are returned as R connections. The problem in doing so is that connections are stored in a static Rconnection Connections[NCONNECTIONS]; (file src/main/connections.c), and I cannot find any function that provides an interface for allocating a slot in the Connections array and storing a connection set up by a the code in my package there. There is a non-static (i.e. externally visible) NextConnection function (which is not declared in any header, though), and nothing like Rboolean setConnection(int connNumber, Rconnection *conn); Rconnection *getConnection(int connNumber); I haven't found any relevant documentation on these issues (R-exts doesn't have any info on handling connections in C code at all). Can any of you direct me to such docs, or point out how I can instantiate and return connections from within a package? > Well, that is probably reasonably easy, but (not the least due to that > fact) I'm still surprised that it has not been done already. I can hardly > imagine that I'm the first one to want to use some external utility from > an R program in this way. > > So, what do you R-devel folks do in this case, and what would you > recommend? I'm still curious about this one. If there really is no way of running stuff through external filter processes in R, I'd volunteer to add that. Best regards & thanks in advance, Jan -- +- Jan T. Kim ---+ |*NEW*email: [EMAIL PROTECTED] | |*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R] Process to both write to and read from (pipe/fork)?
On Tue, Feb 01, 2005 at 01:44:37PM +, Prof Brian Ripley wrote: > [Moved from R-help.] > > One reason you cannot easily do this with basic R functions is that it is > not portable. E.g. pipes on Windows 98 do not work like that, and > system() on that OS has to work hard to do something similar. Ok, thanks -- I really thought (and hoped) that I was just overlooking something obvious. I'm not fully convinced that the portability issues necessarily preclude providing the fork / pipe facilities, as there already is some differentiation present now, reflected by capabilities(). In fact, when I saw that availability of fifos is reflected by capabilities(), I thought that then, more basic pipes must also be accessible somehow (and spent some effort investigating this idea). > If we only had to consider standard Unices, pipe() would allow read-write > modes. As it is, it is easy for you to write an OS-specific extension. Well, that is probably reasonably easy, but (not the least due to that fact) I'm still surprised that it has not been done already. I can hardly imagine that I'm the first one to want to use some external utility from an R program in this way. So, what do you R-devel folks do in this case, and what would you recommend? > BTW, please re-read the distinction between R-devel and R-help in the > posting guide: this (and most of your other recent postings) seem to me to > fall unambiguously within the specification for R-devel. At the time of writing, I thought I was asking for help in using R... Best regards, Jan -- +- Jan T. Kim ---+ |*NEW*email: [EMAIL PROTECTED] | |*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
