Re: [Rd] Dialect for shell scripts

[Iñaki Úcar]

For what it's worth, Autoconf does not assume that arithmetic
expansion will be available. Instead, it emits the following shell
code:

if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then
  eval 'func_arith ()
  {
func_arith_result=$(( $* ))
  }'
else
  func_arith ()
  {
func_arith_result=`expr "$@"`
  }
fi

2017-12-17 23:55 GMT+01:00 Rodrigo Tobar :
> Dear all,
>
> During a recent package submission, we were highlighted that some lines in
> our configure script didn't follow the correct syntax. The lines looked like
> this:
>
> x=$(($y/10))
>
> We were indicated at the time that this is because the statement does not
> use Bourne shell syntax, which is absolutely true, and also that the manual
> warns about this, which is true again. So far everything is clear.
>
> However, what confuses me is that even when the manual says that "you can
> include an executable (Bourne) shell script configure in your package" [1],
> the associated footnote says something slightly different: "The script
> should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes even
> further, and links to the POSIX specification of the Shell Command Language
> [3] (as published by The Open Group), which explicitly includes arithmetic
> expressions like the one above in its syntax [4].
>
> My question then is: what exact dialect should be considered? Given that the
> statement above does not work in the Bourne shell, I conclude that the
> Bourne shell is not POSIX-compliant. That in turn would make the manual
> ambiguous as to the precise dialect that should be used by our configure
> scripts, and either the shells used by R should be changed to be
> POSIX-compliants, or the manual edited to be more precise regarding .
>
> Many thanks.
>
> Rodrigo
>
> [1]
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
> [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25
> [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
> [4]
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Rcpp - Linking to DLL from another package?

[Stravs, Michael]

Hi,

I am trying to make a package B that extends another package A. Package A uses 
Rcpp, and I want to extend a class X used there.

So package A has

src/X.h and inst/include/X.h
class X
{ ... }

src/X.cpp
X::X( arguments )
{ ... }

My package B wants to do this:

DESCRIPTION
[...]
LinkingTo: Rcpp, RcppArmadillo, A
Imports: Rcpp, RcppArmadillo, A

src/Y.h
class Y: public X
{ ... }

src/Y.cpp

Y::Y( arguments ): X(arguments)
{ ... }

Can I somehow make the package link to the library A.dll or its corresponding 
Linux equivalent? (Note: the files in inst/include will already be a pull 
request from me to the package A author, so a limited pull request for more 
changes is feasible, but I would like to keep it minimal.


Dr. Michael Stravs
Eawag
Umweltchemie
BU E 23
�berlandstrasse 133
8600 D�bendorf
+41 58 765 6742


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rcpp - Linking to DLL from another package?

[Dirk Eddelbuettel]

(Moderately wrong list: r-package-devel for packaging questions, rcpp-devel
for Rcpp questions)

On 18 December 2017 at 13:24, Stravs, Michael wrote:
| I am trying to make a package B that extends another package A. Package A 
uses Rcpp, and I want to extend a class X used there.

It doesn't really matter (for the issue at hand) if you use Rcpp or not -- R
only offers us C interfaces so C interfaces are all we got. And they don't
know classes.

I worked through that in some of my packages. See eg RcppXts which "extends"
in your sense xts by allowing C++ level access from another package. The one
key aspect is that _everything you want to call from B must be explicitly
exported by A_.  See Writing R Extensions for details.

If you could rewrite your class A to be header-only then you could just
include it via LinkingTo. But that is a different story.

In short, "No Free Lunch" and no automagic mechanisms.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rcpp - Linking to DLL from another package?

[Jeroen Ooms]

On Mon, Dec 18, 2017 at 2:40 PM, Dirk Eddelbuettel  wrote:
>
> (Moderately wrong list: r-package-devel for packaging questions, rcpp-devel
> for Rcpp questions)
>
> On 18 December 2017 at 13:24, Stravs, Michael wrote:
> | I am trying to make a package B that extends another package A. Package A 
> uses Rcpp, and I want to extend a class X used there.

Another, perhaps simpler example is the xslt package which is an
extension for the xml2 package. The xml2 package exposes its object
types (via ./inst/include/xml2_types.h) so that the xslt package get
to the underlying libxml2 objects.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rcpp - Linking to DLL from another package?

[Dirk Eddelbuettel]

On 18 December 2017 at 16:10, Jeroen Ooms wrote:
| On Mon, Dec 18, 2017 at 2:40 PM, Dirk Eddelbuettel  wrote:
| >
| > (Moderately wrong list: r-package-devel for packaging questions, rcpp-devel
| > for Rcpp questions)
| >
| > On 18 December 2017 at 13:24, Stravs, Michael wrote:
| > | I am trying to make a package B that extends another package A. Package A 
uses Rcpp, and I want to extend a class X used there.
| 
| Another, perhaps simpler example is the xslt package which is an
| extension for the xml2 package. The xml2 package exposes its object
| types (via ./inst/include/xml2_types.h) so that the xslt package get
| to the underlying libxml2 objects.

That is nice too, but doesn't in your case the object code comes from the
external libxml2 only?

Michael wanted to get at code from another R package, and those shared
libraries from R packages are not system-wide visible. Hence the problem.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dialect for shell scripts

[Kurt Hornik]

> Iñaki Úcar writes:

Same from here: in addition to what the standards say, it always pays to
be defensive and check "Portable Shell Programming" in the Autoconf
manual.  Among other things, this says

'$((EXPRESSION))'
 Arithmetic expansion is not portable as some shells (most notably
 Solaris 10 '/bin/sh') don't support it.

motivating the code shown below.  Perhaps simplest to always use expr.

-k


> For what it's worth, Autoconf does not assume that arithmetic
> expansion will be available. Instead, it emits the following shell
> code:

> if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then
>   eval 'func_arith ()
>   {
> func_arith_result=$(( $* ))
>   }'
> else
>   func_arith ()
>   {
> func_arith_result=`expr "$@"`
>   }
> fi

> 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar :
>> Dear all,
>> 
>> During a recent package submission, we were highlighted that some lines in
>> our configure script didn't follow the correct syntax. The lines looked like
>> this:
>> 
>> x=$(($y/10))
>> 
>> We were indicated at the time that this is because the statement does not
>> use Bourne shell syntax, which is absolutely true, and also that the manual
>> warns about this, which is true again. So far everything is clear.
>> 
>> However, what confuses me is that even when the manual says that "you can
>> include an executable (Bourne) shell script configure in your package" [1],
>> the associated footnote says something slightly different: "The script
>> should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes even
>> further, and links to the POSIX specification of the Shell Command Language
>> [3] (as published by The Open Group), which explicitly includes arithmetic
>> expressions like the one above in its syntax [4].
>> 
>> My question then is: what exact dialect should be considered? Given that the
>> statement above does not work in the Bourne shell, I conclude that the
>> Bourne shell is not POSIX-compliant. That in turn would make the manual
>> ambiguous as to the precise dialect that should be used by our configure
>> scripts, and either the shells used by R should be changed to be
>> POSIX-compliants, or the manual edited to be more precise regarding .
>> 
>> Many thanks.
>> 
>> Rodrigo
>> 
>> [1]
>> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
>> [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25
>> [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
>> [4]
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



> -- 
> Iñaki Úcar
> http://www.enchufa2.es
> @Enchufa2

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Region subtag in package 'Language' field

[Kurt Hornik]

> Jeroen Ooms writes:

All standard (not private use or grandfathered) IETF language tags
should be fine.  What WRE says about ISO-639 codes is meant to explain
the language subtags.

Hth
-k

> I am looking for the appropriate field to let package authors to
> declare the pkg documentation language for spell checkers. The most
> important case is to specify a preference between "en-US" or "en-GB"
> which can be used by the hunspell or spelling pkg to select the
> appropriate dictionary.

> WRE defines the "Language" field for documentation language, but from
> the current description it seems restricted to 2 or 3 letter ISO-639
> codes such as "en" or "eng". WRE also mentions rfc-5646, which refers
> to ISO 3166-1 for region/country subtags but it is unclear if these
> are allowed in the field?

> Spell checking libraries (e.g. myspell/hunspell) typically use
> locale-like language names to identify the appropriate dictionary such
> as "en_GB" or "de_AT", see for example [1,2]. Merely specifying "en"
> or "de" is ambiguous to the spell checker. I was wondering if the WRE
> definition of the "Language" field could allow for this?



> [1] https://apps.fedoraproject.org/packages/hunspell-en/contents/
> [2] https://packages.debian.org/stretch/hunspell-en-gb

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Fixed BLAS tests for external BLAS library

[Simon Guest]

We build R with dynamically linked BLAS and LAPACK libraries, in order
to use the AMD Core Math Library (ACML) multi-threaded implementation
of these routines on our 64 core servers.  This is great, and our
users really appreciate it.

However, when building like this, make check fails on the reg-BLAS.R
test.  The reason for this is that the expected test output is checked
using identical.  By changing all uses of identical in this file to
all.equal, the tests pass.

Specifically, I run this command before make check:

$ sed -i -e 's/identical/all.equal/g' tests/reg-BLAS.R

I suggest that the test is fixed like this in the R source code.

Here is the configure command I use, on CentOS 7:
$ ./configure --with-system-zlib --with-system-bzlib --with-system-pcre \
--with-blas \
--with-lapack \
--with-tcl-config=/usr/lib64/tclConfig.sh \
--with-tk-config=/usr/lib64/tkConfig.sh \
--enable-R-shlib \
--enable-prebuilt-html

cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Collaborative Wiki for fostering Open Innovation in R

[Juan Telleria]

I have found Apache JSPWiki solution, which might work and is open source:
https://jspwiki.apache.org

In addition, I will test xwiki, and give my insights about the tool on
r-devel, as it might just be a resolutive tool for collaboration thanks to
it's extensible architecture.

Kind regards,
Juan Telleria

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dialect for shell scripts

[Paul McQuesten]

I do not have a dog in this fight, but I have to ask:
How much person time is worthwhile to invest in supporting Solaris 10?

It has been closed-source (Post-Oracle)

since
March 2010.

On Mon, Dec 18, 2017 at 1:23 PM, Kurt Hornik  wrote:

> > Iñaki Úcar writes:
>
> Same from here: in addition to what the standards say, it always pays to
> be defensive and check "Portable Shell Programming" in the Autoconf
> manual.  Among other things, this says
>
> '$((EXPRESSION))'
>  Arithmetic expansion is not portable as some shells (most notably
>  Solaris 10 '/bin/sh') don't support it.
>
> motivating the code shown below.  Perhaps simplest to always use expr.
>
> -k
>
>
> > For what it's worth, Autoconf does not assume that arithmetic
> > expansion will be available. Instead, it emits the following shell
> > code:
>
> > if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then
> >   eval 'func_arith ()
> >   {
> > func_arith_result=$(( $* ))
> >   }'
> > else
> >   func_arith ()
> >   {
> > func_arith_result=`expr "$@"`
> >   }
> > fi
>
> > 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar :
> >> Dear all,
> >>
> >> During a recent package submission, we were highlighted that some lines
> in
> >> our configure script didn't follow the correct syntax. The lines looked
> like
> >> this:
> >>
> >> x=$(($y/10))
> >>
> >> We were indicated at the time that this is because the statement does
> not
> >> use Bourne shell syntax, which is absolutely true, and also that the
> manual
> >> warns about this, which is true again. So far everything is clear.
> >>
> >> However, what confuses me is that even when the manual says that "you
> can
> >> include an executable (Bourne) shell script configure in your package"
> [1],
> >> the associated footnote says something slightly different: "The script
> >> should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes
> even
> >> further, and links to the POSIX specification of the Shell Command
> Language
> >> [3] (as published by The Open Group), which explicitly includes
> arithmetic
> >> expressions like the one above in its syntax [4].
> >>
> >> My question then is: what exact dialect should be considered? Given
> that the
> >> statement above does not work in the Bourne shell, I conclude that the
> >> Bourne shell is not POSIX-compliant. That in turn would make the manual
> >> ambiguous as to the precise dialect that should be used by our configure
> >> scripts, and either the shells used by R should be changed to be
> >> POSIX-compliants, or the manual edited to be more precise regarding .
> >>
> >> Many thanks.
> >>
> >> Rodrigo
> >>
> >> [1]
> >> https://cran.r-project.org/doc/manuals/r-release/R-exts.
> html#Configure-and-cleanup
> >> [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25
> >> [3] http://pubs.opengroup.org/onlinepubs/9699919799/
> utilities/V3_chap02.html
> >> [4]
> >> http://pubs.opengroup.org/onlinepubs/9699919799/
> utilities/V3_chap02.html#tag_18_06_04
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> > --
> > Iñaki Úcar
> > http://www.enchufa2.es
> > @Enchufa2
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dialect for shell scripts

[peter dalgaard]

Solaris is pretty much dead at this point (closed source or not), but it is not 
the only oddball OS around. 

The need to support a wide palette of (Unix) OS variations has been rapidly 
declining in later years. Fifteen years ago every supercomputer seemed to have 
its own set of OS quirks and we wanted to be able to support the cutting edge. 
Now things seem to converge on a few variations on the big three: Windows, 
MacOS, Linux, possibly on some parallel/cloud infrastructure. 

However, it is probably worth maintaining the conservative defensive policies 
at least for a while yet.

(I suspect that the text in WRE is actually older than the current POSIX 
standard, which is what causes confusion as to what constitutes a Bourne shell. 
It may be worth editing it to say that we are in fact more restrictive than 
current POSIX.)

-pd  

> On 18 Dec 2017, at 23:36 , Paul McQuesten  wrote:
> 
> I do not have a dog in this fight, but I have to ask:
>How much person time is worthwhile to invest in supporting Solaris 10?
> 
> It has been closed-source (Post-Oracle)
> 
> since
> March 2010.
> 
> On Mon, Dec 18, 2017 at 1:23 PM, Kurt Hornik  wrote:
> 
>>> Iñaki Úcar writes:
>> 
>> Same from here: in addition to what the standards say, it always pays to
>> be defensive and check "Portable Shell Programming" in the Autoconf
>> manual.  Among other things, this says
>> 
>> '$((EXPRESSION))'
>> Arithmetic expansion is not portable as some shells (most notably
>> Solaris 10 '/bin/sh') don't support it.
>> 
>> motivating the code shown below.  Perhaps simplest to always use expr.
>> 
>> -k
>> 
>> 
>>> For what it's worth, Autoconf does not assume that arithmetic
>>> expansion will be available. Instead, it emits the following shell
>>> code:
>> 
>>> if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then
>>>  eval 'func_arith ()
>>>  {
>>>func_arith_result=$(( $* ))
>>>  }'
>>> else
>>>  func_arith ()
>>>  {
>>>func_arith_result=`expr "$@"`
>>>  }
>>> fi
>> 
>>> 2017-12-17 23:55 GMT+01:00 Rodrigo Tobar :
 Dear all,
 
 During a recent package submission, we were highlighted that some lines
>> in
 our configure script didn't follow the correct syntax. The lines looked
>> like
 this:
 
 x=$(($y/10))
 
 We were indicated at the time that this is because the statement does
>> not
 use Bourne shell syntax, which is absolutely true, and also that the
>> manual
 warns about this, which is true again. So far everything is clear.
 
 However, what confuses me is that even when the manual says that "you
>> can
 include an executable (Bourne) shell script configure in your package"
>> [1],
 the associated footnote says something slightly different: "The script
 should only assume a POSIX-compliant /bin/sh" [2]. The footnote goes
>> even
 further, and links to the POSIX specification of the Shell Command
>> Language
 [3] (as published by The Open Group), which explicitly includes
>> arithmetic
 expressions like the one above in its syntax [4].
 
 My question then is: what exact dialect should be considered? Given
>> that the
 statement above does not work in the Bourne shell, I conclude that the
 Bourne shell is not POSIX-compliant. That in turn would make the manual
 ambiguous as to the precise dialect that should be used by our configure
 scripts, and either the shells used by R should be changed to be
 POSIX-compliants, or the manual edited to be more precise regarding .
 
 Many thanks.
 
 Rodrigo
 
 [1]
 https://cran.r-project.org/doc/manuals/r-release/R-exts.
>> html#Configure-and-cleanup
 [2] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT25
 [3] http://pubs.opengroup.org/onlinepubs/9699919799/
>> utilities/V3_chap02.html
 [4]
 http://pubs.opengroup.org/onlinepubs/9699919799/
>> utilities/V3_chap02.html#tag_18_06_04
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 
>> 
>>> --
>>> Iñaki Úcar
>>> http://www.enchufa2.es
>>> @Enchufa2
>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@g

Re: [Rd] Dialect for shell scripts

[Rodrigo Tobar]

Hi all,

Thanks to all for your responses. As pointed out by a few of you, using 
expr is indeed safer, and is what we ended up using in our script to get 
it accepted in CRAN.


On 19/12/17 07:26, peter dalgaard wrote:

(I suspect that the text in WRE is actually older than the current POSIX 
standard, which is what causes confusion as to what constitutes a Bourne shell. 
It may be worth editing it to say that we are in fact more restrictive than 
current POSIX.)


This was exactly my point, and I think it would be great to have this 
clarified in the manual to avoid any unsuspected surprises during 
package submission. Since R expectations are naturally aligned with 
autoconf's it would be worth noting that, and maybe also pointing to the 
resource pointed at by Iñaki.


I think the discussion about supported OSs is also an interesting one, 
but is greater than just about this particular subject.


Regards,

Rodrigo

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel