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, there
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
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 ye
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
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. T
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 function
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. Unfortun
On Fri, Apr 24, 2009 at 6:48 PM, 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
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
On Thu, Apr 23, 2009 at 8:54 PM, Ted Harding
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 placed on distirbution fo
>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 throug
On Fri, Apr 24, 2009 at 11:44 AM, Ben Goodrich 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 work in
>> pro
On Fri, Apr 24, 2009 at 5:11 PM, Andrew Piskorski 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 programming, a
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 claim
On 24 April 2009 at 10:18, Kjetil Halvorsen wrote:
| On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich wrote:
|
| > Dirk Eddelbuettel debian.org> writes:
| > > As a non-exhautive list with possible misclassifications, cran2deb
| > currently
| > > has these packasges as 'maybe not free' and does not
> Kjetil Halvorsen writes:
> On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich wrote:
>> Dirk Eddelbuettel 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 Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich wrote:
> Dirk Eddelbuettel 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:
> >
> > BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTA
> Ben Goodrich writes:
> Gabor Grothendieck wrote:
>> On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich
>> wrote:
>>> Dirk Eddelbuettel debian.org> writes:
As a non-exhautive list with possible misclassifications, cran2deb
currently
has these packasges as 'maybe not free' and do
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
> (o
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:
http://cran
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
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 Sc
> "MM" == Martin Maechler
> on Thu, 23 Apr 2009 12:40:22 +0200 (CEST) writes:
> "vQ" == Wacek Kusnierczyk
> on Thu, 23 Apr 2009 11:49:54 +0200 writes:
vQ> maech...@stat.math.ethz.ch wrote:
>>>
vQ> sprintf has a documented limit on strings included in the out
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:
http://cran.at.r-project.org/bin/windows/base/CHANGES
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 re
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 c
26 matches
Mail list logo
