tweag / HaskellR

The full power of R in Haskell.
https://tweag.github.io/HaskellR
Other
585 stars 47 forks source link

Cannot built inline-r-0.10.5 with latest R version 4.2.0 #374

Closed bezirg closed 2 years ago

bezirg commented 2 years ago

Using R 4.1.3 i can cabal build inline-r-0.10.5.

Using latest R 4.2.0 (that also is on stable ArchLinux), I get on cabal build inline-r-0.10.5:

Configuring library for inline-r-0.10.5..
Preprocessing library for inline-r-0.10.5..
compiling dist/build/Foreign/R/Internal_hsc_make.c failed (exit code 1)
rsp file was: "dist/build/Foreign/R/hsc2hscall26684-0.rsp"
command was: /usr/bin/gcc -c dist/build/Foreign/R/Internal_hsc_make.c -o dist/build/Foreign/R/Internal_hsc_make.o -fuse-ld=gold -D__GLASGOW_HASKELL__=810 -Dlinux_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Icbits -I/usr/include/R/ -Idist/build/cbits -I/usr/include/R/ -Idist/build/autogen -Idist/build/global-autogen -include dist/build/autogen/cabal_macros.h -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/process-1.6.13.2/include -I/home/mpla/.cabal/store/ghc-8.10.7/vector-0.12.3.1-5288858e421932da699ccb45be171a38682f0167fd3ea1835346124255781dd2/lib//include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/unix-2.7.2.2/include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/time-1.9.3/include -I/home/mpla/.cabal/store/ghc-8.10.7/primitive-0.7.3.0-ca993c0684c5b48074dd2590184c6f06667d73290dfde50301aed62da070af56/lib//include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/bytestring-0.10.12.0/include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/base-4.14.3.0/include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/integer-gmp-1.0.3.0/include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/include -I/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/include/
error: In file included from /usr/include/strings.h:23,
                 from /usr/include/string.h:462,
                 from /usr/include/R/R_ext/RS.h:34,
                 from /usr/include/R/R.h:80,
                 from Internal.hsc:46:
Internal.hsc: In function ‘main’:
Internal.hsc:142:15: error: unknown type name ‘SEXPREC’
Internal.hsc:142:5: note: in expansion of macro ‘hsc_poke’
Internal.hsc:146:15: error: unknown type name ‘SEXPREC’
Internal.hsc:146:5: note: in expansion of macro ‘hsc_poke’
Internal.hsc:150:15: error: unknown type name ‘SEXPREC’
Internal.hsc:150:5: note: in expansion of macro ‘hsc_poke’
Internal.hsc:195:15: error: unknown type name ‘VECTOR_SEXPREC’
Internal.hsc:195:5: note: in expansion of macro ‘hsc_peek’
In file included from dist/build/Foreign/R/Internal_hsc_make.c:1:
Internal.hsc:199:15: error: ‘SEXPREC_ALIGN’ undeclared (first use in this function)
/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/template-hsc.h:96:39: note: in definition of macro ‘hsc_size’
   96 |     hsc_printf("(%ld)", (long) sizeof(t));
      |                                       ^
Internal.hsc:199:15: note: each undeclared identifier is reported only once for each function it appears in
/home/mpla/.ghcup/ghc/8.10.7/lib/ghc-8.10.7/template-hsc.h:96:39: note: in definition of macro ‘hsc_size’
   96 |     hsc_printf("(%ld)", (long) sizeof(t));
      |                                       ^

I am not sure if this is a bug of this Haskell library, a bug from the Archlinux packaging side, or a bug from the upstream R dev side.

facundominguez commented 2 years ago

Hello @bezirg. Thanks for reporting this.

Since the error is complaining about a missing C type SEXPREC, perhaps the change of R versions requires modifying the includes in Internal.hsc. https://github.com/tweag/HaskellR/blob/afac2e6279cee422d2112c2c5a31d9a35ff54302/inline-r/src/Foreign/R/Internal.hsc#L45-L48

If it amounts to that, it could be a matter of conditionally adjusting the includes when R is at a newer version.

idontgetoutmuch commented 2 years ago

I also have this problem :-(

nevrome commented 2 years ago

I also ran into that. R 4.2.1 on Ubuntu 18.04.6.

erikd commented 2 years ago

Just hit this in Debian Testing (R 4.2.1).

angerman commented 2 years ago

After looking at this a bit more in detail. I'm afraid it won't be as easy as re-ordering headers.

Note that the internal structure of the SEXPREC is not made available to R Extensions: rather SEXP is an opaque pointer, and the internals can only be accessed by the functions provided.

https://cran.r-project.org/doc/manuals/r-release/R-ints.html

The internals are just not exported anymore. And while we could just use SET_TAG, SETCDR, SETCAR, and LENGTH; I've no idea how to deal with the ALIGN hack...

-- | Extract the data pointer from a vector.
unsafeSEXPToVectorPtr :: SEXP s a -> Ptr ()
unsafeSEXPToVectorPtr s = (unsexp s) `plusPtr` #{size SEXPREC_ALIGN}

-- | Inverse of 'vectorPtr'.
unsafeVectorPtrToSEXP :: Ptr a -> SomeSEXP s
unsafeVectorPtrToSEXP s = SomeSEXP $ sexp $ s `plusPtr` (- #{size SEXPREC_ALIGN})

For unsafeSEXPToVectorPtr, there is STDVEC_DATAPTR; but for the inverse unsafeVectorPtrToSEXP, I fail to find a suitable fix.

As unsafeVectorPtrToSEXP is not used internally, I'm tempted to suggest it being removed.

This of course only makes Internal.hsc work. HExp.hsc is a whole another issue. The reliance on peek and poke with internal types poses a major headache there.

angerman commented 2 years ago

After looking some more at this, this will get really complicated. The part of missing_r that seems to hook into the GC... I have no idea how to fix that up. For the rest of HExp.hsc there is a set of accessors that can be used for most of the peek calls. Poke is much harder, as I wasn't able to find the corresponding setters for all the fields we use.

size and alightment for the storage instance will also need some hard thinking to get right :-/

angerman commented 2 years ago

At this point, it's easier for me to just fix an older R version than try to make this compatible with 4.2

idontgetoutmuch commented 2 years ago

@angerman thanks for looking at this

mboes commented 2 years ago

379 has a proposed fix, along the lines explored by @angerman above: removal of the GC-related functions, removal of pokeHExp, etc. Turns out that the getter functions are enough, because we usually construct R values through quasiquotation and evaluation, and only really need to inspect them from Haskell, not construct them.