[R] [SPAM] - Re: R package development in windows - BayesianFilter detected spam

[Gabor Grothendieck]

I think its actually here:

http://search.cpan.org/dist/ppt/

but would have the significant disadvantage of deepening the use of
perl whereas I think the direction should be to get rid of perl.

On 5/5/07, Greg Snow <Greg.Snow at intermountainmail.org> wrote:
>
> If we go the route of converting Perl scripts into windows executables, then
> there is the Perl Power Tools (ppt) project for perl that aims to create a
> cross platform set of common Unix tools (see
> http://sourceforge.net/projects/ppt/, or the current
> toolset can be downloaded from CPAN).  The find utility has been included
> for a while and I think we could get the author of that one to help.
>
> If all the Unix tools needed by R are included in ppt, then it may be
> possible to use those in Rtools for an overall smaller footprint.  The find
> perl script could be compiled to an .exe and given a different name so that
> it would not conflict with the windows find command.
>
> There would need to be some switch or something to indicate using these
> tools rather than the standards for those that don't use the Rtools (but
> insteal installed perl and the other tools).
>
> ________________________________
> From: Duncan Murdoch [mailto:murdoch at stats.uwo.ca]
> Sent: Sat 5/5/2007 6:06 AM
> To: Gabor Grothendieck
> Cc: Greg Snow; Doran, Harold; r-help at stat.math.ethz.ch
>
> Subject: Re: [R] [SPAM] - Re: R package development in windows -
> BayesianFilter detected spam
>
>
>
>
> On 05/05/2007 8:00 AM, Gabor Grothendieck wrote:
> > I think that should be the default in order to protect the user.
> Protecting
> > the user from this sort of annoying conflict is important for a
> professionally
> > working product that gets along with the rest of the Windows system.
>
> I don't, because R building requires simulation of a subset of a Unix
> environment, so in case of a Unix/Windows conflict, Unix should win.
> For example none of the Makefiles use backslashes as path separators,
> they all use Unix-style forward slashes.
>
> Duncan Murdoch
>
>
> >
> > On 5/5/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> >> On 04/05/2007 9:32 PM, Gabor Grothendieck wrote:
> >>> It certainly would be excellent if installing perl could be eliminated.
> >>>
> >>> One additional thing that I really dislike about the R installation is
> that
> >>> one needs "find" on one's path and that conflicts with "find" on Windows
> >>> so other applications unrelated to R that use scripts can suddenly break
> >>> because of R.  If that could be solved at the same time it would be
> nice.
> >> At a minimum we should be able to wrap the calls to find in a macro, so
> >> you could change the macro in MkRules and rename your copy from Rtools
> >> to remove the conflict.  I'll take a look.
> >>
> >> Duncan Murdoch
> >>
> >>> On 5/4/07, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> >>>> On 04/05/2007 4:25 PM, Greg Snow wrote:
> >>>>> I have used the pp/par combination for Perl before.  It is pretty
> straight forward to convert an existing perl script into a stand alone
> windows executable.
> >>>>>
> >>>>> Both the Activestate licence and the Perl Artistic licence allow for
> embedding a script and perl interpreter together and distributing the
> result.
> >>>>>
> >>>>> The current perl script(s) used for the R package build package could
> easily be converted to a 'stand alone' windows executable and be distributed
> with Rtools for those who do not want to install Perl themselves.
> >>>>>
> >>>>> The only drawback is that even a "Hello World" script will result in
> over a meg sized executable (due to the perl interpreter being included).
> >>>> I took a quick look at the PAR page on CPAN, and it seems possible to
> >>>> build a DLL that incorporates the interpreter, and then each individual
> >>>> script .exe could be much smaller.  I'll see if I can get that to work;
> >>>> it would be really nice to be able to drop the Perl requirement.  If we
> >>>> could do that, I'd include the command line tools plus the compiled
> >>>> scripts with the basic R distribution, so you could easily build simple
> >>>> packages.  The Rtools.exe installer would then just need to install the
> >>>> MinGW compilers for packages containing compiled code, and a few extras
> >>>> needed for building R.
> >>>>
> >>>> I don't really know Perl, so I might be asking for advice if I get
> stuck.
> >>>>
> >>>> Duncan Murdoch
> >>>>> ________________________________
> >>>>>
> >>>>> From: r-help-bounces at stat.math.ethz.ch on behalf of
> Gabor Grothendieck
> >>>>> Sent: Fri 5/4/2007 11:55 AM
> >>>>> To: Doran, Harold
> >>>>> Cc: r-help at stat.math.ethz.ch; Duncan Murdoch
> >>>>> Subject: Re: [R] [SPAM] - Re: R package development in windows -
> BayesianFilter detected spam
> >>>>>
> >>>>>
> >>>>>
> >>>>> Just googling I found this:
> >>>>>
> >>>>> http://www.perlmonks.org/?node_id=186402
> >>>>>
> >>>>> On 5/4/07, Doran, Harold <HDoran at air.org> wrote:
> >>>>>>> The best, of course, would be to get rid of Perl altogether.
> >>>>>> In Python, it is possible to make standalone executables. Is it
> possible
> >>>>>> to also do this in Perl, then one could eliminate a perl install. Or,
> is
> >>>>>> it possible to use Python to accomplish what perl is currently doing?
> I
> >>>>>> may be getting in over my head here since I really don't know what
> perl
> >>>>>> is doing under the hood.
> >>>>>>
> >>>>>> Harold
> >>>>>>
> >>>>> ______________________________________________
> >>>>> R-help at stat.math.ethz.ch mailing list
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-help
> >>>>> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> >>>>> and provide commented, minimal, self-contained, reproducible code.
> >>>>>
> >>>>>
> >>>>>
> >>
>
>