Full_Name: Francisco J. Zagmutt
Version: 2.9.0
OS: XP pro, SP2
Submission from: (NULL) (98.245.159.214)
- Description: memory.limit(x) will yield an error even though the memory
allocation limit is changed to x (when possible). The same call does not yield
an error in R version 2.8.x
- Example
MM == Martin Maechler maech...@stat.math.ethz.ch
on Thu, 23 Apr 2009 12:40:22 +0200 (CEST) writes:
vQ == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no
on Thu, 23 Apr 2009 11:49:54 +0200 writes:
vQ maech...@stat.math.ethz.ch wrote:
vQ sprintf has a documented
Thanks, we know from other messages and this has been files as a bug
report minutes ago...
Best wishes,
Uwe Ligges
Pfaff, Bernhard Dr. wrote:
Dear list subscriber (R-Core),
there is a minor typo in the Windows specific NEWS for R 2.9.0:
Dear list subscriber (R-Core),
there is a minor typo in the Windows specific NEWS for R 2.9.0:
http://cran.at.r-project.org/bin/windows/base/CHANGES.R-2.9.0
There is no function 'memory.limits() but memory.limit() (see below).
Secondly, I am kind of irritated by the function's behaviour. It
On Apr 23, 2009, at 6:21 PM, Stavros Macrakis wrote:
I said:
...The GPL FAQs are the FSF's interpretation. The R Foundation is
not
obliged to have the same interpretation, and of course the FSF
cannot
enforce licenses given by the R Foundation
On Thu, Apr 23, 2009 at 5:34 PM, Marc
Hi,
I found the init.c file I did not see before.
m - expand.grid( x = 1:20, y = 1:20, z = 1:20 )
d - dist( m )
system.time( out - as.matrix( d ) )
user system elapsed
3.006 1.252 4.429
old.as.matrix.dist - function(x, ...)
+ {
+ size - attr(x, Size)
+ df - matrix(0, size,
On 24/04/2009 5:33 AM, Uwe Ligges wrote:
Thanks, we know from other messages and this has been files as a bug
report minutes ago...
Best wishes,
Uwe Ligges
Pfaff, Bernhard Dr. wrote:
Dear list subscriber (R-Core),
there is a minor typo in the Windows specific NEWS for R 2.9.0:
maech...@stat.math.ethz.ch wrote:
vQ sprintf has a documented limit on strings included in the output
using the
vQ format '%s'. It appears that there is a limit on the length of
strings included
vQ with, e.g., the format '%d' beyond which surprising things happen
(output
Ben Goodrich writes:
Gabor Grothendieck wrote:
On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich goodr...@fas.harvard.edu
wrote:
Dirk Eddelbuettel edd at debian.org writes:
As a non-exhautive list with possible misclassifications, cran2deb
currently
has these packasges as 'maybe not free'
On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich goodr...@fas.harvard.eduwrote:
Dirk Eddelbuettel edd at debian.org writes:
As a non-exhautive list with possible misclassifications, cran2deb
currently
has these packasges as 'maybe not free' and does not build them:
Kjetil Halvorsen writes:
On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich goodr...@fas.harvard.eduwrote:
Dirk Eddelbuettel edd at debian.org writes:
As a non-exhautive list with possible misclassifications, cran2deb
currently
has these packasges as 'maybe not free' and does not build them:
On 24 April 2009 at 10:18, Kjetil Halvorsen wrote:
| On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich goodr...@fas.harvard.eduwrote:
|
| Dirk Eddelbuettel edd at debian.org writes:
| As a non-exhautive list with possible misclassifications, cran2deb
| currently
| has these packasges as 'maybe
On Thu, Apr 23, 2009 at 03:21:45PM -0700, Ian Fellows wrote:
Assuming that the foundation does not want to deviate from the FSF
interpretation, there would still be value in clarifying its position
vis-?-vis how the license applies to R specifically.
For example the FSF foundation claims
On Fri, Apr 24, 2009 at 5:11 PM, Andrew Piskorski a...@piskorski.com wrote:
On Thu, Apr 23, 2009 at 03:21:45PM -0700, Ian Fellows wrote:
[...]
IMO, that's nuts, there is no such thing as linking to a library in
an interpreted environment. Linking is a well understood operation
in computer
On Fri, Apr 24, 2009 at 11:44 AM, Ben Goodrich goodr...@fas.harvard.edu wrote:
Kurt Hornik wrote:
AGPL, unfortunately, allows supplements, and hence cannot fully be
standardized. We've been thinking about extending the current scheme to
indicate a base license plus supplements, but this is
Still, if they have code that is compiled and linked to R at running
time, then that code must be under the GPL. Again, this is the FSF
?interpretation and certainly not R-core's, not even mine.
[...]
Well, not quite. R.h RDefines.h and RInternals.h are LGPL, so as long as the
hooks go through
On Thu, Apr 23, 2009 at 8:54 PM, Ted Harding
ted.hard...@manchester.ac.uk wrote:
...However, if that commercial interpreter also had a 'compile' option,
and I compiled my progrtam using that, then equally I feel sure
that the compiled version would be subject to whatever restrictions
had been
Ian Fellows wrote:
Still, if they have code that is compiled and linked to R at running
time, then that code must be under the GPL. Again, this is the FSF
?interpretation and certainly not R-core's, not even mine.
[...]
Well, not quite. R.h RDefines.h and RInternals.h are LGPL, so as long
On Fri, Apr 24, 2009 at 6:48 PM, Ian Fellows ifell...@ucsd.edu wrote:
Still, if they have code that is compiled and linked to R at running
time, then that code must be under the GPL. Again, this is the FSF
?interpretation and certainly not R-core's, not even mine.
[...]
Well, not quite. R.h
I am having a problem using two DLLs with the same name, but obviously
located in different directories, in an R session. The troublesome
package is the (Bioconductor) Rgraphviz package. It relies on (3rd party
software) graphviz and imports functions from (Bioconductor) package
graph.
On Fri, 24 Apr 2009, Patrick Aboyoun wrote:
I am having a problem using two DLLs with the same name, but obviously
located in different directories, in an R session. The troublesome package is
the (Bioconductor) Rgraphviz package. It relies on (3rd party software)
graphviz and imports
Thanks Brian. I'll stop trying to hack the code to work and opt for the
dll rename option.
Patrick
Prof Brian Ripley wrote:
On Fri, 24 Apr 2009, Patrick Aboyoun wrote:
I am having a problem using two DLLs with the same name, but
obviously located in different directories, in an R session.
Kurt Hornik wrote:
AGPL, unfortunately, allows supplements, and hence cannot fully be
standardized. We've been thinking about extending the current scheme to
indicate a base license plus supplements, but this is still work in
progress.
This would be helpful. I would just reemphasize that a
Howdy all...
Reading with interest the thread(s) about REvolution, package
licensing and the requirements of the GPL.
First of all, let me introduce myself . I joined REvolution Computing
in February, after working for nearly 4 years for Intel as an open
source strategist and before that for 6
Hi all,
I think for the common licences, we should also add BSD licence... for
example my pkg randtoolbox (which is currently with incompatible
licences) will probably be in a near future with the BSD licence.
Anyway I like the idea of two different repositories for GPL like
licensed pkg
I don't have a strong opinion about partitioning the repository, but I
don't think partitioning based on whether the license is commonly used
for R packages is terribly helpful. AGPL and AGPL + GPL3 are not common
licensing schemes for R packages currently, but from the perspective of
a useR,
26 matches
Mail list logo
