Re: r-mathjaxr

[Guillaume Le Vaillant]

Ricardo Wurmus  skribis:

> Ricardo Wurmus  writes:
>
>> unfortunately I had to revert commits
>> 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 (Add r-mathjaxr) and
>> 00056eafaefed0af8535f219760fbbe01dd6f240 (updating r-metafor).
> […]
>> The good news is that we can soon build a
>> slightly degraded version of mathjaxr completely from source.
>
> I have restored the commits, changing r-mathjaxr to use the files we’ve
> built in the js-mathjax-for-r-mathjaxr package.
>
> I decided not to delete the a11y directory from r-mathjaxr (which we
> couldn’t build in js-mathjax-for-r-mathjaxr), because these files are
> not minified and rather short, so it doesn’t hurt to keep them.

Ok. Thanks for fixing it.


signature.asc
Description: PGP signature

Re: r-mathjaxr

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> unfortunately I had to revert commits
> 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 (Add r-mathjaxr) and
> 00056eafaefed0af8535f219760fbbe01dd6f240 (updating r-metafor).
[…]
> The good news is that we can soon build a
> slightly degraded version of mathjaxr completely from source.

I have restored the commits, changing r-mathjaxr to use the files we’ve
built in the js-mathjax-for-r-mathjaxr package.

I decided not to delete the a11y directory from r-mathjaxr (which we
couldn’t build in js-mathjax-for-r-mathjaxr), because these files are
not minified and rather short, so it doesn’t hurt to keep them.

-- 
Ricardo

Re: R

[Ben Woodcroft]

On 08/09/16 23:02, Ricardo Wurmus wrote:

Ben Woodcroft  writes:


Hi,

I thought I'd respond to this old thread now that the openblas eigen
error seems to be fixed. I'm interested in using openblas so that the
(as yet not in master) WGCNA package works faster, among other things:

https://labs.genetics.ucla.edu/horvath/CoexpressionNetwork/Rpackages/WGCNA/faq.html


On 06/02/16 08:24, Andreas Enge wrote:

On Fri, Feb 05, 2016 at 09:48:24PM +0100, Ricardo Wurmus wrote:

I would suggest to drop “--with-lapack”, too.  (I haven’t found the time
to try building without this flag just now.)  The manual says:
I don’t remember why I added it in the first place, so I think it’s best
to drop it, considering that the manual tells us only to do it if we
know what we want to achieve by adding it.

I did, and it still builds on arm.

Shall I push the attached patch to core-updates? I tested it on x86_64.
Or, would you mind testing it on arm please Andreas?

The patch looks fine to me and I’m generally in favour of adding
OpenBLAS to R.

I should note that the R admin manual[1] says that the correct configure
flag for OpenBLAS is

 --with-blas="-lopenblas"

I’m not sure if this makes a difference.


Thanks. I changed it to that minus the double quotes, and updated to 
3.3.1, then pushed to core-updated. We'll see how things go.

ta

Re: R

[Pjotr Prins]

OpenBLAS works fine for me - hit the same issue with Python before.

Pj.

On Thu, Sep 08, 2016 at 09:41:59PM +1000, Ben Woodcroft wrote:
> Hi,
> 
> I thought I'd respond to this old thread now that the openblas eigen
> error seems to be fixed. I'm interested in using openblas so that
> the (as yet not in master) WGCNA package works faster, among other
> things:
> 
> https://labs.genetics.ucla.edu/horvath/CoexpressionNetwork/Rpackages/WGCNA/faq.html
> 
> 
> On 06/02/16 08:24, Andreas Enge wrote:
> >On Fri, Feb 05, 2016 at 09:48:24PM +0100, Ricardo Wurmus wrote:
> >>I would suggest to drop “--with-lapack”, too.  (I haven’t found the time
> >>to try building without this flag just now.)  The manual says:
> >>I don’t remember why I added it in the first place, so I think it’s best
> >>to drop it, considering that the manual tells us only to do it if we
> >>know what we want to achieve by adding it.
> >I did, and it still builds on arm.
> 
> Shall I push the attached patch to core-updates? I tested it on
> x86_64. Or, would you mind testing it on arm please Andreas?
> 
> Thanks,
> ben

