Re: [Rd] S4 Generics and NAMESPACE : justified warning ?
> "YC" == Yohan Chalabi > on Thu, 3 Sep 2009 12:44:13 +0200 writes: > "MM" == Martin Maechler > on Mon, 31 Aug 2009 14:51:16 +0200 MM> Yes, I agree, unjustified in your case. The question MM> is: is there a patch which does differentiate between MM> your situation and Martin's scenario -- or does your MM> patch already do that? YC> Hi Martin, YC> Thanks for your response. YC> Here is an attempt to combine both views. YC> To check if the generic was derived from the function it YC> wants to overwrite, the following patch checks if the YC> package associated with the generic is the same as the YC> one where the function was defined. YC> regards, Yohan [.] I have now committed your proposal (+-), and also added /tests/Pkgs/ in order to allow checking such Namespace <-> S4 and other package dependencies. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
On Fri, Sep 11, 2009 at 1:48 PM, rudjer wrote:
>
> Comrades,
>
> When talk turns to the purity of the revolution, and purge of packages then
> the guillotine can't be far behind. We all remember Lenin berating the
> "renegade Kautsky" for his "pragmatism," and we know where that led...
>
> So let me put in a good word for pragmatism, and incidentally for saving one
> of my
> own packages, SparseM, and perhaps eventually my neck. Last week Kurt asked
> me to look into a SparseM licensing quirk based on an inquiry from the
> Fedora
> folks. SparseM is GPL except for one routine cholesky.f written at Oakridge
> Lab by E. Ng and B. Peyton. Our version of the code was redistributed in
> the
> package PCx which was copywrited by the U. of Chicago, who specified that
> commercial users should contact someone at Argonne National Lab. Since the
> beginning we have retained this language in the License file of SparseM,
> even
> though the code in question was not actually developed as a part of PCx.
>
> I contacted one of the original PCx developers who responded as follows:
>
> The routine you mention was distributed with PCx but not part
> of it as you see from the legalese and not covered by the PCx
> copyright. I tried to interest the authors of that code
> in legal issues in around 1997 but could not get them
> motivated (frankly I also can't get too interested).
>
> To which I heartily concurred. If someone who is worried about getting sued
> would like to dig into this can of worms, then fine. But life is too short
> for the rest of us. This is quite a murky business, we shouldn't create
> incentives to make it murkier by covering up relevant language on licensing.
> But surely we can also all agree that CRAN has been a fantastic success, and
> adding new constraints on its operation is ill-advised.
It is unfortunately common in the numerical analysis community,
especially those still using Fortran, to have a rather vague approach
to licensing. ("I'll send a copy of my code to anyone who asks for it
but put in some language that if someone is going to get fantastically
rich from it then they owe me money too") In the Open Source
community licensing is very important - it is what makes Open Source
software, including CRAN, possible. Most non-lawyers don't find the
study and discussion of licenses to be terribly fascinating but they
are the foundation of Open Source software. If the authors of Fortran
subroutines feel that it is too much of a bother to pay attention to
licenses (or to learn post-1950's programming languages) then
evolution will run its course and they will be left behind. It's
annoying in that so little software from the numerical analysis
community is covered by suitable licenses but that will change.
Tim Davis's C and C++-based sparse matrix code that is incorporated in
the Matrix package is licensed under the GPL or LGPL. Why mess around
with antiquated software and vague or non-existent licenses when there
are better alternatives? It is painful to need to recode old Fortran
routines in modern programming languages and under real licenses but
it is the only way we will ever bring numerical analysis into the
post-Beatles era.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why license filtering is important (was non-GPL ...)
Using the acronym "GPL" in comments on the management of package repositories led the discussion well away from the issues I wanted to shed light upon, so I have changed the subject tag. Examples of my concerns: 1) I use a package with a non-free component and learn how to work with it efficiently. I'm a retired academic, but still try to recover some costs of the work I do for R and other open projects by doing some contract and training work. A client has a problem and wants a solution. If there is a "non-commercial" restriction, I'm put in the awkward position of having to get a permission -- possibly from a defunct organization or one that has long forgotten how to grant such a permission. 2) There may be new tools available that ARE free software. Dirk's blacklist (perhaps we could have a less loaded name?) may suggest opportunities for gradually moving to packages that can be used without need to check license details. I have used such tasks in the past as student projects where they are relatively straightforward. 3) Many workers are not aware of the consequences of license status of their codes (I was not for some years). The development of CRAN and similar repositories has been and can be a positive force allowing for improvement and understanding of methods. 4) We definitely should retain the ability to access non-free codes -- somehow folk have misread my comments otherwise. I'll use them for learning and when there is no alternative, but if at all possible, I'll choose the free ones for production work so I don't get caught out as above. A comment: In looking at SparseM, I first used the pdf -- it simply says GPL(>=2) as the license. (I'm sure I've got similar bugs in my own docs.) I dug deeper and found the LICENSE file, and also looked at cholesky.f, which is unfortunately one of the bigger files. I was hoping it was somewhat related to work I've done over the years on Cholesky decompositions in the hope I could offer a substitute as per concern (2) above, but it is not of the same nature as the algorithms I worked on as far as I can determine. Maybe someone else is able to step in on that. And a big tip of the hat to Dirk E. and Charles B. for the cran2deb work -- I already admired the work. Now I've started looking at some of the package files for license info, I'm amazed they've got as far as they have. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DESCRIPTION/OS_type and OS X
R Extensions (Section 1.1.1, and using the 2.9.2 version) says The optional `OS_type' field specifies the OS(es) for which the package is intended. If present, it should be one of `unix' or `windows', and indicates that the package should only be installed on a platform with `.Platform$OS.type' having that value. and I am wondering if 'OS_type: unix' includes OS X or not. I am currently updating RInside which builds on the two unixy OS variants. Would I exclude OS X by picking OS_type: unix ? I don't think so but maybe this could be made more explicit in the paragraph above. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION/OS_type and OS X
On Sep 12, 2009, at 9:49 AM, Dirk Eddelbuettel wrote: R Extensions (Section 1.1.1, and using the 2.9.2 version) says The optional `OS_type' field specifies the OS(es) for which the package is intended. If present, it should be one of `unix' or `windows', and indicates that the package should only be installed on a platform with `.Platform$OS.type' having that value. and I am wondering if 'OS_type: unix' includes OS X or not. I am currently updating RInside which builds on the two unixy OS variants. Would I exclude OS X by picking OS_type: unix ? I don't think so but maybe this could be made more explicit in the paragraph above. Dirk Dirk, On OSX: > .Platform$OS.type [1] "unix" Remember that OSX is a BSD Unix derivative. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] DESCRIPTION/OS_type and OS X
On 12 September 2009 at 09:52, Marc Schwartz wrote: | On Sep 12, 2009, at 9:49 AM, Dirk Eddelbuettel wrote: | | > | > R Extensions (Section 1.1.1, and using the 2.9.2 version) says | > | > The optional `OS_type' field specifies the OS(es) for which the | > package is intended. If present, it should be one of `unix' or | > `windows', and indicates that the package should only be installed | > on a | > platform with `.Platform$OS.type' having that value. | > | > and I am wondering if 'OS_type: unix' includes OS X or not. I am | > currently | > updating RInside which builds on the two unixy OS variants. Would I | > exclude | > OS X by picking OS_type: unix ? I don't think so but maybe this | > could be | > made more explicit in the paragraph above. | > | > Dirk | | Dirk, | | On OSX: | | > .Platform$OS.type | [1] "unix" Thanks, that's exactly what I needed. Maybe one day when I grow up I can treat myself to one of these shiny computers ... | Remember that OSX is a BSD Unix derivative. "In theory, theory and practice are the same. In practice, they are not." Never hurts to double-check. Thanks again! Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Access to integer value of BUILTINSXP/SPECIALSXP
Hello, For the BUILTINSXP and SPECIALSXP types, the R Internals page documents "An integer giving the offset into the table of primitives/.Internals. " What macro gives me the value of this integer? I guess something like this would work had R_USEINTERNALS been defined v->u.primsxp.offset (where v is a SEXP of either of the above types). What is the portable version? Thank you Saptarshi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Access to integer value of BUILTINSXP/SPECIALSXP
After some reading, what i really need is something to give access to PRIMNAME(obj). Setting #define R_USEINTERNALS doesn't work and i'd rather not use internals. Is the some exposed api call to get PRIMNAME? Thank you Saptarshi On Sat, Sep 12, 2009 at 2:08 PM, Saptarshi Guha wrote: > Hello, > For the BUILTINSXP and SPECIALSXP types, the R Internals page documents > > "An integer giving the offset into the table of primitives/.Internals. " > > What macro gives me the value of this integer? I guess something like this > would work > had R_USEINTERNALS been defined > v->u.primsxp.offset > (where v is a SEXP of either of the above types). > > What is the portable version? > > Thank you > Saptarshi > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
