Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Duncan Murdoch 

On 10/01/2024 10:53 a.m., Dirk Eddelbuettel wrote:


On 10 January 2024 at 16:25, Uwe Ligges wrote:
|
|
| On 10.01.2024 15:35, Josiah Parry wrote:
| > Thanks, all. As it goes, the package submission failed. The package that
| > is suggested is available at https://r.esri.com/bin/
| >  and as such provided `https://r.esri.com
| > ` as the url in `Additional_repositories`.
|
| There is no
|
| https://r.esri.com/src
|
| hence it is obviously not a standard repository.

And how to set one up is described very patiently over ten pages in

Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data

at

https://journal.r-project.org/archive/2017/RJ-2017-026/index.html


And for the impatient, see the drat "Quick Start" instructions at

  https://github.com/eddelbuettel/drat

They work really well!  Thanks Dirk!

Duncan Murdoch



which does

Abstract Data-only packages offer a way to provide extended functionality
for other R users. However, such packages can be large enough to exceed
the package size limit (5 megabytes) for the Comprehen sive R Archive
Network (CRAN). As an alternative, large data packages can be posted to
additional repostiories beyond CRAN itself in a way that allows smaller
code packages on CRAN to access and use the data. The drat package
facilitates creation and use of such alternative repositories and makes it
particularly simple to host them via GitHub. CRAN packages can draw on
packages posted to drat repositories through the use of the
‘Additonal_repositories’ field in the DESCRIPTION file. This paper
describes how R users can create a suite of coordinated packages, in which
larger data packages are hosted in an alternative repository created with
drat, while a smaller code package that interacts with this data is
created that can be submitted to CRAN.

for the use case of a 'too large for CRAN' suggested data package

| > The request was to remove the additional repositories and provide
| > instructions for package installation in the Description field. This
| > package, arcgisbinding, is used in one line of the entire package
| > 
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123 

 to extract an authorization token. It is provided for compatibility with a semi-closed-source R 
package. The installation instructions for which arelengthy 
(https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html 
) and /only 
/available as a windows binary. Providing an explicit call out for installation in the 
"Description" field of the DESCRIPTION feels like it is co-opting the Description to describe 
the installation process for a function that I anticipate /very few /people to use.
|
| So you can either remove the need for that package or say something like
| " and if an authorization token is to be extracted on Windows, the
| 'arcgisbinding' package is needed that can be installed as explained at
| ."

Additional_repositories is great, and you have 134 examples at CRAN:


D <- data.table(tools::CRAN_package_db())
D[is.na(Additional_repositories)==FALSE, .(Package, Additional_repositories)]

   Package
Additional_repositories

 
   1:archiDART  
https://archidart.github.io/drat/
   2:   aroma.core 
https://henrikbengtsson.r-universe.dev,\nhttps://r-forge.r-project.org
   3: asteRisk   
https://rafael-ayala.github.io/drat/
   4:BayesfMRI 
https://inla.r-inla-download.org/R/testing
   5:bigDM  
https://inla.r-inla-download.org/R/stable
  ---
130:TreatmentPatterns   
https://ohdsi.github.io/drat
131: TreeDist  
https://ms609.github.io/packages/
132: triplesmatch
https://errickson.net/rrelaxiv/
133: USA.state.boundaries 
https://iembry.gitlab.io/drat/
134:  voi 
https://inla.r-inla-download.org/R/stable/




Dirk



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

Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Duncan Murdoch 

On 10/01/2024 9:35 a.m., Josiah Parry wrote:
Thanks, all. As it goes, the package submission failed. The package that 
is suggested is available at https://r.esri.com/bin/ 
 and as such provided `https://r.esri.com 
` as the url in `Additional_repositories`.


I don't see a source package there, only .zip files.  Those are only 
going to work on Windows, and only on the R versions you've prepared it 
for.  If the suggested package is only on that platform, I'd suggest 
removing it from "Suggests", and just describe what it does and how to 
use it in a vignette or help page.


If you really want to keep it in Suggests, but don't want to describe 
installation in the way that was recommended to you, then take the other 
route, and put it in an "Additional_repositories" repository as I 
suggested last week -- but this time make sure to use a properly 
formatted repository, not just a web site with some binary builds.  The 
"drat" package makes building one of those really easy.


Duncan Murdoch

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

Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Dirk Eddelbuettel 