> From 012c013661c739b8d90be8bcbfce13349dcaee89 Mon Sep 17 00:00:00 2001
> From: Ben J Woodcroft 
> Date: Thu, 8 Sep 2016 21:14:12 +1000
> Subject: [PATCH] gnu: r: Add openblas input.
> 
> * gnu/packages/statistics.scm (r)[inputs]: Add openblas.
> [arguments]: Adapt configure flags.
> ---
>  gnu/packages/statistics.scm | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
> index 990f2fc..e34bcec 100644
> --- a/gnu/packages/statistics.scm
> +++ b/gnu/packages/statistics.scm
> @@ -136,6 +136,7 @@ be output in text, PostScript, PDF or HTML.")
>(lambda _ (zero? (system* "make" "install-info")
> #:configure-flags
> '("--with-cairo"
> + "--with-blas=openblas"
>   "--with-libpng"
>   "--with-jpeglib"
>   "--with-libtiff"
> @@ -170,6 +171,7 @@ be output in text, PostScript, PDF or HTML.")
> ("pango" ,pango)
> ("curl" ,curl)
> ("tzdata" ,tzdata)
> +   ("openblas" ,openblas)
> ("gfortran" ,gfortran)
> ("icu4c" ,icu4c)
> ("libjpeg" ,libjpeg)
> -- 
> 2.9.2
> 


-- 

Re: R

[Ricardo Wurmus]

Ben Woodcroft  writes:

> Hi,
>
> I thought I'd respond to this old thread now that the openblas eigen 
> error seems to be fixed. I'm interested in using openblas so that the 
> (as yet not in master) WGCNA package works faster, among other things:
>
> https://labs.genetics.ucla.edu/horvath/CoexpressionNetwork/Rpackages/WGCNA/faq.html
>
>
> On 06/02/16 08:24, Andreas Enge wrote:
>> On Fri, Feb 05, 2016 at 09:48:24PM +0100, Ricardo Wurmus wrote:
>>> I would suggest to drop “--with-lapack”, too.  (I haven’t found the time
>>> to try building without this flag just now.)  The manual says:
>>> I don’t remember why I added it in the first place, so I think it’s best
>>> to drop it, considering that the manual tells us only to do it if we
>>> know what we want to achieve by adding it.
>> I did, and it still builds on arm.
>
> Shall I push the attached patch to core-updates? I tested it on x86_64. 
> Or, would you mind testing it on arm please Andreas?

The patch looks fine to me and I’m generally in favour of adding
OpenBLAS to R.  

I should note that the R admin manual[1] says that the correct configure
flag for OpenBLAS is

--with-blas="-lopenblas"

I’m not sure if this makes a difference.

~~ Ricardo


[1]: 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Goto-and-OpenBLAS

Re: R

[Ben Woodcroft]

Hi,

I thought I'd respond to this old thread now that the openblas eigen 
error seems to be fixed. I'm interested in using openblas so that the 
(as yet not in master) WGCNA package works faster, among other things:


https://labs.genetics.ucla.edu/horvath/CoexpressionNetwork/Rpackages/WGCNA/faq.html


On 06/02/16 08:24, Andreas Enge wrote:

On Fri, Feb 05, 2016 at 09:48:24PM +0100, Ricardo Wurmus wrote:

I would suggest to drop “--with-lapack”, too.  (I haven’t found the time
to try building without this flag just now.)  The manual says:
I don’t remember why I added it in the first place, so I think it’s best
to drop it, considering that the manual tells us only to do it if we
know what we want to achieve by adding it.

I did, and it still builds on arm.


Shall I push the attached patch to core-updates? I tested it on x86_64. 
Or, would you mind testing it on arm please Andreas?


Thanks,
ben
>From 012c013661c739b8d90be8bcbfce13349dcaee89 Mon Sep 17 00:00:00 2001
From: Ben J Woodcroft 
Date: Thu, 8 Sep 2016 21:14:12 +1000
Subject: [PATCH] gnu: r: Add openblas input.

* gnu/packages/statistics.scm (r)[inputs]: Add openblas.
[arguments]: Adapt configure flags.
---
 gnu/packages/statistics.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/statistics.scm b/gnu/packages/statistics.scm
index 990f2fc..e34bcec 100644
--- a/gnu/packages/statistics.scm
+++ b/gnu/packages/statistics.scm
@@ -136,6 +136,7 @@ be output in text, PostScript, PDF or HTML.")
   (lambda _ (zero? (system* "make" "install-info")
#:configure-flags
'("--with-cairo"
+ "--with-blas=openblas"
  "--with-libpng"
  "--with-jpeglib"
  "--with-libtiff"
@@ -170,6 +171,7 @@ be output in text, PostScript, PDF or HTML.")
("pango" ,pango)
("curl" ,curl)
("tzdata" ,tzdata)
+   ("openblas" ,openblas)
("gfortran" ,gfortran)
("icu4c" ,icu4c)
("libjpeg" ,libjpeg)
-- 
2.9.2

Re: R packages do not show up as requisites

[Pjotr Prins]

On Sat, Mar 05, 2016 at 12:30:06AM +0100, Ludovic Courtès wrote:
> Pjotr Prins  skribis:
> 
> > Funny thing,
> >
> >   guix gc -R path
> >
> > on a package that has python modules and R packages as inputs only the
> > python inputs show up. Try for example r-munsell which has
> > r-colorspace as an input:
> >
> >   ./pre-inst-env guix package -i r-munsell
> >
> >r-munsell0.4.2 → 0.4.2 
> > /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
> >
> >   ./pre-inst-env guix gc -R 
> > /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
> >
> > Niente, nop, nada. 
> 
> That’s because r-munsell does not explicitly refer to r-colorspace.
> Instead, r-colorspace is a propagated input of r-munsell, and propagated
> inputs are something taken into account when building the profile (see
> the ‘manifest’ file in there), but not other at the lower levels.

It is funny how my misconceptions trip me up :). I thought inputs were
treated as dependencies. So, if I were to write a package I would have
to include r-colorspace both as an input AND a propagated input? From
your description that won't help (I actually tried, it does not)
because there are no *explicit* links inside the package. 

It is very interesting and relevant to Ruby and R packages because
they don't use the full store paths explicitly. I need to check how
python does include them (they appear to work), maybe Ricardo was
thinking about that too in the earlier discussions on builds.

It also explains why they did not show up in the generated SVG graphs.

You see, I noted these things, but it did not register as a problem
until I tried to archive :)

> > My problem is now that 'guix archive' won't include R modules because
> > they are not listed as requisites.
> >
> > Is there an easy fix?
> 
> You could do, say:
> 
>   guix package -i r-munsell -p foo
>   guix archive --export $(readlink foo) > t.nar
> 
> HTH!

Yes, that will help.

Pj.

Re: R packages do not show up as requisites

[Ludovic Courtès]

Pjotr Prins  skribis:

> Funny thing,
>
>   guix gc -R path
>
> on a package that has python modules and R packages as inputs only the
> python inputs show up. Try for example r-munsell which has
> r-colorspace as an input:
>
>   ./pre-inst-env guix package -i r-munsell
>
>r-munsell0.4.2 → 0.4.2 
> /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
>
>   ./pre-inst-env guix gc -R 
> /gnu/store/kwhzqrpcm8agl8q2v9n19rss060xs2j4-r-munsell-0.4.2
>
> Niente, nop, nada. 

That’s because r-munsell does not explicitly refer to r-colorspace.
Instead, r-colorspace is a propagated input of r-munsell, and propagated
inputs are something taken into account when building the profile (see
the ‘manifest’ file in there), but not other at the lower levels.

> My problem is now that 'guix archive' won't include R modules because
> they are not listed as requisites.
>
> Is there an easy fix?

You could do, say:

  guix package -i r-munsell -p foo
  guix archive --export $(readlink foo) > t.nar

HTH!

Ludo’.

Re: R

[Andreas Enge]

On Fri, Feb 05, 2016 at 09:48:24PM +0100, Ricardo Wurmus wrote:
> I would suggest to drop “--with-lapack”, too.  (I haven’t found the time
> to try building without this flag just now.)  The manual says:
> I don’t remember why I added it in the first place, so I think it’s best
> to drop it, considering that the manual tells us only to do it if we
> know what we want to achieve by adding it.

I did, and it still builds on arm.

Andreas

Re: R

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> There’s a separate section for OpenBLAS, which also mentions that using
> a “shared BLAS” is a preferred alternative to linking with a particular
> BLAS implementation.  We already pass “--enable-BLAS-shlib”, so we
> actually do use a shared BLAS, IIUC.
>
> I guess we could drop the “--with-blas” flag and see if that helps.  I
> remember struggling with this a lot in the past.  I’ll try building R
> again without that flag and see if it still works.

I dropped the flag and noticed that OpenBLAS is not mentioned at all (it
does retain a reference, but that’s expected when “openblas” is among
the inputs), so I also dropped “openblas” from the inputs and R built
just fine.

It’s a bit sad to me that we won’t be able to just use this BLAS
implementation, but if it fixes the build on ARM and MIPS I’m all for
it.

I can also confirm that dropping openblas from the R build “fixes” the
segfault when running

x <- eigen(crossprod(matrix(rnorm(50 * 500), 50, 500)))

as reported here: https://github.com/xianyi/OpenBLAS/issues/703

So, I think it’s a good idea to build R without OpenBLAS on all
architectures for now.

~~ Ricardo

Re: R

[Kyle Meyer]

Ricardo Wurmus  writes:

[...]

> I can also confirm that dropping openblas from the R build “fixes” the
> segfault when running
>
> x <- eigen(crossprod(matrix(rnorm(50 * 500), 50, 500)))
>
> as reported here: https://github.com/xianyi/OpenBLAS/issues/703
>
> So, I think it’s a good idea to build R without OpenBLAS on all
> architectures for now.

Thank you, Ricardo.  I'm sorry I wasn't able make any progress on
figuring out what the underlying issue was there.

-- 
Kyle

Re: R

[Andreas Enge]

On Fri, Feb 05, 2016 at 06:17:04PM +0100, Ricardo Wurmus wrote:
> I dropped the flag and noticed that OpenBLAS is not mentioned at all (it
> does retain a reference, but that’s expected when “openblas” is among
> the inputs), so I also dropped “openblas” from the inputs and R built
> just fine.

Okay. I am giving it a try on arm right now. It looks like we should
then also drop "--with-lapack"; the documentation states that this has only
an effect when "--with-blas" is also given:
   https://cran.r-project.org/doc/manuals/r-release/R-admin.html#LAPACK

If compilation succeeds on arm now, I will see whether a reference to lapack
is retained or not.

Andreas

Re: R

[Ricardo Wurmus]

Andreas Enge  writes:

> On Fri, Feb 05, 2016 at 08:02:36PM +0100, Andreas Enge wrote:
>> Okay. I am giving it a try on arm right now. It looks like we should
>> then also drop "--with-lapack"; the documentation states that this has only
>> an effect when "--with-blas" is also given:
>>https://cran.r-project.org/doc/manuals/r-release/R-admin.html#LAPACK
>> 
>> If compilation succeeds on arm now, I will see whether a reference to lapack
>> is retained or not.
>
> Well, compilation succeeded! We will see whether this will also be the
> case on mips.
>
> And there is still a reference to lapack, so I am not touching the
> "--with-lapack" configure flag for now.

I would suggest to drop “--with-lapack”, too.  (I haven’t found the time
to try building without this flag just now.)  The manual says:

“However, the likely performance gains are thought to be small (and
may be negative), and the default is not to search for a suitable
LAPACK library, and this is definitely not recommended.

[...]

Please do bear in mind that using --with-lapack is ‘definitely not
recommended’: it is provided only because it is necessary on some
platforms and because some users want to experiment with claimed
performance improvements. Reporting problems where it is used
unnecessarily will simply irritate the R helpers.”

I don’t remember why I added it in the first place, so I think it’s best
to drop it, considering that the manual tells us only to do it if we
know what we want to achieve by adding it.

~~ Ricardo

Re: R

[Andreas Enge]

On Fri, Feb 05, 2016 at 08:02:36PM +0100, Andreas Enge wrote:
> Okay. I am giving it a try on arm right now. It looks like we should
> then also drop "--with-lapack"; the documentation states that this has only
> an effect when "--with-blas" is also given:
>https://cran.r-project.org/doc/manuals/r-release/R-admin.html#LAPACK
> 
> If compilation succeeds on arm now, I will see whether a reference to lapack
> is retained or not.

Well, compilation succeeded! We will see whether this will also be the
case on mips.

And there is still a reference to lapack, so I am not touching the
"--with-lapack" configure flag for now.

Thanks a lot for your help!

Andreas

Re: R

[Pjotr Prins]

On Fri, Feb 05, 2016 at 11:00:40AM +0100, Andreas Enge wrote:
> I did get a reply, but not using R, I do not quite know what to make of it:
>https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16697

Anyone here programming in R?

> It would be nice if someone using R could help me out; if you send me an
> ssh key, I could give you access to an arm machine.
> 
> To start, a probably simple question: Why do we use "--with-blas=openblas"?

openblas is fast.

http://blog.nguyenvq.com/blog/2014/11/10/optimized-r-and-python-standard-blas-vs-atlas-vs-openblas-vs-mkl/

Re: R

[Ricardo Wurmus]

Andreas Enge  writes:

> I did get a reply, but not using R, I do not quite know what to make of it:
>https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16697
> It would be nice if someone using R could help me out; if you send me an
> ssh key, I could give you access to an arm machine.
>
> To start, a probably simple question: Why do we use "--with-blas=openblas"?

I did this when we switched from ATLAS to OpenBLAS (for substitutability
reasons).  It is possible I have misunderstood the meaning of this
configure flag.

Here’s the installation manual on building with a specific BLAS
implementation:

https://cran.r-project.org/doc/manuals/r-release/R-admin.html#BLAS

According to this section,

“R can make use of enhanced BLAS (Basic Linear Algebra Subprograms,
http://www.netlib.org/blas/faq.html) routines. However, these have
to be explicitly requested at configure time: R provides an internal
BLAS which is well-tested and will be adequate for most uses of R.”

There’s a separate section for OpenBLAS, which also mentions that using
a “shared BLAS” is a preferred alternative to linking with a particular
BLAS implementation.  We already pass “--enable-BLAS-shlib”, so we
actually do use a shared BLAS, IIUC.

I guess we could drop the “--with-blas” flag and see if that helps.  I
remember struggling with this a lot in the past.  I’ll try building R
again without that flag and see if it still works.

I’m sorry if that’s what’s responsible for the failures, but it’s pretty
hard for me to understand how linking with a high-performance BLAS
implementation could have caused these build/test failures on other
platforms.  I’ll report back when I have a successful build or an
interesting failure to share.

~~ Ricardo

Re: R and R modules (and a Ruby twist)

[Ricardo Wurmus]

Pjotr Prins  writes:

> On Thu, Sep 24, 2015 at 11:40:57AM +0200, Ricardo Wurmus wrote:
>> Maybe it would be best to append the R version to the site-library
>> directory.  I don’t think we should go further than that and bring in
>> the Guix hash, because I’m willing to trust that packages built with
>> version 3.2.2 are compatible with R 3.2.2, even if the inputs to our R
>> package changed and thus the hash is different.
>
> The exception I can think of is when R provides compile time switches
> for blas or ssl (for example). We don't do that now (Nix does!), but
> if you had two R's with the same version number, it could just be that
> a module 'lifts' that dependency and strictly works with one R (and
> not the other).

Isn’t that expected, though?  That’s a property of the used version of
R, then, not a problem with the package.

> It is the same for Ruby, Perl, Python, Apache, Firefox, etc. Anything
> that allows for building 'site' modules.

I don’t disagree in general.  There may be cases where the variant of
the build-time dependency must be identical to that used at runtime.
But I don’t think this is true for more than a few special packages.
Take R as an example.  Most packages are written in pure R, and thus
only depend on features provided by R.  What features are provided by
the language depends only on the version, not on configure flags.

If a user builds a variant of R that lacks Cairo, for example, then
certain packages won’t work as intended.  But does this mean that we
need to disallow installing packages that would have reduced feature
sets for a mutilated version of R in that case?

> I know this is mostly theoretical at this stage, but why not encourage
> strict isolation of interpreter+modules? That is the only way we'll
> guarantee independence between graphs. Nix/Guix does such a great job
> there, and now we allow interpreters to 'leak' their environments,
> just because of their convention and our trust in things that ought to
> work. And all it costs us is a partial SHA added to the path. So for
> Ruby it would be
>
>   ~/.guix-profile/lib/ruby/2.2.0-edb92950/
>
> instead of
>
>   ~/.guix-profile/lib/ruby/2.2.0/
>
> Personally I can live with the status quo, but somehow I prefer the
> exact isolation. Maybe it will come when someone gets hurt.

For R, Perl, Ruby and Python we are often forced to propagate inputs, so
that they end up in the profile and can be loaded by looking up the path
to the union in some environment variable, such as R_LIBS_SITE,
GEM_HOME, or PYTHONPATH.  These environment variables do not make a
distinction between versions or variants.  (Only Perl allows for a
distinction between major versions by having the major version number as
part of its environment variable: PERL5LIB.)

How would a *user* make sure to use different sets of packages with
different variants of languages?  At the moment, the only way is to
manually set the environment variable to point to the desired path.

With propagated inputs we cannot achieve as much isolation as we would
like to.  There might be a way to actually patch the mechanisms that
these languages use to load additional libraries/packages, patching them
such that they load dependencies by full path rather than by simple
name, similar to how we patch ‘dlopen()’ calls in C programmes.

Only if we can avoid using these inflexible environment variables can we
achieve the kind of isolation you try to get by adding a partial hash to
the output directory.

Just a data point: last time I checked Ruby’s “require” directive allows
for a full path to be given instead of a simple string.  Might there be
a way to forego propagating inputs by patching all “require $string”
statements in Ruby sources in a build phase, much like we automatically
patch shebangs?

To note: this would make it impossible for users to override
libraries/modules by adding an alternative directory containing a
modified version of a module to the list of search paths in the
consulted environment variable.  That’s akin to disabling the
LD_LIBRARY_PATH feature in C programmes.

~~ Ricardo

Re: R and R modules (and a Ruby twist)

[Ricardo Wurmus]

Pjotr Prins  writes:

> When we add an R module, such as R-qtl, the R-build-system does not
> provide R itself as a propagated input, i.e., the R interpreter is not
> in the profile. In the R world this is kinda odd.  Almost all modules
> used from R. I.e. start up R and
>
>   library(qtl)
>   do something with R/qtl
>
> Would have use people use that module in interactive mode. In the
> current package install R is not included as a symlink and needs to be
> separately installed.

Correct.  I didn’t think of it as a problem as I assumed people would
have R installed in their profile if they wanted to interactively use an
R package.  But now that you mention it, I think it might lead to
problems (see below).

> It is one other thing I am trying to think through. With a standard R
> distribution, every package is strictly aligned with the interpreter
> (they get installed from inside R).
>
> With Guix' rolling model of package updates modules may go out of sync
> - even if they are correctly linked with an underlying R. So mixing
> interpreters and modules/packages may potentially give problems. 

Users can have any number of “libraries” (directories containing
installed R packages) in R_LIBS_SITE.  Currently, our R package suggests
R_LIBS_SITE to be set to “$profile/site-library” and the r-build-system
installs packages to “$out/site-library”.

We could add a level for the R version, e.g. “$out/site-library/3.2.2/”,
but it should be noted that R_LIBS_SITE makes no distinction for
different versions of R.  It’s just a single list of directories.  I
don’t know what would happen if you had

R_LIBS_SITE=$HOME/site-library/3.2.2:$HOME/site-library/3.1.3

and then ran one or the other version of R.  (Note that currently there
can only be one version of R in a single profile anyway.)

I guess the problem is with updates.  If you had R 3.1.3 in your profile
and installed a new R package that is then built with the latest version
of R (3.2.2), this might lead to problems actually using the package in
an R session using version 3.1.3.

Maybe it would be best to append the R version to the site-library
directory.  I don’t think we should go further than that and bring in
the Guix hash, because I’m willing to trust that packages built with
version 3.2.2 are compatible with R 3.2.2, even if the inputs to our R
package changed and thus the hash is different.

~~ Ricardo

Re: R and R modules (and a Ruby twist)

[Pjotr Prins]

On Thu, Sep 24, 2015 at 11:40:57AM +0200, Ricardo Wurmus wrote:
> Maybe it would be best to append the R version to the site-library
> directory.  I don’t think we should go further than that and bring in
> the Guix hash, because I’m willing to trust that packages built with
> version 3.2.2 are compatible with R 3.2.2, even if the inputs to our R
> package changed and thus the hash is different.

The exception I can think of is when R provides compile time switches
for blas or ssl (for example). We don't do that now (Nix does!), but
if you had two R's with the same version number, it could just be that
a module 'lifts' that dependency and strictly works with one R (and
not the other).

It is the same for Ruby, Perl, Python, Apache, Firefox, etc. Anything
that allows for building 'site' modules.

I know this is mostly theoretical at this stage, but why not encourage
strict isolation of interpreter+modules? That is the only way we'll
guarantee independence between graphs. Nix/Guix does such a great job
there, and now we allow interpreters to 'leak' their environments,
just because of their convention and our trust in things that ought to
work. And all it costs us is a partial SHA added to the path. So for
Ruby it would be

  ~/.guix-profile/lib/ruby/2.2.0-edb92950/

instead of

  ~/.guix-profile/lib/ruby/2.2.0/

Personally I can live with the status quo, but somehow I prefer the
exact isolation. Maybe it will come when someone gets hurt.

Pj.
 

Re: R dependencies

[Vicente Vera]

Hello again,

Finally solved this:

Error in grid.Call.graphics(L_text, as.graphicsAnnot(x$label), x$x, x$y,  :
X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 2 at size
11 could not be loaded

The problem arose because R wasn't using cairo for font rendering.
Some simple configurations in ~/.Rprofile solved it:

setHook(packageEvent("grDevices", "onLoad"),
function(...) grDevices::X11.options(type = "cairo",
 antialias = "subpixel"))

The code changes the X11 device (used for plotting) type from "XLib"
to "cairo", once it gets called.

(just for the record, i'm not using GuixSD)

2015-09-03 11:55 GMT-03:00 Vicente Vera :
> Hi,
>
> Sure. The error message is this:
>
> X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 5 at size
> 15 could not be loaded
>
> No plot is being drawn; only a blank window appears.
>
> The code:
>
> ggplot(data = fig1, aes(x = Var1, y = Freq, fill =
> brewer.pal(length(levels(the_data$VARIABLE1)), "Set3"))) +
> geom_bar(stat = "identity") +
> scale_fill_identity() +
> labs(x = "x", y = "y") +
> geom_text(aes(label = perc), vjust = 2, size = 4, colour =
> "black", fontface = "bold") +
> scale_x_discrete(labels = c("a", "b", "c")) +
> theme(panel.background = element_blank(),
>   line = element_blank(),
>   axis.text.y = element_blank())
>
> On my base system, R 3.2.1 + ggplot2 draws the plot with no problem.
>
> It might be related to a missing font or font alias in the Guix store
> (not familiar enough with it to catch the issue).
>
> Now, I didn't installed ggplot2 through Guix, so that could be a problem.
>
> 2015-09-03 3:29 GMT-03:00 Ricardo Wurmus :
>> Hi Vicente,
>>
>>> Going back to the R dependencies topic, I ran across an issue when
>>> trying to draw a plot (with ggplot2). But first some context:
>>>
>>> - I'm not using GuixSD but a binary installation over Manjaro OpenRC;
>>> several base packages missing on Guix
>>> - I only have other two Guix packages installed: xpdf & abbaye
>>
>> All Guix packages capture the complete graph of dependencies, so you’ll
>> always end up with the dependent packages in ‘/gnu/store’ even if only
>> those packages appear in your profile that have been explicitly
>> installed.
>>
>>> - I installed ggplot2 through install.packages("ggplot2") in R (Guix 
>>> package)
>>
>> Note that ggplot2 has been packaged for Guix:
>>
>> guix package -i r-ggplot2
>>
>>> R complained about some fonts missing, but I think it could be related
>>> to a missing X11 dependency (complete Xorg maybe?). What could it be?
>>
>> What is the exact error message you get?  Is any plot drawn at all?
>> What is the code you use to draw the plot?
>>
>> ~~ Ricardo
>>

Re: R dependencies

[Vicente Vera]

Hi,

Sure. The error message is this:

X11 font -adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*, face 5 at size
15 could not be loaded

No plot is being drawn; only a blank window appears.

The code:

ggplot(data = fig1, aes(x = Var1, y = Freq, fill =
brewer.pal(length(levels(the_data$VARIABLE1)), "Set3"))) +
geom_bar(stat = "identity") +
scale_fill_identity() +
labs(x = "x", y = "y") +
geom_text(aes(label = perc), vjust = 2, size = 4, colour =
"black", fontface = "bold") +
scale_x_discrete(labels = c("a", "b", "c")) +
theme(panel.background = element_blank(),
  line = element_blank(),
  axis.text.y = element_blank())

On my base system, R 3.2.1 + ggplot2 draws the plot with no problem.

It might be related to a missing font or font alias in the Guix store
(not familiar enough with it to catch the issue).

Now, I didn't installed ggplot2 through Guix, so that could be a problem.

2015-09-03 3:29 GMT-03:00 Ricardo Wurmus :
> Hi Vicente,
>
>> Going back to the R dependencies topic, I ran across an issue when
>> trying to draw a plot (with ggplot2). But first some context:
>>
>> - I'm not using GuixSD but a binary installation over Manjaro OpenRC;
>> several base packages missing on Guix
>> - I only have other two Guix packages installed: xpdf & abbaye
>
> All Guix packages capture the complete graph of dependencies, so you’ll
> always end up with the dependent packages in ‘/gnu/store’ even if only
> those packages appear in your profile that have been explicitly
> installed.
>
>> - I installed ggplot2 through install.packages("ggplot2") in R (Guix package)
>
> Note that ggplot2 has been packaged for Guix:
>
> guix package -i r-ggplot2
>
>> R complained about some fonts missing, but I think it could be related
>> to a missing X11 dependency (complete Xorg maybe?). What could it be?
>
> What is the exact error message you get?  Is any plot drawn at all?
> What is the code you use to draw the plot?
>
> ~~ Ricardo
>

Re: R dependencies

[Vicente Vera]

Hello,

Going back to the R dependencies topic, I ran across an issue when
trying to draw a plot (with ggplot2). But first some context:

- I'm not using GuixSD but a binary installation over Manjaro OpenRC;
several base packages missing on Guix
- I only have other two Guix packages installed: xpdf & abbaye
- I installed ggplot2 through install.packages("ggplot2") in R (Guix package)

R complained about some fonts missing, but I think it could be related
to a missing X11 dependency (complete Xorg maybe?). What could it be?

2015-09-02 10:09 GMT-03:00 Ludovic Courtès :
> Ricardo Wurmus  skribis:
>
>> An alternative is to inherit from the “r” package in “statistics.scm”.
>>
>> (define-module (my own packages)
>>   #:use-module (guix packages)
>>   #:use-module (gnu packages statistics)
>>   #:use-module (srfi srfi-1))
>>
>> (define-public my-r
>>   (package (inherit r)
>> (name "my-r")
>> ;; modify only the inputs here
>> (native-inputs (alist-delete "texlive" (package-native-inputs r)))
>> (inputs (alist-delete "icedtea6" (package-inputs r)
>
> Speaking of which: should we get rid of icedtea6:jdk in the default R
> package (closure size: 1 GiB), and maybe of TeX Live (4 GiB)?  Or should
> we provide, say, ‘r-light’ with the definition above?
>
> I’m afraid having these two dependencies by default makes it
> prohibitively expensive.
>
> Ludo’.