<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.r.devel">
    <title>gmane.comp.lang.r.devel</title>
    <link>http://blog.gmane.org/gmane.comp.lang.r.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31112"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31111"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31110"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31109"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31108"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31107"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31106"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31105"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31104"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31103"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31102"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31101"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31100"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31099"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31098"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31097"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31096"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31095"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31094"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.devel/31093"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31112">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31112</link>
    <description>&lt;pre&gt;
I don't see why.  t(DF) is not a dataframe, so it will give surprising 
answers in a different way.  If people rely on using code in ways that 
are documented to give unexpected results, they deserve what they get.

I disagree.  I think it is most friendly to implement the function in 
the way it has been documented (even if it hasn't always been behaving 
as documented).

Duncan Murdoch

&lt;/pre&gt;</description>
    <dc:creator>Duncan Murdoch</dc:creator>
    <dc:date>2012-05-24T18:42:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31111">
    <title>Re: modifying some package code</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31111</link>
    <description>&lt;pre&gt;

I'm not sure what *is* your issue. nlms:::inner_perc_table is defined (automatically), so it just works. If you are re-using just the .C part of nlme somewhere else that you dyn-load manually then you can simply use "inner_perc_table" instead.

Cheers,
Simon



&lt;/pre&gt;</description>
    <dc:creator>Simon Urbanek</dc:creator>
    <dc:date>2012-05-24T18:14:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31110">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31110</link>
    <description>&lt;pre&gt;
If user code or packages start to depend on is.unsorted(t(DF)) it would be
harder to change, no? Why provide something that is unsuitable and allow
that possibility to happen? It's more user friendly to return "not
implemented", "unsuitable", or the nicer message already in the C code,
than leave the door open for confusion and errors. Or in other words, it's
even more user friendly to return a warning or error to the user at the
prompt, than the user friendliness of writing in the help file that it's
unsuitable for data.frame.

Matthew

&lt;/pre&gt;</description>
    <dc:creator>Matthew Dowle</dc:creator>
    <dc:date>2012-05-24T17:33:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31109">
    <title>Re: modifying some package code</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31109</link>
    <description>&lt;pre&gt;Simon,

Thank you for this valuable information.  However, you must forgive some
ignorance on my part.  If R-registerRoutines defines the native function,
how should I go about fixing this issue?  Would I copy the init.c to the
base package (where I have the new function)?

Thanks,
Charles

On Thu, May 24, 2012 at 11:58 AM, Simon Urbanek &amp;lt;simon.urbanek&amp;lt; at &amp;gt;r-project.org


[[alternative HTML version deleted]]

&lt;/pre&gt;</description>
    <dc:creator>Charles Determan Jr</dc:creator>
    <dc:date>2012-05-24T17:26:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31108">
    <title>Re: modifying some package code</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31108</link>
    <description>&lt;pre&gt;
On May 24, 2012, at 12:25 PM, Charles Determan Jr wrote:


The (unexported) object contains cached reference to the native function (see ?getNativeSymbolInfo) and is defined by R_registerRoutines in src/init.c. This is a typical optimization in R packages to avoid costly lookup of symbols and to provide check for native arguments.

Cheers,
Simon

&lt;/pre&gt;</description>
    <dc:creator>Simon Urbanek</dc:creator>
    <dc:date>2012-05-24T16:58:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31107">
    <title>modifying some package code</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31107</link>
    <description>&lt;pre&gt;Greetings,

I am working on modifying some code from the nlme package.  I have had many
discussions on the mixed models mailing list and have been directed to
simply 'hack' the source code to have the degrees of freedom generated by
one function to use in the output of another function that doesn't generate
them.  My current holdup is an error regarding a .c file called
'inner_perc_table' called by the .C function.  The error states that the
object 'inner_perc_table' is not found.  My confusion lies in the fact that
when I run the original script, it recognizes the part just fine.  At no
point is the object defined and I cannot currently find such a code in the
package's source.  Perhaps someone here is familiar with the nlme package
and could assist me in some form.  If you need further information, please
ask as I don't know if there is a general answer for this type of question
or if you will need the actual code.

Regards,
Charles

[[alternative HTML version deleted]]

&lt;/pre&gt;</description>
    <dc:creator>Charles Determan Jr</dc:creator>
    <dc:date>2012-05-24T16:25:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31106">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31106</link>
    <description>&lt;pre&gt;
I don't see why saying this function is unsuitable for dataframes 
implies that it will never be made suitable for dataframes.

The fix handles the case is.unsorted was designed for:  it checks 
whether x[1] &amp;lt; x[2] &amp;lt; x[3] etc., which it doesn't currently do properly 
for non-atomic objects.

Duncan Murdoch

&lt;/pre&gt;</description>
    <dc:creator>Duncan Murdoch</dc:creator>
    <dc:date>2012-05-24T15:25:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31105">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31105</link>
    <description>&lt;pre&gt;
But that leaves the door open to confusion later, whilst closing the door
to a better solution: making is.unsorted() work by column for data.frame;
i.e., making is.unsorted _suitable_ for data.frame. If you just do the
quick fix for .gtn result you can never go back. If making is.unsorted(DF)
work by column is too hard for now, then leaving the door open would be
better by returning the error message already in the C code: "only atomic
vectors can be tested to be sorted". That would be a better quick fix
since it leaves options for the future.


&lt;/pre&gt;</description>
    <dc:creator>Matthew Dowle</dc:creator>
    <dc:date>2012-05-24T15:10:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31104">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31104</link>
    <description>&lt;pre&gt;
Okay, I'm going to fix the handling of .gtn results, and document the 
unsuitability of this
function for dataframes and arrays.

Duncan Murdoch


&lt;/pre&gt;</description>
    <dc:creator>Duncan Murdoch</dc:creator>
    <dc:date>2012-05-24T13:57:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31103">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31103</link>
    <description>&lt;pre&gt;that's in
expectation
the .gtn

Because then is.unsorted(DF) would work, but go by row, which you guessed above 
wasn't intended and isn't sensible. But once it worked in that way, users might 
start to depend on it; e.g., by writing is.unsorted(t(DF)). If I came 
along in future and suggested that was inefficient and wouldn't it be more 
natural and efficient if is.unsorted(DF) went by column, returning the same as 
with(DF,is.unsorted(order(a,b))) but implemented efficiently, you would fear 
that user code now depended on it going by row and say it was too late. I'd 
persist and highlight that it didn't seem in keeping with the spirit of 
is.unsorted()'s speed since it short circuits on the first unsorted item, which 
is why we love it. You'd reply that's not documented. Which it isn't. And that 
would be the end of that.


&lt;/pre&gt;</description>
    <dc:creator>Matthew Dowle</dc:creator>
    <dc:date>2012-05-24T13:15:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31102">
    <title>Re: New S3 methods for optional package</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31102</link>
    <description>&lt;pre&gt;Dear Prof. Ripley,
Thanks a lot for your answers!
See inline comments below.

On 24-May-12 12:01, Prof Brian Ripley wrote:

Replacing require with requireNamespace does not seem to work for this 
case, it fails with the error:
Error: object 'estimateParameters' not found whilst loading namespace 
'intamap'
This comes from registerS3methods which cannot find the generic 
estimateParameters from parent.env of B (rtop). Is this because 
loadNamespace does not attach the namespace to the search path?


I really hoped that would not be necessary, but you are probably right 
that it is the only solution if I want to get rid of the note. The 
disadvantage is then that I have to clutter the package repository of 
CRAN with one more package, which only purpose is to load two other 
packages. For me that does not appear as a better solution than having a 
package with a note and use of a function that is not intended. But then 
I am also not sure how much extra work my current solution would give 
the CRAN-maintainers, so if you think an extra package is better I will 
follow your advice.

Thanks,
Jon

