headers
Bill Dunlap | 1 Jun 2007 02:52

Re: [Rd] Possible changes to connections

On Thu, 31 May 2007, Seth Falcon wrote:

> > When I ran some tests I found 7 packages on CRAN that in their tests
> > were not closing connections.  Four of those are maintained by R-core
> > members.
> > Even though none were by me, I think this is too easy to forget to
> > do!
>
> I agree that it is easy to forget.  It is especially easy if one
> creates so-called anonymous connection references like
> readLines(file(path)) -- this anonymous idiom seems nature to me when
> coding R and it would be nice to make it work for connections.

I like the idea of the connection being closed when there
are no more references to it.  I guess that means when the
garbage collector notices it has been orphaned, which may
take a while.

However, one of my longstanding complaints about connections
in Splus and R may have a bearing here also.  Currently, if you
want to have your file opened in a particular way, say for
only reading or for appending or in binary mode then you
need to specify open=mode when calling file().  However that
also tells it to actually open the file.  I would prefer that
there was a mode= argument to file that meant that when the
file is eventually opened it would be opened with that mode.
open= should be restricted to TRUE or FALSE, or IMO, be eliminated.
(We have an open() function for that.)  With the current system
   readLines(file(path))
does not leave path open but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dirk Eddelbuettel | 1 Jun 2007 03:12
Picon
Favicon
Gravatar

Re: [Rd] Problems when linking to R shared library


On 31 May 2007 at 19:04, John Maddock wrote:
| Folks,
| 
| I'm fairly sure that I'm doing something stupid, but I'm getting a few
| really strange results from *some* of the distributions, but by no means 
| all,
| when I link directly to the R shared library.

When I try to build your program, I get very immediate and explicit messages:

edd <at> basebud:~> g++ -Wall -O3 -I/usr/share/R/include -o /tmp/johnmaddock /tmp/johnmaddock.cc -lRmath
/tmp/ccb5T7l9.o: In function `main':
johnmaddock.cc:(.text+0xae): undefined reference to `Rf_pf'
johnmaddock.cc:(.text+0xed): undefined reference to `Rf_pchisq'
johnmaddock.cc:(.text+0x136): undefined reference to `Rf_pgamma'
johnmaddock.cc:(.text+0x17a): undefined reference to `Rf_ppois'
johnmaddock.cc:(.text+0x1b9): undefined reference to `Rf_qchisq'
johnmaddock.cc:(.text+0x202): undefined reference to `Rf_qgamma'
collect2: ld returned 1 exit status

which shows that the compiler/linker do not yet know about the functions you
use. 

Your mistake was to not do 

#define MATHLIB_STANDALONE 1

before the #include of Rmath.h.  After that, all is well:
(Continue reading)

Permalink | Reply | 0 comments |
headers
mel | 1 Jun 2007 08:24

Re: [Rd] Possible changes to connections

Prof Brian Ripley a écrit :

>> I use getConnection().
>> In the context in which I use it, the number of the connection is
>> known a priori.
> 
> I don't see how you can know it 'a priori': it is an implementation detail
> (and since R itself uses connections, those details could easily change).

(disclaimer : I don't claim its the best way to proceed)

Before launching my app, the connections context is :
 > showConnections(all=TRUE)
   description class      mode text   isopen   can read can write
0 "stdin"     "terminal" "r"  "text" "opened" "yes"    "no"
1 "stdout"    "terminal" "w"  "text" "opened" "no"     "yes"
2 "stderr"    "terminal" "w"  "text" "opened" "no"     "yes"

So, the call to socketConnections() creates always (at least
for all my experiments) a connection with number 3.
Btw, if (socketConnections(...) != 3) the application simply
don't launch.
So, if the application runs, it's sure that this is with a
connection number==3.
That's why I say that "the number of the connection is known a priori".

Of course, the connection number could also be retrieved eg using
the description field.

______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prof Brian Ripley | 1 Jun 2007 08:39
Picon
Picon
Favicon

Re: [Rd] Possible changes to connections

On Fri, 1 Jun 2007, mel wrote:

> Prof Brian Ripley a écrit :
>
>>> I use getConnection().
>>> In the context in which I use it, the number of the connection is
>>> known a priori.
>>
>> I don't see how you can know it 'a priori': it is an implementation detail
>> (and since R itself uses connections, those details could easily change).
>
> (disclaimer : I don't claim its the best way to proceed)
>
> Before launching my app, the connections context is :
> > showConnections(all=TRUE)
>   description class      mode text   isopen   can read can write
> 0 "stdin"     "terminal" "r"  "text" "opened" "yes"    "no"
> 1 "stdout"    "terminal" "w"  "text" "opened" "no"     "yes"
> 2 "stderr"    "terminal" "w"  "text" "opened" "no"     "yes"
>
> So, the call to socketConnections() creates always (at least
> for all my experiments) a connection with number 3.
> Btw, if (socketConnections(...) != 3) the application simply
> don't launch.
> So, if the application runs, it's sure that this is with a
> connection number==3.
> That's why I say that "the number of the connection is known a priori".

You don't *know* that: it depends on how R internally numbers connections 
and what the startup code does.  That detail will almost certainly change.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Byron Ellis | 1 Jun 2007 09:42
Picon

Re: [Rd] Possible changes to connections

On 5/31/07, Bill Dunlap <bill <at> insightful.com> wrote:

> I like the idea of the connection being closed when there
> are no more references to it.  I guess that means when the
> garbage collector notices it has been orphaned, which may
> take a while.

Although, playing devil's advocate, it Green Book connections do
follow the same pattern as the other resource allocation type,
graphics devices. Not that this should be taken as endorsement, I
think I would like to see graphics devices head in the direction of
being actual objects as well (and I think I would want with() to be
involved with that).

It would also be really nice if connections became more like graphics
devices in that new connections could be implemented from a package.
That would make, for example, implementing clipboard connections on OS
X do the Right Thing under X11 and the GUI.

CLIM-style event streams would also be nice, but is almost surely too
much to ask. :-)

>
> However, one of my longstanding complaints about connections
> in Splus and R may have a bearing here also.  Currently, if you
> want to have your file opened in a particular way, say for
> only reading or for appending or in binary mode then you
> need to specify open=mode when calling file().  However that
> also tells it to actually open the file.  I would prefer that
> there was a mode= argument to file that meant that when the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prof Brian Ripley | 1 Jun 2007 11:32
Picon
Picon
Favicon

Re: [Rd] Problem building R from source on Windows

On Thu, 31 May 2007, Jonathan Swinton wrote:

>
> I have a problem when building R from source on Windows XP.
>
> When I get to 3.1.3 of the Installation and Administration manual and try
> make all recommended
> from R_HOME it fails with
> make: *** No rule to make target `all'.  Stop.

But it is from R_HOME/src/gnuwin32.

> I am pretty sure there is an obvious and well documented thing I am missing,
> but missing it I am. Any clues?
>
> Is my problem that I have a Makefile.in but not a Makefile? Have I understood
> section 3.1.3 correctly that no ./configure step is needed? Although my reading
> of the I&A manual is that no ./configure step is needed under Windows, I did
> wonder and tried running
> sh ./configure

You really don't want to do that, and to be sure it did no harm you need 
to unpack R afresh.

> but that failed with
> chmod: not found
> chmod: not found
> chmod: not found
> configure: error: cannot create configure.lineno; rerun with a POSIX shell
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ev Whin | 1 Jun 2007 11:44
Picon

[Rd] Question on the R's C stack limit

Dear r-devel members,
    I encountered a C stack limit issue, when I tried to embed R 2.5 into my
application. In the R-exts document, it says:"Note that R's own front ends
use a stack size of 10Mb". I desire to know: is it possible to decrease this
stack size
by modifying R's source code? If it's possible, which part of the source
code is responsible for the issue?

Thank you all.

Whin

	[[alternative HTML version deleted]]

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Permalink | Reply | 3 comments |
headers
Prof Brian Ripley | 1 Jun 2007 11:58
Picon
Picon
Favicon

Re: [Rd] Question on the R's C stack limit

On Fri, 1 Jun 2007, Ev Whin wrote:

> Dear r-devel members,
>    I encountered a C stack limit issue, when I tried to embed R 2.5 into my
> application. In the R-exts document, it says:"Note that R's own front ends
> use a stack size of 10Mb". I desire to know: is it possible to decrease this
> stack size
> by modifying R's source code? If it's possible, which part of the source
> code is responsible for the issue?

You have picked that out of the Windows-specific documentation without 
saying you are on Windows (are you?).  The setting is in 
src/gnuwin/front-ends, unsurprisingly.  (In the Makefile, to be exact.)

> Thank you all.
>
> Whin
>
> 	[[alternative HTML version deleted]]

Please don't send HTML: see the posting guide.

--

-- 
Brian D. Ripley,                  ripley <at> 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 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Urbanek | 1 Jun 2007 14:59
Favicon

Re: [Rd] Question on the R's C stack limit

On Jun 1, 2007, at 5:44 AM, Ev Whin wrote:

> Dear r-devel members,
>     I encountered a C stack limit issue, when I tried to embed R  
> 2.5 into my
> application.

If you are embedding R, you can change or disable the stack limit by  
setting R_CStackLimit appropriately. There is no need to change the R  
source code.

Cheers,
Simon

> In the R-exts document, it says:"Note that R's own front ends
> use a stack size of 10Mb". I desire to know: is it possible to  
> decrease this
> stack size
> by modifying R's source code? If it's possible, which part of the  
> source
> code is responsible for the issue?
>
> Thank you all.
>

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen B. Weston | 1 Jun 2007 17:05

Re: [Rd] Possible changes to connections

Prof Brian Ripley <ripley <at> stats.ox.ac.uk> writes:

 > [I know there is a call to getConnection in package gtools, but
 > the return value is unused!]

Speaking of connections and gtools, I've been wondering if the
gtools setTCPNoDelay function's method of getting the Unix file
descriptor of a socket connection is safe.  It's basically doing
this:

   d <- as.integer(socketConnection("localhost", 80)[1])

Is that depending on an implementation detail that may change?
I think it's useful to allow C extensions to set OS specific
socket options on connection objects.  But perhaps Jeffrey
Horner's proposal addresses this need.

- Steve

______________________________________________
R-devel <at> r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Permalink | Reply | 0 comments |

Gmane