Argument with nargs=Inf type=character is not divided into vector.

[Former user]

When using infinite number of arguments, output is not splitted into vector. Weird is that on different computer (I can't see the configuration now), it works. See appended minimum example, which when called:

Rscript argprint.r --foo a b --bar a b c

where foo is fixed number of arguments and bar infinite number of argument, this gives output:

[[1]]
[1] FALSE

$help
[1] FALSE

$opts
[1] NA

$foo
[1] "a" "b"

$bar
[1] "a,b,c"

Like if convert_type was not called or something:/

[David Shih]

The behaviour you observed is implemented in v0.2.x. Official support for multi-value argument was added in v0.3, which is not on CRAN yet. If you want multivalue support, please update to latest version using the instructions at the front page.

With version argparser v0.4:

$ Rscript argprint.r --foo a b --bar a b c
[[1]]
[1] FALSE

$help
[1] FALSE

$opts
[1] NA

$foo
[1] "a" "b"

$bar
[1] "a" "b" "c"

[David Shih]

I'll submit an updated package to CRAN when I am done with v0.4.

[David Shih]

Official support for multivalue argument is in v0.3.

[Jiří Moravec]

Sorry, this is weird and I am confused, you said that v0.3 is (was) not yet on CRAN, but according to my session info, I am supposed to be on version 0.4 and problem persists.

I tried to download update.packages(), delete from R folder and install again and even install from git.

Rscript argprint.r --foo a b --bar a b c d
[[1]]
[1] FALSE

$help
[1] FALSE

$opts
[1] NA

$foo
[1] "a" "b"

$bar
[1] "a,b,c,d"

R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS

locale:
 [1] LC_CTYPE=cs_CZ.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=cs_CZ.UTF-8        LC_COLLATE=cs_CZ.UTF-8    
 [5] LC_MONETARY=cs_CZ.UTF-8    LC_MESSAGES=cs_CZ.UTF-8   
 [7] LC_PAPER=cs_CZ.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=cs_CZ.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] methods   stats     graphics  grDevices utils     datasets  base     

other attached packages:
[1] argparser_0.4

[David Shih]

Hmm... I might have mislabeled the version I updated to CRAN?

This is what I get with the latest commit:

$ Rscript argprint.r --foo a b --bar a b c
[[1]]
[1] FALSE

$help
[1] FALSE

$opts
[1] NA

$foo
[1] "a" "b"

$bar
[1] "a" "b" "c"

R version 3.2.3 (2015-12-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Red Hat Enterprise Linux Server release 6.8 (Santiago)

locale:
[1] C

attached base packages:
[1] methods   stats     graphics  grDevices utils     datasets  base     

other attached packages:
[1] argparser_0.4

So the bug does not exist in the latest commit.

Thanks for bringing this to my attention. I'll upload v0.5 to CRAN as soon as the other changes are added.

In the meanwhile, you should follow the instructions at https://bitbucket.org/djhshih/argparser to install the latest commit.

[Jiří Moravec]

If you haven't uploaded the 0.4 yet, you might have mislabelled the cran release. However, as stated earlier, I already tried to use version directly from bitbucket with same behaviour (btw. do you use devtools? It simplifies package development and instalation and than you could just use install_bitbucket function). Maybe locale might be the problem? As on my work computer with english locale it is OK, but on my home computer its broken.

I will look into it when I have time (and desk and chair).

[David Shih]

I use devtools. You can also do document and install after cloning the directory. I do not agree with how the install_bitbucket works. It does not attempt to generate intermediate files (e.g. man pages, NAMSPACE, etc.), last time I tried. It is generally considered poor practice to commit automatically generated files in a git commit:

https://sethrobertson.github.io/GitBestPractices/

I also rarely install packages directly from git repositories.

I already tried to use version directly from bitbucket with same behaviour

If this is true, I must say I really cannot help you. I cannot reproduce your error. You should make you have followed the instructions exactly as written.

I see that you are using a new version of R. I may try to reproduce your error using a later version of R. At this point, your best bet is probably to wait for the v0.5 release on CRAN.