&lt;/pre&gt;</description>
    <dc:creator>Jon Olav Skoien</dc:creator>
    <dc:date>2012-05-24T13:00:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31101">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31101</link>
    <description>&lt;pre&gt;
I would guess that it was never intended to be used this way.  It is 
intended for to test x[1] &amp;lt; x[2] &amp;lt; x[3] ... for objects where this is a 
sensible calculation; it isn't really sensible for dataframes.


I don't follow the last sentence.  If the .gtn call needs to be negated, 
why would you want to go back?

Duncan Murdoch


&lt;/pre&gt;</description>
    <dc:creator>Duncan Murdoch</dc:creator>
    <dc:date>2012-05-24T12:20:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31100">
    <title>Re: Expected behaviour of is.unsorted?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31100</link>
    <description>&lt;pre&gt;
Thanks. Yes you're right. So is.unsorted() on a data.frame is trying to tell us 
if there exists any unsorted row, it seems.

  a b
1 1 1               # this row is sorted
2 3 3               # this row is sorted
3 5 5               # this row is sorted
[1] TRUE
[1] FALSE
  a b
1 1 1               # this row is sorted
2 3 2               # this row isn't sorted
3 5 5               # this row is sorted
[1] FALSE
[1] FALSE

Since it seems to have a bug anyway (and if so, can't be correct in anyone's 
use of it), could either is.unsorted on a data.frame return the error that's in 
the C code already: "only atomic vectors can be tested to be sorted", for 
safety and to lessen confusion, or be changed to return the natural expectation 
proposed above? The easiest quick fix would be to negate the result of the .gtn 
call of course, but then you could never go back.

Matthew


&lt;/pre&gt;</description>
    <dc:creator>Matthew Dowle</dc:creator>
    <dc:date>2012-05-24T11:39:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31099">
    <title>Re: Curry: proposed new functional programming, er, function.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31099</link>
    <description>&lt;pre&gt;
Hadley Wickham-2 wrote
I've been playing around with this for a while. One flaw I found - it
doesn't handle nested Curries very well (the naive implementation in
roxygen/functional does).

e.g.:

foo=function(x,y,z) x+y+z
Curry(Curry("foo",3),4)(3)
# 10

Curry(Curry(foo,3),4)(3)
# hangs

foo4=function(a,b,c,d)
Curry(Curry(Curry("foo4",3),4),1)(3)
# hangs

I was also curious if there was some trick to force a function eval when the
list of arguments got exhausted (for example, a triple Curry on foo above
would leave no arguments so would trigger eval into 10).

--
View this message in context: http://r.789695.n4.nabble.com/Curry-proposed-new-functional-programming-er-function-tp917654p4631127.html
Sent from the R devel mailing list archive at Nabble.com.

&lt;/pre&gt;</description>
    <dc:creator>Yike Lu</dc:creator>
    <dc:date>2012-05-23T19:53:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31098">
    <title>Re: New S3 methods for optional package</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31098</link>
    <description>&lt;pre&gt;
You are not supposed to be calling registerS3methods .... it is only 
visible because of the nature of the base namespace and its 
documentation says

'Not intended to be called directly.'

And require() is the wrong thing here; you want to register methods on a 
namespace.   The logic seems to be that you should do that only if A's 
namespace is already loaded, but you could load it pre-emptively with 
requireNamespace().


Most likely a call to requireNamespace() would work without any NOTE.


That will happen.  But that's the price for the convenience of binary 
packages.


I guess the problem is that you are trying to do too much with package 
rtop.  I would consider creating a separate package depending on intamap 
(and most likely rtop) which adds the S3 methods for intamap.


&lt;/pre&gt;</description>
    <dc:creator>Prof Brian Ripley</dc:creator>
    <dc:date>2012-05-24T10:01:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31097">
    <title>New S3 methods for optional package</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31097</link>
    <description>&lt;pre&gt;Hi,

I have asked this question before, but the solution I ended up with (see 
below) creates a note when running R CMD check. So I am trying again...

I am developing a package B that, among other things, also offers some 
extra S3-methods for functions in package A if the user has installed A. 
I do not want to list A under Depends of B, as the dependency list of A 
is rather long, and most potential users of B will not be interested in 
package A and what it depends on. Unfortunately I struggle with doing 
this right. After asking on the list some time ago, I have listed A 
under Suggests, and have a .onLoad function in B with
if (require(A)) registerS3methods(newMethodsMatrix, package = A, env = 
environment(B))
But starting with R 2.13 or R 2.14, R CMD check creates a note:
"Package startup functions should not change the search path.
See section 'Good practice' in ?.onAttach."
I have understood that packages with notes can be uploaded to CRAN, but 
that they tend to create extra work for the maintainers and hence I am 
trying to find another solution.

So far I have tried:
List A under Suggest of B, with a conditional import in NAMESPACE.
If I build a Windows-binary from this when A is installed, this package 
can be installed but not loaded on computers where A is not installed.

List A under Enhances of B.
This seems to be the right thing, as the R extensions manual says: "the 
'Enhances' field lists packages "enhanced" by the package at hand, e.g., 
by providing methods for classes from these packages".
However, although it seems I can install and load package B when I 
conditionally import package A in the NAMESPACE, R CMD check stops with 
the error: Namespace dependency not required: A
If I remove the import, R CMD check is happier, but I cannot load the 
package after installing.

I have read about the use of "Suggest", "Enhances" etc in "Writing R 
Extensions", but could not figure out the right way to do this. I am 
sure there is something I am missing here.

If anyone wants to check possible solutions, package A is "intamap", 
available from CRAN, whereas B is "rtop", available from Rforge: 
**|install.packages("rtop", repos="http://R-Forge.R-project.org")|**

Thanks,
Jon

&lt;/pre&gt;</description>
    <dc:creator>Jon Olav Skoien</dc:creator>
    <dc:date>2012-05-24T09:38:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31096">
    <title>Re: Capturing signals from within external libs</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31096</link>
    <description>&lt;pre&gt;Simon,

Very likely butchered my initial problem explanation. The issue is that I
make a call to a library, something like:

SEXP my_fun() {
...
CB = MyCallback("XYZ");  /* this contains callback functions that in turn
use R */
externalLibCall(CB);     /* infinite loop that won't return as it is
capturing streaming data */

/* we never get here */

Return(R_NilValue);
}

My callbacks look something like

on_event_A () {
  R_CheckUserInterrupt():
  evalRFunctionFromC();
}

But event_A only gets called when a new message arrives.  When a new
message arrives the on_event_A gets called from within the external
library code (hence calling R), but only when a message arrives.

At this point R_CheckUserInterrupt() works just fine.  The problem is when
the external process is waiting on a new message.  I have no entry to
check whether or not a message is available, nothing akin to select().
Basically I only get control in my callback when a new message happens.
So if there is no new message (in the context above it is a message/tick
from an exchange), the process spins/waits/not too sure what happens
internally, but the net result is I don't see anything.  I am waiting.  It
is at this point that I want to force an interrupt.

My current solution is just to redefine as my SIGINT handler before the
externalLibCall call, with an ungraceful exit() internal to it.  Dirty,
but lets me break. In the ideal world I would be returned to the R prompt,
but it isn't overly critical in this application since it is being run
more or less headless as is.

The other problem, which makes me cringe of course, is that this is all
further complicated by the fact that it is not just C, but C++ and running
on Win64 ;-)   I tried not to mention that of course ...

Your insights are very appreciated, and I now have further knowledge into
making this work in other applications, but my hope for this one is
dwindling.

Best,
Jeff


On 5/23/12 11:49 AM, "Simon Urbanek" &amp;lt;simon.urbanek&amp;lt; at &amp;gt;r-project.org&amp;gt; wrote:


&lt;/pre&gt;</description>
    <dc:creator>Jeffrey Ryan</dc:creator>
    <dc:date>2012-05-23T17:23:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31095">
    <title>Re: Capturing signals from within external libs</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31095</link>
    <description>&lt;pre&gt;
On May 23, 2012, at 12:40 PM, Jeffrey Ryan wrote:


Well, but in that case you already have interrupt points so I'm not sure what is the problem? I thought the whole point is that you have long processing in some 3rd party library where you can't call R API so that's why you need the hack in the first place ...



&lt;/pre&gt;</description>
    <dc:creator>Simon Urbanek</dc:creator>
    <dc:date>2012-05-23T16:49:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31094">
    <title>Re: test suites for packages</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31094</link>
    <description>&lt;pre&gt;I use svUnit, too.

I put a kind of standard skeleton into my packages that has a
packagename.unittest () function that will run all svUnit tests (if
svUnit is available). This function returns NA if svUnit is not
available, invisible (TRUE) if all tests are passed and  stops
otherwise. Which will cause R CMD check to fail.

My test directory contains one single tests.R file with the two lines:

library (packagename)
packagename.unittest ()


which gives me e.g.:

Running the tests in ‘tests/tests.R’ failed.
Last 13 lines of output:
    only logical matrix subscripts are allowed in replacement

  * :     ...) ... **ERROR**
  Error in `[&amp;lt;-.data.frame`(`*tmp*`, x.na, value = NA) :
    only logical matrix subscripts are allowed in replacement
                           kind timing                time unit msg
  test(kernelpls.fit)        OK  0.009 2012-05-23 14:38:49
  test(scale)                OK  0.009 2012-05-23 14:38:49
  test(.ldapreproc)   **ERROR**  0.007 2012-05-23 14:38:49
  test(pcalda)               OK  0.003 2012-05-23 14:38:49
  Error in errorLog(summarize = FALSE) : 0 failure(s) and 1 error(s)
  Calls: cbmodels.unittest -&amp;gt; errorLog
  Execution halted


While the 13 lines may not be enough if there are lots of tests, I can
easily run packagename.unittest () in an interactive session and start
tracking down the problem from there.


Claudia


Am 18.05.2012 17:28, schrieb Cook, Malcolm:


&lt;/pre&gt;</description>
    <dc:creator>Claudia Beleites</dc:creator>
    <dc:date>2012-05-23T16:47:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31093">
    <title>Re: Capturing signals from within external libs</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31093</link>
    <description>&lt;pre&gt;Simon,

Thanks for the clarifying example.  I fear my current set up fails the
test for 'no R calls', so I think I am stuck on the ugly variant for my
current challenge, but I will be able to use this in other places.

Thanks again,
Jeff

On 5/22/12 4:45 PM, "Simon Urbanek" &amp;lt;simon.urbanek&amp;lt; at &amp;gt;r-project.org&amp;gt; wrote:


&lt;/pre&gt;</description>
    <dc:creator>Jeffrey Ryan</dc:creator>
    <dc:date>2012-05-23T16:40:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.devel/31092">
    <title>Re: [R] how to remove the 'promise' attribute of an R object (.Random.seed)?</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.devel/31092</link>
    <description>&lt;pre&gt;I'm not persuaded at this point that we want to support use of the
lazy loading infrastructure outside the core as we might want to
change it in the future. But the principle that promises are an
internal implementation detail that should be as invisible at possible
at the user level suggest that this should be changed, so R-devel and
R-patched now force promises in this case.

There are a number of other cases in the sources that may have
similar issues. It would be good to check them over and handle any
that need handling in a systematic way. I don't have time to do that
now but I'll put it in my queue.

luke

On Wed, 23 May 2012, Yihui Xie wrote:


&lt;/pre&gt;</description>
    <dc:creator>luke-tierney&lt; at &gt;uiowa.edu</dc:creator>
    <dc:date>2012-05-23T16:22:25</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.r.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.r.devel</link>
  </textinput>
</rdf:RDF>