On 10 January 2024 at 16:25, Uwe Ligges wrote:
| 
| 
| On 10.01.2024 15:35, Josiah Parry wrote:
| > Thanks, all. As it goes, the package submission failed. The package that 
| > is suggested is available at https://r.esri.com/bin/ 
| >  and as such provided `https://r.esri.com 
| > ` as the url in `Additional_repositories`.
| 
| There is no
| 
| https://r.esri.com/src
| 
| hence it is obviously not a standard repository.

And how to set one up is described very patiently over ten pages in

   Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data

at

   https://journal.r-project.org/archive/2017/RJ-2017-026/index.html

which does

   Abstract Data-only packages offer a way to provide extended functionality
   for other R users. However, such packages can be large enough to exceed
   the package size limit (5 megabytes) for the Comprehen sive R Archive
   Network (CRAN). As an alternative, large data packages can be posted to
   additional repostiories beyond CRAN itself in a way that allows smaller
   code packages on CRAN to access and use the data. The drat package
   facilitates creation and use of such alternative repositories and makes it
   particularly simple to host them via GitHub. CRAN packages can draw on
   packages posted to drat repositories through the use of the
   ‘Additonal_repositories’ field in the DESCRIPTION file. This paper
   describes how R users can create a suite of coordinated packages, in which
   larger data packages are hosted in an alternative repository created with
   drat, while a smaller code package that interacts with this data is
   created that can be submitted to CRAN.

for the use case of a 'too large for CRAN' suggested data package

| > The request was to remove the additional repositories and provide 
| > instructions for package installation in the Description field. This 
| > package, arcgisbinding, is used in one line of the entire package 
| > 
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123
 

 to extract an authorization token. It is provided for compatibility with a 
semi-closed-source R package. The installation instructions for which 
arelengthy 
(https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html 
) 
and /only /available as a windows binary. Providing an explicit call out for 
installation in the "Description" field of the DESCRIPTION feels like it is 
co-opting the Description to describe the installation process for a function 
that I anticipate /very few /people to use.
| 
| So you can either remove the need for that package or say something like 
| " and if an authorization token is to be extracted on Windows, the 
| 'arcgisbinding' package is needed that can be installed as explained at 
| ."

Additional_repositories is great, and you have 134 examples at CRAN:

> D <- data.table(tools::CRAN_package_db())
> D[is.na(Additional_repositories)==FALSE, .(Package, Additional_repositories)]
  Package
Additional_repositories
  
  
  1:archiDART  
https://archidart.github.io/drat/
  2:   aroma.core 
https://henrikbengtsson.r-universe.dev,\nhttps://r-forge.r-project.org
  3: asteRisk   
https://rafael-ayala.github.io/drat/
  4:BayesfMRI 
https://inla.r-inla-download.org/R/testing
  5:bigDM  
https://inla.r-inla-download.org/R/stable
 ---

130:TreatmentPatterns   
https://ohdsi.github.io/drat
131: TreeDist  
https://ms609.github.io/packages/
132: triplesmatch
https://errickson.net/rrelaxiv/
133: USA.state.boundaries 
https://iembry.gitlab.io/drat/
134:  voi 
https://inla.r-inla-download.org/R/stable/
>

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Uwe Ligges 



On 10.01.2024 16:29, Josiah Parry wrote:
Well, I wouldn't say "obviously." It's not quite clear what a "standard" 
CRAN-like repository looks like unless you have an intimate knowledge of 
CRAN's structure.


A repository r that works with

install.packages(..., repos=r)

i.e. needs PACKAGES files and sources/binaries in relevant directories 
such as

./src (at least)
and ideally also
./bin/windows/contrib/4.2/
./bin/windows/contrib/4.3/
./bin/windows/contrib/4.4/
and similarly for mac.

Best,
Uwe Ligges





Regardless, thank you for the feedback! I'll adjust the description file.

On Wed, Jan 10, 2024 at 10:26 AM Uwe Ligges 
> wrote:




On 10.01.2024 15:35, Josiah Parry wrote:
 > Thanks, all. As it goes, the package submission failed. The
package that
 > is suggested is available at https://r.esri.com/bin/

 > > and as such
provided `https://r.esri.com 
 > >` as the url in
`Additional_repositories`.

There is no

https://r.esri.com/src 

hence it is obviously not a standard repository.


 > The request was to remove the additional repositories and provide
 > instructions for package installation in the Description field. This
 > package, arcgisbinding, is used in one line of the entire package
 >
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123 
 
> to 
extract an authorization token. It is provided for compatibility with a semi-closed-source R package. The installation 
instructions for which arelengthy (https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html 
 
>) and /only /available as a windows 
binary. Providing an explicit call out for installation in the "Description" field of the DESCRIPTION feels like it 
is co-opting the Description to describe the installation process for a function that I anticipate /very few /people to use.

