On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote:
> Dear R developers,
>
> I am seeking advice on some $subject matter.
>
> My package will have an update soon, that is not backward compatible
> with the current version. It will likely break much of the existing
> code. Many (~50) packages dep
Sorry - not iplot, but igraph.
On Thu, Oct 20, 2011 at 9:21 AM, Rainer M Krug wrote:
>
>
> On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi wrote:
>
>> Dear R developers,
>>
>> I am seeking advice on some $subject matter.
>>
>> My package will have an update soon, that is not backward compatible
>
On Thu, 20 Oct 2011, Rainer M Krug wrote:
On Wed, Oct 19, 2011 at 8:05 PM, G?bor Cs?rdi wrote:
Dear R developers,
I am seeking advice on some $subject matter.
If this is intended to be a CRAN update, then really you need to ask
the CRAN crew about the possible implications (and I've sent
Thanks for the insight!
It is indeed true that naming the new version 'igraph1' (this is a
better name for the change it introduces), is optimal for the existing
packages.
I was a bit reluctant to do this, because of two reasons. First,
igraph exists as a Python package, and a C library as well,
> My package will have an update soon, that is not backward compatible
> with the current version. It will likely break much of the existing
> code. Many (~50) packages depend on 'igraph' and they, too, will most
> probably break with the new version.
>
> My intended solution is, that I create a s
On 11-10-20 10:56 AM, Hadley Wickham wrote:
My package will have an update soon, that is not backward compatible
with the current version. It will likely break much of the existing
code. Many (~50) packages depend on 'igraph' and they, too, will most
probably break with the new version.
My inte
> We did have an attempt at that for some versions, but I don't think it ever
> achieved all of its goals, and we've dropped it.
Yes, I remembered it used to be possible to do versioned installs, but
I don't think you could ever have them loaded simultaneously.
> I'm not sure it would be "optimal
On Thu, 20 Oct 2011, Hadley Wickham wrote:
The optimal solution would be if R packages could depend on a specific
version of a package, and a user could have multiple packages
You used to be able to have a versioned install of a package, and then
load a particular version. Not sure when it wa
On 20.10.2011 18:25, Geoff Jentry wrote:
On Thu, 20 Oct 2011, Hadley Wickham wrote:
The optimal solution would be if R packages could depend on a specific
version of a package, and a user could have multiple packages
You used to be able to have a versioned install of a package, and then
load
Dear All,
I am a beginner creating R packages. I followed the Leisch (2009) tutorial
and the document “Writing R Extensions” to write an example.
I installed R 2.12.2 (I also tried R2.13.2), the last version of Rtools and
the recommended packages in a PC with Windows 7 Home Premium.
I can run
That. Cygwin warning is expected on Windows. You can still build the package
and it should be fine, although it looks like the documentation may need a bit
of tweaking to pass R CMD check. 2.13.2 is the latest version of R, and I
would recommend using it over 2.12.2. Both for the improvements
On 20/10/2011 3:06 PM, Joshua Wiley wrote:
That Cygwin warning is expected on Windows.
It can be suppressed by setting an environment variable named CYGWIN
with value nodosfilewarning, e.g. by doing this at the command line:
SET CYGWIN=nodosfilewarning
Duncan Murdoch
You can still build
`$` and `[` are primitives while `[.data.frame` is a longish R function
that does all sorts of clever things.
On 19/10/11 22:34, Stavros Macrakis wrote:
I was surprised to find that df$a[1] is an order of magnitude faster than
df[1,"a"]:
df<- data.frame(a=1:10)
system.time(replicate(10, d
On Wed, Oct 19, 2011 at 2:34 PM, Stavros Macrakis wrote:
> I was surprised to find that df$a[1] is an order of magnitude faster than
> df[1,"a"]:
Yes. This treats a data frame as a list, and is much faster.
> I thought this might be because df[,] builds a data frame before simplifying
> it to a
14 matches
Mail list logo