On 14.10.2011 18:52, Jari Oksanen wrote:
On 14/10/11 19:00 PM, "Uwe Ligges"<lig...@statistik.tu-dortmund.de> wrote:
On 14.10.2011 16:15, Duncan Murdoch wrote:
On 14/10/2011 10:10 AM, Jari Oksanen wrote:
On 14/10/11 16:26 PM, "Duncan Murdoch"<murdoch.dun...@gmail.com> wrote:
On 14/10/2011 9:18 AM, Jari Oksanen wrote:
Uwe& others,
This is OK if you want to identify the cause of the problems. However,
the basic problem was that checking required something that is not
required: there was one example that was not run, and one case
where the
loading of the package was not necessary (if(require(<package>))).
I do
believe that handling this kind of cases is difficult in automatic
checking. However, I think they need not be checked: there should be a
new case of package reference in addition to 'depends', 'suggests' and
'enhances' -- something like 'benefitsfrom'.
Users use those declarations when they ask to install dependencies. If
you don't declare a dependence on a contributed package, users will
have
to manually install it.
Howdy,
This is a pretty weak argument in this particular case: 'parallel' is
not a
contributed package so that you cannot install it. You either have it
or you
don't have it. In latter case, nothing happens, but everything works like
usual. In the former case, you may have some new things.
(Having 'parallel' as a contributed package for R< 2.14.0 would be a
great
idea but not something I dare to suggest.)
This is now actual to me, since I'm adding 'parallel' support to my
package, but there seems to be no clean way of doing this with the
current checking procedures. I use the 'parallel' support only if the
package is available (in R>= 2.14.0, not yet released), and there are
multiple cores.
Temporarily maintain two releases of your package: one for R< 2.14.0
that doesn't mention parallel, and one for R>= 2.14.0 that does. The
second one should declare its dependence on R>= 2.14.0. If support for
parallel is your only change, you don't need to do anything for the
previous one: CRAN will not replace it in the 2.13.x repository if the
new one needs a newer R.
Forking my package was indeed one of the three alternatives I have
considered. In this case forking sounds really weird: for R< 2.13.0 both
forks would work identically. The only difference being how they are
handled
by R checkers.
I don't see why it's weird to require that a version that uses a
facility that is in 2.14.0 but no earlier versions should have to
declare that. Sure, you can put all sorts of conditional tests into your
code so that it avoids using the new facility in older versions, but
isn't it simpler to just declare the dependency and avoid cluttering
your code with those tests?
Indeed, I think you should update your package and declare the
dependency on R>= 2.14.0. This seems to be a cleanest possible
approach. Distributing a contributed parallel package without
functionality for R< 2.14.0 is not, why should anybody develop code for
R versions that won't be supported any more in due course?
Here one reason: Our PC labs have now R version 2.12.something and it is not
in my power to upgrade R,but that depends on the will of our computing
centre.
So other people from the administration tell you which software to use
for teaching? And what happens if they tell you only Excel is available?
... weird ...
If it will upgraded, it will not be 2.14.something. A simple desire
to be able to use the package in the environment were I work sounds a valid
personal reason.
You can still use the old version there, if the new version depends on R
>= 2.14.0. The old version will stay in the binary repositories for old
versions of R and in the package archives of the source repository as
well. I think Duncan explained that already.
A second point is that the package would not *depend* or anything on R>=
2.14.0.
But it depends on it: it won't pass the checks for R < 2.14.0.
It could be faster in some cases, but not in all. It would just as
legitimate to have a condition, that the package cannot be used by those
poor sods who don't have but one processor (and I was one just a short time
ago).
Indeed, this is exactly the same condition: you *must* have a hardware
I want you to have, and the version of R I want to have. I won't make that
requirement.
Why is the hardware relevant to use the parallel (or your) package? You
can also use it with one cpu.
Best,
Uwe
Like I wrote in my previous message, I had considered three choices. One was
forking, another was delaying the release of these features till 2.14.* is
old, and the third was to depend on 'snow' *and* 'multicore' instead of
'paralle'. Now the second choice sounds the best.
Cheers, Jari Oksanen
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