So you can either remove the need for that package or say something
like
" and if an authorization token is to be extracted on Windows, the
'arcgisbinding' package is needed that can be installed as explained at
>."

Best,
Uwe Ligges



 >
 > Is there another approach that can be taken here? The one requested
 > feels like an incorrect use of the description field because it no
 > longer describes the package but how to handle one very rare edge
case.
 >
 > On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges
 > mailto:lig...@statistik.tu-dortmund.de>
 > >> wrote:
 >
 >       From the CRAN polcies:
 >
 >     "Packages on which a CRAN package depends should be available
from a
 >     mainstream repository: if any mentioned in ‘Suggests’ or
‘Enhances’
 >     fields are not from such a repository, where to obtain them at a
 >     repository should be specified in an
‘Additional_repositories’ field of
 >     the DESCRIPTION file (as a comma-separated list of repository
URLs) or
 >     for other means of access, described in the ‘Description’
field. "
 >
 >     Best,
 >     Uwe Ligges
 >
 >
 >
 >
 >     On 03.01.2024 18:19, Josiah Parry wrote:
 >      > Thanks, both. I'm not familiar with
Additional_repositories. Must
 >     the
 >      > package source be specified there? Or can it be specified via
 >      > documentation a la Rd file?
 >      >
 >      > On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
 >      > mailto:lig...@statistik.tu-dortmund.de>
 >     >
 >      > 
 >           >
 >      >
 >      >
 >      >     On 03.01.2024 17:58, Duncan Murdoch wrote:
 >      >      > On 03/01/2024 11:33 a.m., Josiah Parry wrote:
 >      >      >> I have a scenario where I have an exported
function

Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Josiah Parry 
Well, I wouldn't say "obviously." It's not quite clear what a "standard"
CRAN-like repository looks like unless you have an intimate knowledge of
CRAN's structure.

Regardless, thank you for the feedback! I'll adjust the description file.

On Wed, Jan 10, 2024 at 10:26 AM Uwe Ligges 
wrote:

>
>
> On 10.01.2024 15:35, Josiah Parry wrote:
> > Thanks, all. As it goes, the package submission failed. The package that
> > is suggested is available at https://r.esri.com/bin/
> >  and as such provided `https://r.esri.com
> > ` as the url in `Additional_repositories`.
>
> There is no
>
> https://r.esri.com/src
>
> hence it is obviously not a standard repository.
>
>
> > The request was to remove the additional repositories and provide
> > instructions for package installation in the Description field. This
> > package, arcgisbinding, is used in one line of the entire package
> >
> https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123
> <
> https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123>
> to extract an authorization token. It is provided for compatibility with a
> semi-closed-source R package. The installation instructions for which
> arelengthy (
> https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html
> <
> https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html>)
> and /only /available as a windows binary. Providing an explicit call
> out for installation in the "Description" field of the DESCRIPTION feels
> like it is co-opting the Description to describe the installation process
> for a function that I anticipate /very few /people to use.
>
> So you can either remove the need for that package or say something like
> " and if an authorization token is to be extracted on Windows, the
> 'arcgisbinding' package is needed that can be installed as explained at
> ."
>
> Best,
> Uwe Ligges
>
>
>
> >
> > Is there another approach that can be taken here? The one requested
> > feels like an incorrect use of the description field because it no
> > longer describes the package but how to handle one very rare edge case.
> >
> > On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges
> >  > > wrote:
> >
> >   From the CRAN polcies:
> >
> > "Packages on which a CRAN package depends should be available from a
> > mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’
> > fields are not from such a repository, where to obtain them at a
> > repository should be specified in an ‘Additional_repositories’ field
> of
> > the DESCRIPTION file (as a comma-separated list of repository URLs)
> or
> > for other means of access, described in the ‘Description’ field. "
> >
> > Best,
> > Uwe Ligges
> >
> >
> >
> >
> > On 03.01.2024 18:19, Josiah Parry wrote:
> >  > Thanks, both. I'm not familiar with Additional_repositories. Must
> > the
> >  > package source be specified there? Or can it be specified via
> >  > documentation a la Rd file?
> >  >
> >  > On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  >
> >  >
> >  > On 03.01.2024 17:58, Duncan Murdoch wrote:
> >  >  > On 03/01/2024 11:33 a.m., Josiah Parry wrote:
> >  >  >> I have a scenario where I have an exported function that
> >  > requires the
> >  >  >> installation a package that *is not* available on CRAN.
> > The body
> >  > of the
> >  >  >> function is generally:
> >  >  >>
> >  >  >> fx <- function() {
> >  >  >>rlang::check_installed("noncranpkg")
> >  >  >>noncranpkg::gx()
> >  >  >> }
> >  >  >>
> >  >  >> As required, this package is in the Suggests field. But
> this
> >  > results in a
> >  >  >> note:
> >  >  >>
> >  >  >> checking package dependencies ... NOTE
> >  >  >> Package suggested but not available for checking:
> > ‘noncranpkg’
> >  >  >>
> >  >  >> Can this be safely ignored?
> >  >  >
> >  >  > Uwe said yes, and he's an authority.  But for your users,
> it
> >  > might be
> >  >  > nice to include an Additional_repositories field so they
> > can find
> >  > the
> >  >  > package.  This needs to be organized as an actual
> > repository; the
> >  > drat
> >  >  > package is a very convenient way to set one up.
> >  >
> >  > Thanks for elaborating, yes of course, people have to declare
> > where to
> >  > get the package from. The note from above is still
> unavoidable in
> >  >

Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Uwe Ligges 



