@Konrad, you're right, that's exactly what I'm looking for. That's
great stuff. Thanks! (And thanks also to Gabor Grothendieck, who
suggested modules to me way back.)
On Tue, Oct 4, 2016 at 7:07 AM, Konrad Rudolph
wrote:
> Check out ‹klmr/modules› on Github (distinct from CRAN’s ‹modules›!).
Shower thoughts:
Are you digging for something like what you'd use with a CI/CD pipeline?
e.g. - building a workflow that pulls a tag from a couple of code
repositories, checks them out into a workspace, installs prereqs, and then
runs your code/tasks in a repeatable fashion?
I'm not aware of a
Check out ‹klmr/modules› on Github (distinct from CRAN’s ‹modules›!). It
looks pretty much exactly like what you want:
https://github.com/klmr/modules
It has an extensive README and vignette explaining the usage.
Cheers,
Konrad
--
Konrad Rudolph
On Sun, 2 Oct 2016 at 18:31 Kynn Jones wrote:
Martin, thanks for that example. It's definitely eye-opening, and
very good to know.
The installation business, however, is still a killer for me. Of
course, it's a trivial step in a simple example like the one you
showed. But consider this scenario: suppose I perform an analysis
that I may pu
On 10/03/2016 01:51 PM, Kynn Jones wrote:
Thank you all for your comments and suggestions.
@Frederik, my reason for mucking with environments is that I want to
minimize the number of names that import adds to my current
environment. For instance, if module foo defines a function bar, I
want my
Kynn,
You appear confused by the meaning of the word "optional".
All the things I listed for packages are additional features you _may_ use,
not onces that are imposed on you so that they _must_ be used.
Lastly, I forgot to mention NAMESPACE support. Which gives pretty much
exactly what you ou
Thank you all for your comments and suggestions.
@Frederik, my reason for mucking with environments is that I want to
minimize the number of names that import adds to my current
environment. For instance, if module foo defines a function bar, I
want my client code to look like this:
import("fo
On Mon, Oct 3, 2016 at 10:18 AM, wrote:
> Hi Kynn,
>
> Thanks for expanding.
>
> I wrote a function like yours when I first started using R. It's
> basically the same up to your "new.env()" line, I don't do anything
> with environmentns. I just called my function "mysource" and it's
> essentially
Have a look at the CRAN modules package and the import package.
On Sun, Oct 2, 2016 at 1:29 PM, Kynn Jones wrote:
> I'm looking for a way to approximate the "zero-overhead" model of code
> reuse available in languages like Python, Perl, etc.
>
> I've described this idea in more detail, and the mo
Hi Kynn,
Thanks for expanding.
I wrote a function like yours when I first started using R. It's
basically the same up to your "new.env()" line, I don't do anything
with environmentns. I just called my function "mysource" and it's
essentially a "source with path". That allows me to find code I reu
Kynn,
How much homework have you done researching any other "alternatives" to the
package system? I know of at least one...
In short, just about everybody here believes in packages. And repositories.
And package management. And version control (at the package level). And
maybe byte compilation
On Sun, Oct 2, 2016 at 8:01 PM, Kynn Jones wrote:
> Hi Frederick,
>
> I described what I meant in the post I sent to R-help
> (https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html),
> but in brief, by "zero overhead" I mean that the only thing needed for
> library code to be accessible
Hi Frederick,
I described what I meant in the post I sent to R-help
(https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html),
but in brief, by "zero overhead" I mean that the only thing needed for
library code to be accessible to client code is for it to be located
in designed directory.
Hi Kynn,
Do you mind defining the term "zero-overhead model of code reuse"?
I think I understand what you're getting at, but not sure.
Thank you,
Frederick
On Sun, Oct 02, 2016 at 01:29:52PM -0400, Kynn Jones wrote:
> I'm looking for a way to approximate the "zero-overhead" model of code
> reu
I'm looking for a way to approximate the "zero-overhead" model of code
reuse available in languages like Python, Perl, etc.
I've described this idea in more detail, and the motivation for this
question in an earlier post to R-help
(https://stat.ethz.ch/pipermail/r-help/2016-September/442174.html).
15 matches
Mail list logo
