I have made available the work of the last weekend that I mentioned
in my previous messages on ftp://sirio.stat.unipd.it/pub/R.
Many thanks to Peter D. and Ross I. for their suggestions.
If you think that the work is of some interest, I can upload it
to CRAN.
guido m.
This is the README enclosed in the distribution.
-------------------------------------------------------------------------
rgnwbin.tgz and rgnwsrc.tgz are the first results of an attempt to
build R for Win95 and WinNT using egcs-mingw32.
The advantages over the binaries for MsWindows that can be found in CRAN
are:
1. R seems to run faster. Some simple (perhaps too simple)
benchmarks point to a 20% gain.
2. The port is based on a more recent version (0.61.1) and it is more
complete (more "system calls": system, tempfile, unlink,
WinExec - to launch applications without waiting for the result;
support for the standard help system: try help(), help(abline),
help(line,eda), ?women, data(), library())
3. A new menu item "Stop current computation" make possible
to interupt long computation (but only when something is printed).
4. Since egcs-mingw32 uses the standard C calling convention,
you don't need a Watcom compiler to build dynamic link libraries.
Indeed, this was my original motivation.
5. It should be easy to use some other gnu-win32 compilers (maybe
running on a non MsWindows machine). It should be easy to
adapt the port to lcc-win32, too.
But remember: this is experimental code so
-----------------------------------------------------------------------------
USE IT AT YOUR RISK
-----------------------------------------------------------------------------
BINARY DISTRIBUTION
Just unpack rgwnbin.tgz somewhere.
The executable is R.GNW\bin\R.exe. This binary distribution
includes only the standard packages (base+eda+mva+stepfun).
SOURCE DISTRIBUTION
This is an add-on to the R-0.61.1 distribution.
So unpack R-0.61.1.tar.gz somewhere.
Then, from the same directory, unpack rgwnsrc.tgz.
To rebuild the system, go to R-0.61.1/src/gnuwin32.
Then
> make
should build the standard stuff.
To add a new package, you should
a) download it;
b) unpack it in the R-0.61.1/src directory.
c) go to the R-0.61.1/src/gnuwin32 directory and type
> make pkg-xxx
where xxx is the name of the package.
You should get the directory R-0.61.1/library/xxx
and its subdirectory R/ (the r-code) data/ (the
data of the package) R/libs (the dynamic link library) and
the support for the help system (INDEX, TITLE, an updated
LibIndex). Of course, the data and libs subdirectory
can be missing.
d) if you want the documentation, you can download
the preformatted one.Then unpack it in the R-0.61.1
(not in the R-0.61.1/src) directory. If you don't need
the LaTeX files, remove them.
Note:
(1) Of course, you need a compiler. As I have said I used
the egcs-mingw32 one:
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
(2) You must also have a GNU make and some standard unix
command (ls,cat,sed,rm). Furthemore, make and this
command must be able to overcome the MsDOS limitation
about the length of a command.
I used the ones coming with the djgpp compiler.
According to me, they are the best version for dos and
windows. You can find it in any SIMTEL mirror.
If you want, I can make available a small file with
only the needed tools.
(3) The gnuwin32/Makefile use the g77 Fortran compiler.
If you don't have it, or if you don't want to use it,
you can use something like
> make HAVEG77=NO
or
> make HAVEG77=NO pkg-xxx
For example, the g77 compiler in egcs-mingw32 was
not able to compile the fortran code in the acepack package.
However, I was able to build this package with the command
> make HAVEG77=NO pkg-acepack
(4) When installing a package, if in R-0.61.1/src/library/xxx/R
exist a file with name yyy.gnw then this file is used
and files with name yyy or yyy.somethingelse are
ignored. In this way, you can configure the R code
of the package. An example is the base/R/system.gnw
file.
(5) This is not a developer's distribution. For example, dependences
are written in a silly way. Furthemore, all the code
in src/appl/, src/appl-f,..... is compiled.
No use of the original Makefile is done.
Hence, you have to start from a cleaned distribution.
BUGS and TODO
(0) The English of this README.
(1) If you exit from the edit windows and this is empty you get a
segmentation fault. This happens also on my Linux box. So,
it seem to be a general problem.
(2) The dll's are statically linked with the other R code.
So they get support for the routines that they need.
In this way, they work but are big. We should have
a large R.dll with all the standard code. Then
the executable and the dll's should simply import
from R.dll.
(3) Try and adapt this port to other win32 compiler.
It should be easy. So, why don't try?
(4) The system command does not work if the command to be
execute require some user interaction. It is just a
"simulated reading pipe for a broken OS".
(5) I inserted an event loop at the beginning of the
function which print to the console. In this way,
you can interupt the computation or, for example,
give the focus to the graphics window.
But only when you print. A call to the event loop
must be inserted inside the "main" code.
But, for the moment, I decided to leave the "main"
code untouched.
(6) When building package xxx, all the C and Fortran files
found in library/xxx/src (or library/xxx/src-c if
you don't have the g77 compiler) are compiled
and putted in a dll. On the contrary, we have to make
use of the original Makefile.
(7) The Windows code must be cleaned.
guido masarotto 22 marzo 1998
guido@sirio.stat.unipd.it
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
guido@sirio.stat.unipd.it writes:> rgnwbin.tgz and rgnwsrc.tgz are the first results of an attempt to > build R for Win95 and WinNT using egcs-mingw32. > > The advantages over the binaries for MsWindows that can be found in CRAN > are: > 1. R seems to run faster. Some simple (perhaps too simple) > benchmarks point to a 20% gain. > 2. The port is based on a more recent version (0.61.1) and it is more > complete (more "system calls": system, tempfile, unlink, > WinExec - to launch applications without waiting for the result; > support for the standard help system: try help(), help(abline), > help(line,eda), ?women, data(), library()) > 3. A new menu item "Stop current computation" make possible > to interupt long computation (but only when something is printed). > 4. Since egcs-mingw32 uses the standard C calling convention, > you don't need a Watcom compiler to build dynamic link libraries. > Indeed, this was my original motivation. > 5. It should be easy to use some other gnu-win32 compilers (maybe > running on a non MsWindows machine). It should be easy to > adapt the port to lcc-win32, too.One piece of bad news is that it doesn't work on Win3.X systems (win32s). The PE-COFF object files that mingw32 makes simply won't load, even for a "Hello, world" example. The most likely candidate to get something running on that platform (I, for one, still have quite a few students with older notebooks and/or upgrade paranoia) seems to be RSXNT, but it's not all that simple. It's also GCC-based, but the "specs" file is set up differently from the mingw32/egcs one, which may create a great deal of "fun". RSXNT can (e.g.) be found at ftp://ftp.tex.ac.uk/tex-archive/systems/msdos/dpmigcc/ I did a quick test and it does seem that a little fiddling makes it possible to compile e.g. wincons.c with mingw32 headers plus a few extra defines from the mingw32 specs file, so it would seem to be doable, but it's hardly trivial. (Actually, this was with the ordinary Linux GCC, but it's the header files that always cause trouble). I also haven't got the foggiest about how to create DLL's with RSXNT, especially how to to the important callbacks to the R binary (call_R). And, there's no g77 in RSXNT, so you'd need f2c. Perhaps it would be easier to make the egcs cross-platform tools once and for all? In any case, we need to do an "official" collection of tools. I tried to compile using Guido's files during Easter, but immediately got stopped by the absence of an "ls" command... -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
My own efforts to get a new windows version out have been hampered by the preponderance of bugs in Watcom C (11.0). They decided to make their dll's and exe's somewhat more compatible with M'soft stuff out of Visual C. They seemed to create a large number of bugs in the process. They have also decided not to distribute patches but rather to sell CD's with the patches on them......(isn't commercial software a wonderful thing) robert -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Peter Dalgaard BSA writes:
>
> Ouch! In that case, I suggest that we try to put some collective
> effort into getting something working with RSXNT. The only thing that
> bothers me a little is that RSXNT isn't quite GPL compatible (you have
> to pay a license for non-freeware usage) but I suppose that (a) it's a
> very mild restriction, and (b) it can hardly be worse than shipping
> GCC itself for RSXNT... There are certainly a lot of good things to be
> said for using GCC throughout.
>
1) More than one year ago, hence, maybe, things are changed, I download
RSXNT. However, I had problems to run its demo under MsWin3.1 (not under
Win95). So, I prefered to give up. Just a limited experience, however.
The other problem that I see is that, if I understand well,
RSXNT is the effort of just one pearson not of a team.
2) What about DOS? Do you think that we really need a GUI console under
Microsoft-something? A couple of week ago, I took a look to the
R code thinking to recompile it with DJGPP. I didn't try but it seems
possible. The advantages that I can see are:
a) DJGPP is stable, mature and supported.
b) I have limited experence but dynamic linking with DJGPP works
better than under Windows. For me, of course. And I am not a
Windows programmers. But, I was able to to build dyn. libs
which call routines in the main executable (and we need this
non only for call_R but also for R_alloc and S_alloc).
With, just 3 #define's its possible to use the dlopen/dlsym/dlclose
interface.
c) Same user interface under MsWindows and Unix (character+readline).
d) DJGPP has g77.
e) From DOS to WinNt, only one executable.
A couple of disadvantages are:
a) Old fashion.
b) We need a new device. I suggest one based on grx (the standard djgpp
graphic library) since this will have a small side effect:
grx is available also for the linux console so can be used under
linux without X (I remember some question about this on
the R mailing list).
c) dll's must be built using djgpp; anyway, djgpp is GPL.
Comments? I have no time for a couple of weeks, but, after, if you
think that can be a worth tentative, I can make the first
attempt (manage to recompile the non-graphic part +
write a first draft for the graphic device if the previous
point go well).
guido m.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._