On 10.01.2024 15:35, Josiah Parry wrote:
Thanks, all. As it goes, the package submission failed. The package that 
is suggested is available at https://r.esri.com/bin/ 
 and as such provided `https://r.esri.com 
` as the url in `Additional_repositories`.


There is no

https://r.esri.com/src

hence it is obviously not a standard repository.


The request was to remove the additional repositories and provide 
instructions for package installation in the Description field. This 
package, arcgisbinding, is used in one line of the entire package 
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123  to extract an authorization token. It is provided for compatibility with a semi-closed-source R package. The installation instructions for which arelengthy (https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html ) and /only /available as a windows binary. Providing an explicit call out for installation in the "Description" field of the DESCRIPTION feels like it is co-opting the Description to describe the installation process for a function that I anticipate /very few /people to use.


So you can either remove the need for that package or say something like 
" and if an authorization token is to be extracted on Windows, the 
'arcgisbinding' package is needed that can be installed as explained at 
."


Best,
Uwe Ligges





Is there another approach that can be taken here? The one requested 
feels like an incorrect use of the description field because it no 
longer describes the package but how to handle one very rare edge case.


On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges 
> wrote:


  From the CRAN polcies:

"Packages on which a CRAN package depends should be available from a
mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’
fields are not from such a repository, where to obtain them at a
repository should be specified in an ‘Additional_repositories’ field of
the DESCRIPTION file (as a comma-separated list of repository URLs) or
for other means of access, described in the ‘Description’ field. "

Best,
Uwe Ligges




On 03.01.2024 18:19, Josiah Parry wrote:
 > Thanks, both. I'm not familiar with Additional_repositories. Must
the
 > package source be specified there? Or can it be specified via
 > documentation a la Rd file?
 >
 > On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
 > mailto:lig...@statistik.tu-dortmund.de>
 > >> wrote:
 >
 >
 >
 >     On 03.01.2024 17:58, Duncan Murdoch wrote:
 >      > On 03/01/2024 11:33 a.m., Josiah Parry wrote:
 >      >> I have a scenario where I have an exported function that
 >     requires the
 >      >> installation a package that *is not* available on CRAN.
The body
 >     of the
 >      >> function is generally:
 >      >>
 >      >> fx <- function() {
 >      >>    rlang::check_installed("noncranpkg")
 >      >>    noncranpkg::gx()
 >      >> }
 >      >>
 >      >> As required, this package is in the Suggests field. But this
 >     results in a
 >      >> note:
 >      >>
 >      >> checking package dependencies ... NOTE
 >      >> Package suggested but not available for checking:
‘noncranpkg’
 >      >>
 >      >> Can this be safely ignored?
 >      >
 >      > Uwe said yes, and he's an authority.  But for your users, it
 >     might be
 >      > nice to include an Additional_repositories field so they
can find
 >     the
 >      > package.  This needs to be organized as an actual
repository; the
 >     drat
 >      > package is a very convenient way to set one up.
 >
 >     Thanks for elaborating, yes of course, people have to declare
where to
 >     get the package from. The note from above is still unavoidable in
 >     that case.
 >
 >     Best,
 >     Uwe
 >
 >      >
 >      > Duncan Murdoch
 >      >
 >      > __
 >      > R-package-devel@r-project.org

 >     > mailing list
 >      > https://stat.ethz.ch/mailman/listinfo/r-package-devel

 >     >
 >

