Metodo suggerito per estrarre una libreria C standalone da un pacchetto R esistente?

Question

Metodo suggerito per estrarre una libreria C standalone da un pacchetto R esistente?

#1 da (2 voti)

8

Il mio gruppo ha sviluppato un pacchetto R per simulare la crescita delle piante (vedi repository GitHub ). Il pacchetto R utilizza .Call per interfacciare con C.

Abbiamo deciso che sarebbe valso la pena creare una libreria C standalone. I due motivi principali sono 1) utilizzare strumenti di debug di C familiari e 2) gran parte della comunità di sviluppatori / utenti ha familiarità con i linguaggi compilati (per lo più i modelli nella classe sono scritti in C o Fortran). Tuttavia, il pacchetto R è accessibile a molti al di fuori di questa comunità, quindi vogliamo mantenere la sua funzionalità.

Ho esaminato alcune domande correlate, ad es. link , che discute i pacchetti R con le dipendenze della libreria C, ma non ne ha trovato uno che si occupa specificamente del disaccoppiamento di un pacchetto R esistente.

Un approccio proposto

(cosa abbiamo inventato finora ... un uomo di paglia)

Scrivi test per la funzionalità esistente
mantieni la libreria C all'interno della cartella src/
Inserisci il codice C specifico per R (ad esempio SEXP , caricando le librerie R, ecc.) nei file 'R wrapper' anteposto a R_*
crea funzioni separate per leggere i file di configurazione in C
crea una funzione C "principale" per sostituire la funzionalità in R
scrive un makefile per la libreria C che ignora i file wrapper R
Una volta che la libreria C funziona in modo indipendente e in modo equivalente al pacchetto R, potremmo considerare di spostare le funzioni C in un repository separato, che sarebbe una dipendenza per il pacchetto R

Domande:

Questo sforzo è fuorviato?
Stiamo trascurando qualsiasi potenziale insidia?
C'è un modo migliore per sviluppare sia le librerie R che C in parallelo?
Ci sono esempi di librerie C che sono state disaccoppiate dai pacchetti R?
Come possiamo scrivere test per confrontare funzioni equivalenti in R e C?

testing design refactoring c r

posta David LeBauer 25.06.2014 - 22:46

fonte

1 risposta

Leggi altre domande sui tag testing design refactoring c r

come implementare le chiamate al servizio web idempotente Qual è la differenza tra "kk" e "HH" +1 in ISO-8601?

score 2 · Accepted Answer

In generale, questa è una buona idea e molti pacchetti lo fanno. Puoi dare un'occhiata a RSQLite per l'ispirazione - impacchettano sqlite e includi solo alcune funzioni wrapper. Simile a rhdf5 e hdf5

Per quanto riguarda i tuoi punti:

Write tests for existing functionality

Sempre una buona idea!

Keep the C library inside the src/ folder

Sì - oppure potresti considerare inst/include se hai mai seguito il percorso "solo header", a la Rcpp

Place R-specific C code (e.g. SEXP, loading R libraries, etc) into 'R wrapper' files prepended with R_*

Sembra abbastanza ragionevole.

Create separate functions for reading configuration files in C

Non sei proprio sicuro di cosa intendi qui.

Create a 'main' C function to replace functionality in R

Questo mi sembra strano. Perché hai bisogno di un main - non stai semplicemente sviluppando una libreria di funzioni chiamabili? Sia R la tua main :)

Write a makefile for the C library that ignores R wrapper files

Sì, probabilmente avrai bisogno di un Makefile più coinvolto per gestirlo - suggerisco nuovamente di guardare il codice sorgente per RSQLite, e anche R-exts potrebbe essere utile.

Once the C library works independently and equivalently to the R package, we could consider moving the C functions to a separate repository, that would be a dependency for the R package

Sì, sembra ragionevole - far sì che il pacchetto R recuperi il codice sorgente C come necessario quando si costruisce / sviluppa il pacchetto. In questo modo possono essere efficacemente disaccoppiati.