Re: [R-pkg-devel] Suggests with non-CRAN packages

2024-01-10 Thread Josiah Parry 
Thanks, all. As it goes, the package submission failed. The package that is
suggested is available at https://r.esri.com/bin/ and as such provided `
https://r.esri.com` as the url in `Additional_repositories`.

The request was to remove the additional repositories and provide
instructions for package installation in the Description field. This
package, arcgisbinding, is used in one line of the entire package
https://github.com/R-ArcGIS/arcgisutils/blob/64093dc1a42fa28010cd45bb6ae8b8c57835cb40/R/arc-auth.R#L123
to extract an authorization token. It is provided for compatibility with a
semi-closed-source R package. The installation instructions for which
arelengthy (
https://r.esri.com/r-bridge-site/arcgisbinding/installing-arcgisbinding.html)
and *only *available as a windows binary. Providing an explicit call
out for installation in the "Description" field of the DESCRIPTION feels
like it is co-opting the Description to describe the installation process
for a function that I anticipate *very few *people to use.

Is there another approach that can be taken here? The one requested feels
like an incorrect use of the description field because it no longer
describes the package but how to handle one very rare edge case.

On Wed, Jan 3, 2024 at 12:36 PM Uwe Ligges 
wrote:

>  From the CRAN polcies:
>
> "Packages on which a CRAN package depends should be available from a
> mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’
> fields are not from such a repository, where to obtain them at a
> repository should be specified in an ‘Additional_repositories’ field of
> the DESCRIPTION file (as a comma-separated list of repository URLs) or
> for other means of access, described in the ‘Description’ field. "
>
> Best,
> Uwe Ligges
>
>
>
>
> On 03.01.2024 18:19, Josiah Parry wrote:
> > Thanks, both. I'm not familiar with Additional_repositories. Must the
> > package source be specified there? Or can it be specified via
> > documentation a la Rd file?
> >
> > On Wed, Jan 3, 2024 at 12:14 PM Uwe Ligges
> >  > > wrote:
> >
> >
> >
> > On 03.01.2024 17:58, Duncan Murdoch wrote:
> >  > On 03/01/2024 11:33 a.m., Josiah Parry wrote:
> >  >> I have a scenario where I have an exported function that
> > requires the
> >  >> installation a package that *is not* available on CRAN. The body
> > of the
> >  >> function is generally:
> >  >>
> >  >> fx <- function() {
> >  >>rlang::check_installed("noncranpkg")
> >  >>noncranpkg::gx()
> >  >> }
> >  >>
> >  >> As required, this package is in the Suggests field. But this
> > results in a
> >  >> note:
> >  >>
> >  >> checking package dependencies ... NOTE
> >  >> Package suggested but not available for checking: ‘noncranpkg’
> >  >>
> >  >> Can this be safely ignored?
> >  >
> >  > Uwe said yes, and he's an authority.  But for your users, it
> > might be
> >  > nice to include an Additional_repositories field so they can find
> > the
> >  > package.  This needs to be organized as an actual repository; the
> > drat
> >  > package is a very convenient way to set one up.
> >
> > Thanks for elaborating, yes of course, people have to declare where
> to
> > get the package from. The note from above is still unavoidable in
> > that case.
> >
> > Best,
> > Uwe
> >
> >  >
> >  > Duncan Murdoch
> >  >
> >  > __
> >  > R-package-devel@r-project.org
> >  mailing list
> >  > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > 
> >
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Fw: [Rd] using Paraview "in-situ" with R?

2024-01-10 Thread Mike Marchywka 
The r-devel list suggested I try this here. Thanks. 



From: R-devel  on behalf of Mike Marchywka 

Sent: Tuesday, January 9, 2024 9:20 AM
To: R-devel
Subject: [Rd] using Paraview "in-situ" with R?

I had previously asked about R interfaces to various "other" visualization
tools specifically lightweights for monitoring progress of
various codes. I was working on this,

https://github.com/mmarchywka/mjmdatascope

but in the meantime found out that Paraview has an "in-situ"
capability for similar objectives.

https://discourse.paraview.org/t/does-or-can-paraview-support-streaming-input/13637/9

While R does have a lot of plotting features,
it seems like an excellent tool to interface to R allowing visualization without
a bunch of temp files or

Is anyone aware of anyone doing this interface or reasons its  a boondoggle?

Thanks.



 Mike Marchywka
44 Crosscreek Trail
Jasper GA 30143
was 306 Charles Cox Drive  Canton, GA 30115
470-758-0799
404-788-1216



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

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