Re: [Rd] GUI error. (PR#8204)
I was also unable to reproduce this in either 2.2.0 or current (from svn) R-devel. On Wed, 12 Oct 2005, Duncan Murdoch wrote: > [EMAIL PROTECTED] wrote: >> Full_Name: Ian G I've never encountered anyone with full surname `G' >> Version: latest > > Please tell us which version. There are at least three versions which > might be called "latest", and by tomorrow two of them may well be different. > >> OS: win xp pro sp1 >> Submission from: (NULL) (193.1.209.251) >> >> >> step one >> start the r project any way you like >> step two >> type "demo()" and press return >> step three >> press then shortcut button to open file 'just under the file menu' >> while then demp screen is up >> the program seem not to like to open a new file when the window demo window >> is >> active. >> the error can be reproduce easly. > > Not reproducible for me in 2.2.0. Things worked just as I'd expect. > > Duncan Murdoch > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rgl package demo causes R memory corruption under Windows
Dominick Samperi wrote: > Hello, > > Running the rgl demo package (demo(rgl)) causes memory corruption when > used with > R 2.2.0 under Windows. I tested on two Windows systems: Windows 2000 and > Windows XP. > > When you terminate R after running the demo you get a message about the > application > trying to reference invalid memory. If you try to run another > application in R after running > the rgl demo it typically fails. > > Dominick > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel Dominick, this report is package related. Please contact the package maintainer who might be willing to help to debug on your machine. I cannot reproduce this neither on Windows NT4 SP6 nor on Windows Server 2003 SP1. Uwe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rgl package demo causes R memory corruption under Windows
It does not fail for me either (on Windows XP). I suspect it is hardware-related, that is that the GL support of the video driver may be implicated. I see no evidence of `R memory corruption' as distinct from `memory corruption to the R process'. On Thu, 13 Oct 2005, Uwe Ligges wrote: > Dominick Samperi wrote: > >> Hello, >> >> Running the rgl demo package (demo(rgl)) causes memory corruption when >> used with >> R 2.2.0 under Windows. I tested on two Windows systems: Windows 2000 and >> Windows XP. >> >> When you terminate R after running the demo you get a message about the >> application >> trying to reference invalid memory. If you try to run another >> application in R after running >> the rgl demo it typically fails. >> >> Dominick >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > Dominick, > > this report is package related. Please contact the package maintainer > who might be willing to help to debug on your machine. > I cannot reproduce this neither on Windows NT4 SP6 nor on Windows Server > 2003 SP1. > > Uwe > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R, Wine, and multi-threadedness.
Hi, I managed to install Win32 R 2.2.0 with the CRAN Innosetup installer under Wine on x86 linux a few days ago. However, on trying to run it, MSVCP60.DLL is missing. So here is a sort of a bug report, and a couple of questions: (1) I think the R binary in the CRAN Innosetup installer was built with mingw. The R-windows FAQ did mention that this DLL is required *for Chinese/Japanese/Korean* (which I wasn't trying to do). In this circumstance, it isn't particularly legal to copy the dll from elsewhere. So I would suggest enhancing R-windows FAQ and even the main R FAQ for this... also, is it possible *not* to have this dependency, or have it runtime-determined (i.e. try to load the dll dynamically, and fall back to US/ascii only when unsuccessful)? (2) The interesting question: As I understand it (could be wrong), R Win32 is (partly) multi-threaded, and the native linux R is not. Is is possible to have better performance or CPU utilisation on multi-CPU systems running Win32 R under Wine rather than natively? At least on certain specific application areas? Regards, Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
Duncan Murdoch wrote: > It's possible you have the wrong R.dll installed, because I don't see > any dependency on that file in the no-mbcs version of Rgui.exe or R.dll. > Do you have pedump? Can you see imports from MSVCP60.DLL in your copy > of R.dll? I don't currently have pedump, but I have used it before and I can get it. I'll have a look around the R-shipped dll's and will report back. During the installation, I just picked "English". Apparently the extra DLL dependency is just for wide-char support? Is the English version sensitive to Locale? My LANG is set to "en_GB.UTF-8" as is most recent Redhat linux systems, and Wine probably does strange things with it. (and I have some CJK fonts installed). >> (2) The interesting question: As I understand it (could be wrong), >> R Win32 is (partly) multi-threaded, and the native linux R is not. >> Is is possible to have better performance or CPU utilisation >> on multi-CPU systems running Win32 R under Wine rather than natively? >> At least on certain specific application areas? > > > I doubt it, but you'll have to try. R uses two threads on Windows so > that it can respond to Windows messages (repainting, etc.). It won't > really offload any substantial amount of computation to a second CPU. Wine on linux most of the time consists of at least two processes, with a "wine server" process doing screen drawings, etc. Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 13 Oct 2005, Hin-Tak Leung wrote: > I managed to install Win32 R 2.2.0 with the CRAN Innosetup > installer under Wine on x86 linux a few days ago. However, on trying > to run it, MSVCP60.DLL is missing. So here is a sort of a bug > report, and a couple of questions: This is a sort of bug report on your report. The rw-FAQ makes clear that DLL is _only_ required by R if you select East Asian support, and that is not the default. It seems you chose a non-default option. Please go back and reinstall R without East Asian support. > (1) I think the R binary in the CRAN Innosetup installer was built with > mingw. The R-windows FAQ did mention that this DLL is required *for > Chinese/Japanese/Korean* (which I wasn't trying to do). In this > circumstance, it isn't particularly legal to copy the dll from > elsewhere. So I would suggest enhancing R-windows FAQ and even the main > R FAQ for this... For what? As far as we know the rw-FAQ is accurate about all the dependencies. (Note that all current and recently obselete versions of Windows do have it, so its absence is a problem of Wine, not for Windows users of R.) > also, is it possible *not* to have this dependency, > or have it runtime-determined (i.e. try to load the dll dynamically, > and fall back to US/ascii only when unsuccessful)? The MinGW project assumes a tolerably recent version of Windows (from 2000 or later). It would be tricky to have MSVCP60.dll loaded and linked on demand, but not impossible (and it was considered not to be a worthwile use of the core group's time). We look forwards to your contributing code to do so if you think it is worthwhile. > (2) The interesting question: As I understand it (could be wrong), > R Win32 is (partly) multi-threaded, and the native linux R is not. > Is is possible to have better performance or CPU utilisation > on multi-CPU systems running Win32 R under Wine rather than natively? > At least on certain specific application areas? Rterm.exe is multithreaded, but the second thread is only used for input. RGui.exe is singlethreaded. As R for Windows uses a DLL it is about the same speed (running Windows natively on the same hardware) as R under ix86 Linux using a shared library, and that is appreciably slower than R under ix86 Linux without (see the R-admin manual). R under Linux can make use of a multithreaded BLAS, but I know of none available for Windows. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
Prof Brian Ripley wrote: > On Thu, 13 Oct 2005, Hin-Tak Leung wrote: > >> I managed to install Win32 R 2.2.0 with the CRAN Innosetup >> installer under Wine on x86 linux a few days ago. However, on trying >> to run it, MSVCP60.DLL is missing. So here is a sort of a bug >> report, and a couple of questions: > > > This is a sort of bug report on your report. The rw-FAQ makes clear > that DLL is _only_ required by R if you select East Asian support, and > that is not the default. It seems you chose a non-default option. > Please go back and reinstall R without East Asian support. Sorry - indeed you are right. In my last attempt, I (blindly) selected every optional packages, and that includes East Asian support. R does work under wine if that option is not selected. However, that option is mixed in with other harmless options which obviously have no extra requirements (pdf docs, source files, etc) and dependencies, and that's somewhat misleading. I would suggest putting it on a separate screen (and an warning?) in the installer? I don't think I was particularly careless wanting to install every optional part - even without understanding the full implication of doing so. >> (1) I think the R binary in the CRAN Innosetup installer was built with >> mingw. The R-windows FAQ did mention that this DLL is required *for >> Chinese/Japanese/Korean* (which I wasn't trying to do). In this >> circumstance, it isn't particularly legal to copy the dll from >> elsewhere. So I would suggest enhancing R-windows FAQ and even the main >> R FAQ for this... > > > For what? As far as we know the rw-FAQ is accurate about all the > dependencies. This information can go into the main FAQ (under linux/wine). Part of the interests (besides the "multi-threadedness") is the GUI alternatives, which is a bit lacking on the unix front. > (Note that all current and recently obselete versions of Windows do have > it, so its absence is a problem of Wine, not for Windows users of R.) I did a search on Google, and this DLL is apparently not on win98 as shipped. >> also, is it possible *not* to have this dependency, >> or have it runtime-determined (i.e. try to load the dll dynamically, >> and fall back to US/ascii only when unsuccessful)? > > > The MinGW project assumes a tolerably recent version of Windows (from > 2000 or later). That's quite incorrect. Mingw makes little assumption in that regard. The dependency on that DLL among Mingw people seems to be quite well-known, but somewhat restricted to wide-char support. > It would be tricky to have MSVCP60.dll loaded and linked on demand, but > not impossible (and it was considered not to be a worthwile use of the > core group's time). We look forwards to your contributing code to do so > if you think it is worthwhile. The circumstance is somewhat more arguable in the other possibility of building a win32 executable, via a cross-compiler. There are also less proprietary alternatives, such as libiconv? >> (2) The interesting question: As I understand it (could be wrong), >> R Win32 is (partly) multi-threaded, and the native linux R is not. >> Is is possible to have better performance or CPU utilisation >> on multi-CPU systems running Win32 R under Wine rather than natively? >> At least on certain specific application areas? > > > Rterm.exe is multithreaded, but the second thread is only used for > input. RGui.exe is singlethreaded. As R for Windows uses a DLL it is > about the same speed (running Windows natively on the same hardware) as > R under ix86 Linux using a shared library, and that is appreciably > slower than R under ix86 Linux without (see the R-admin manual). R > under Linux can make use of a multithreaded BLAS, but I know of none > available for Windows. Is the Intel MKL not available form Windows? Somewhat surprising... Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building R on Windows
Hi, I"m a newbie on building R on Windows. I followed the instructions cited here, http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. Everything works fine up till when package base needs to be compiled. here is the error message, -- Making package base adding build stamp to DESCRIPTION Error in library.dynam(lib, package, package.lib) : shared library 'tools' not found Execution halted make[4]: *** [frontmatter] Error 1 make[3]: *** [all] Error 2 make[2]: *** [pkg-base] Error 2 make[1]: *** [rpackage] Error 2 make: *** [all] Error 2 Has anyone seen this error message before? Where can I find shared library tools? Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] how to compiler the package bundles
Dear R user: I would like to combine two packages together in one package, So how do I compiler these two package simultaneously? Would someone give me some suggestion? Thanks in advance!! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
On Thu, 13 Oct 2005, Jennifer Lai wrote: > Hi, > I"m a newbie on building R on Windows. I followed the instructions > cited here, > http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. > Everything works fine up till when package base needs to be compiled. > here is the error message, > > -- Making package base > adding build stamp to DESCRIPTION > Error in library.dynam(lib, package, package.lib) : >shared library 'tools' not found > Execution halted > make[4]: *** [frontmatter] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [pkg-base] Error 2 > make[1]: *** [rpackage] Error 2 > make: *** [all] Error 2 > > Has anyone seen this error message before? Where can I find shared > library tools? It was built at the bootstrapping phase, or should have been. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272860 (secr) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Installing R-2.2.0 package
Dear list,
I've just installed R-2.2.0 under Solaris and have a question about
installing packages. If a package fails to install for any reason and I go
to install another package, I get this message:
$ R-2.2.0-64bit --vanilla CMD INSTALL ~/srca/cran/RSQLite_0.4-0.tar.gz
ERROR: failed to lock directory
'/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
I can remove the lock directory by hand, and then the next package installs,
but this makes it quite difficult to download and install a batch of
packages from CRAN or Biocondctor! Is this lock directory a new feature with
R-2.2.0? Is there a work around in the R build itself or the installation
scripts?
Much thanks!!!
-
David P Dean
Research Informatics
PGRD Groton Labs
(860)-441-5053
[EMAIL PROTECTED]
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
Hin-Tak Leung wrote: > Prof Brian Ripley wrote: > >> On Thu, 13 Oct 2005, Hin-Tak Leung wrote: >>> (2) The interesting question: As I understand it (could be wrong), >>> R Win32 is (partly) multi-threaded, and the native linux R is not. >>> Is is possible to have better performance or CPU utilisation >>> on multi-CPU systems running Win32 R under Wine rather than natively? >>> At least on certain specific application areas? >> >> >> >> Rterm.exe is multithreaded, but the second thread is only used for >> input. RGui.exe is singlethreaded. As R for Windows uses a DLL it is >> about the same speed (running Windows natively on the same hardware) >> as R under ix86 Linux using a shared library, and that is appreciably >> slower than R under ix86 Linux without (see the R-admin manual). R >> under Linux can make use of a multithreaded BLAS, but I know of none >> available for Windows. > > > Is the Intel MKL not available form Windows? Somewhat surprising... Sorry to reply to my own post. Actually, FAQ 8.2 for r-on-windows and the netlib FAQ: http://cran.r-project.org/bin/windows/base/rw-FAQ.html#Can-I-use-a-fast-BLAS_003f http://www.netlib.org/blas/faq.html#9 seems to suggest otherwise - from what it says, (1) the BLAS dll can be conveniently replaced without recompiling, (2) most vendor BLAS implementations are multi-threaded. In fact the Atlas implementation is explicitly named in both places. Now, the interesting questions are: (1) is Atlas multi-threaded on *every* platform, or more specifically, on Windows?, (2) Can wine use the atlas dll under x86 linux? Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 13 Oct 2005, Hin-Tak Leung wrote: > Hin-Tak Leung wrote: >> Prof Brian Ripley wrote: >> >>> On Thu, 13 Oct 2005, Hin-Tak Leung wrote: > (2) The interesting question: As I understand it (could be wrong), R Win32 is (partly) multi-threaded, and the native linux R is not. Is is possible to have better performance or CPU utilisation on multi-CPU systems running Win32 R under Wine rather than natively? At least on certain specific application areas? >>> >>> >>> >>> Rterm.exe is multithreaded, but the second thread is only used for input. >>> RGui.exe is singlethreaded. As R for Windows uses a DLL it is about the >>> same speed (running Windows natively on the same hardware) as R under ix86 >>> Linux using a shared library, and that is appreciably slower than R under >>> ix86 Linux without (see the R-admin manual). R under Linux can make use >>> of a multithreaded BLAS, but I know of none available for Windows. >> >> >> Is the Intel MKL not available form Windows? Somewhat surprising... It is not as much available as msvcp60.dll, which you were complaining about. It has strict licence conditions, as well as compiler conditions (and MinGW does not use the same calling conventions as the compilers which are supported). It is certainly not straightforward how to use it with MinGW, and I rather doubt if it would work properly (the Goto BLAS only works partially). > Sorry to reply to my own post. > > Actually, FAQ 8.2 for r-on-windows and the netlib FAQ: > http://cran.r-project.org/bin/windows/base/rw-FAQ.html#Can-I-use-a-fast-BLAS_003f > http://www.netlib.org/blas/faq.html#9 > > seems to suggest otherwise - from what it says, (1) the BLAS dll can be > conveniently replaced without recompiling, (2) most vendor BLAS > implementations are multi-threaded. In fact the Atlas implementation > is explicitly named in both places. > > Now, the interesting questions are: (1) is Atlas multi-threaded on *every* > platform, or more specifically, on Windows?, By default it is not multi-threaded on any platform, and we have not succeeded in compiling a multi-threaded version on Windows except by using Cygwin extensions (i.e. not actually on Windows). > (2) Can wine use the atlas dll under x86 linux? `the atlas dll' being? The ATLAS-based Rblas.dlls on CRAN are not multithreaded. Who knows what wine can do? Please be more reasonable in your support requests. Yours is a rather unusual use, and we don't have time to support it. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
Dean, David P wrote:
> Dear list,
>
> I've just installed R-2.2.0 under Solaris and have a question about
> installing packages. If a package fails to install for any reason and I go
> to install another package, I get this message:
>
> $ R-2.2.0-64bit --vanilla CMD INSTALL ~/srca/cran/RSQLite_0.4-0.tar.gz
> ERROR: failed to lock directory
> '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
> Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>
> I can remove the lock directory by hand, and then the next package installs,
> but this makes it quite difficult to download and install a batch of
> packages from CRAN or Biocondctor! Is this lock directory a new feature with
> R-2.2.0? Is there a work around in the R build itself or the installation
> scripts?
No, not a new feature in R-2.2.0, it has been there for some time now.
After a *successful* installation, the 00LOCK directory should be
deleted by the installation tools themselves.
After an unsuccessful installation, the installation tools should
restore the stuff in the 00LOCK directory.
Do you abort the installtion manually (this is the only way I figured
out how not to remove 00LOCK automatically)?
Uwe Ligges
>
> Much thanks!!!
> -
> David P Dean
> Research Informatics
> PGRD Groton Labs
> (860)-441-5053
> [EMAIL PROTECTED]
> --
> LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
>
> __
> 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] Installing R-2.2.0 package
Uwe Ligges wrote:
>Dean, David P wrote:
>
>
>
>>Dear list,
>>
>>I've just installed R-2.2.0 under Solaris and have a question about
>>installing packages. If a package fails to install for any reason and I go
>>to install another package, I get this message:
>>
>>$ R-2.2.0-64bit --vanilla CMD INSTALL ~/srca/cran/RSQLite_0.4-0.tar.gz
>>ERROR: failed to lock directory
>>'/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
>>Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>>
>>I can remove the lock directory by hand, and then the next package installs,
>>but this makes it quite difficult to download and install a batch of
>>packages from CRAN or Biocondctor! Is this lock directory a new feature with
>>R-2.2.0? Is there a work around in the R build itself or the installation
>>scripts?
>>
>>
>
>No, not a new feature in R-2.2.0, it has been there for some time now.
>
>
I have the impression the feature behaves slightly differently as of
R-2.2.0. Now the 00LOCK file is not removed in Solaris when there is an
unsuccessful install. (In Linux I think it does get removed.)
Paul Gilbert
>After a *successful* installation, the 00LOCK directory should be
>deleted by the installation tools themselves.
>After an unsuccessful installation, the installation tools should
>restore the stuff in the 00LOCK directory.
>Do you abort the installtion manually (this is the only way I figured
>out how not to remove 00LOCK automatically)?
>
>Uwe Ligges
>
>
>
>
>
>>Much thanks!!!
>>-
>>David P Dean
>>Research Informatics
>>PGRD Groton Labs
>>(860)-441-5053
>>[EMAIL PROTECTED]
>>--
>>LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
>>
>>__
>>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
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
Paul Gilbert wrote:
>
>
> Uwe Ligges wrote:
>
>> Dean, David P wrote:
>>
>>
>>
>>> Dear list,
>>>
>>> I've just installed R-2.2.0 under Solaris and have a question about
>>> installing packages. If a package fails to install for any reason and
>>> I go
>>> to install another package, I get this message:
>>>
>>> $ R-2.2.0-64bit --vanilla CMD INSTALL
>>> ~/srca/cran/RSQLite_0.4-0.tar.gz ERROR: failed to lock directory
>>> '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
>>> Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>>>
>>> I can remove the lock directory by hand, and then the next package
>>> installs,
>>> but this makes it quite difficult to download and install a batch of
>>> packages from CRAN or Biocondctor! Is this lock directory a new
>>> feature with
>>> R-2.2.0? Is there a work around in the R build itself or the
>>> installation
>>> scripts?
>>>
>>
>>
>> No, not a new feature in R-2.2.0, it has been there for some time now.
>>
>>
> I have the impression the feature behaves slightly differently as of
> R-2.2.0. Now the 00LOCK file is not removed in Solaris when there is an
> unsuccessful install. (In Linux I think it does get removed.)
Yes, under both Linux and Windows it is removed.
Can anybody else check on Solaris, please? Or can David Dean debug on
his machine?
In particular, we need exact system information, because it seems to be
an OS/platform specific problem.
Uwe Ligges
> Paul Gilbert
>
>> After a *successful* installation, the 00LOCK directory should be
>> deleted by the installation tools themselves.
>> After an unsuccessful installation, the installation tools should
>> restore the stuff in the 00LOCK directory.
>> Do you abort the installtion manually (this is the only way I figured
>> out how not to remove 00LOCK automatically)?
>>
>> Uwe Ligges
>>
>>
>>
>>
>>
>>> Much thanks!!!
>>> - David P Dean
>>> Research Informatics
>>> PGRD Groton Labs
>>> (860)-441-5053
>>> [EMAIL PROTECTED]
>>> --
>>> LEGAL NOTICE\ Unless expressly stated otherwise, this
>>> messag...{{dropped}}
>>>
>>> __
>>> 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
>>
>>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
It works on Solaris 8 for me, and this is checked as part of the
alpha/beta process.
The code is the same on Linux and Solaris, after all, so this would have
to be a Solaris shell bug.
On Thu, 13 Oct 2005, Uwe Ligges wrote:
> Paul Gilbert wrote:
>
>>
>>
>> Uwe Ligges wrote:
>>
>>> Dean, David P wrote:
>>>
>>>
>>>
Dear list,
I've just installed R-2.2.0 under Solaris and have a question about
installing packages. If a package fails to install for any reason and
I go
to install another package, I get this message:
$ R-2.2.0-64bit --vanilla CMD INSTALL
~/srca/cran/RSQLite_0.4-0.tar.gz ERROR: failed to lock directory
'/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
I can remove the lock directory by hand, and then the next package
installs,
but this makes it quite difficult to download and install a batch of
packages from CRAN or Biocondctor! Is this lock directory a new
feature with
R-2.2.0? Is there a work around in the R build itself or the
installation
scripts?
>>>
>>>
>>> No, not a new feature in R-2.2.0, it has been there for some time now.
>>>
>>>
>> I have the impression the feature behaves slightly differently as of
>> R-2.2.0. Now the 00LOCK file is not removed in Solaris when there is an
>> unsuccessful install. (In Linux I think it does get removed.)
>
> Yes, under both Linux and Windows it is removed.
>
> Can anybody else check on Solaris, please? Or can David Dean debug on
> his machine?
>
> In particular, we need exact system information, because it seems to be
> an OS/platform specific problem.
>
> Uwe Ligges
>
>
>
>
>> Paul Gilbert
>>
>>> After a *successful* installation, the 00LOCK directory should be
>>> deleted by the installation tools themselves.
>>> After an unsuccessful installation, the installation tools should
>>> restore the stuff in the 00LOCK directory.
>>> Do you abort the installtion manually (this is the only way I figured
>>> out how not to remove 00LOCK automatically)?
>>>
>>> Uwe Ligges
>>>
>>>
>>>
>>>
>>>
Much thanks!!!
- David P Dean
Research Informatics
PGRD Groton Labs
(860)-441-5053
[EMAIL PROTECTED]
--
LEGAL NOTICE\ Unless expressly stated otherwise, this
messag...{{dropped}}
__
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
>>>
>>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
Prof Brian Ripley wrote: >> Now, the interesting questions are: (1) is Atlas multi-threaded on >> *every* platform, or more specifically, on Windows?, > > > By default it is not multi-threaded on any platform, and we have not > succeeded in compiling a multi-threaded version on Windows except by > using Cygwin extensions (i.e. not actually on Windows). Thanks for the explanations. As I said, my main interests in running R under Wine is mostly about having a GUI, but the multi-threading possibility is an interesting discussion; also re-compiling the whole lot (either for win32 or linux) just for the *possibility* of speeding up is a bit painful, so having drop-in dll replacement (or a shared-library replacement) for trying-out sounds rather attractive. >> (2) Can wine use the atlas dll under x86 linux? > > `the atlas dll' being? The ATLAS-based Rblas.dlls on CRAN are not > multithreaded. Who knows what wine can do? Thanks for stating that. It wasn't clear that the Atlas-based Rblas is not multi-threaded. > Please be more reasonable in your support requests. Yours is a rather > unusual use, and we don't have time to support it. Thanks for the detailed explanations about threading implementations. that's what I was after. Most of what I said is throwing ideas about, really. As for the issue with msvcp60.dll, I am really sorry about it - but since one of you had bothered enough to write an FAQ item for it, I cannot be the first one getting bitten? It would be a good deal more useful to separate that option from the other harmless ones in the Innosetup installer, and/or shouldn't be too much effort to say, put it last instead or somehow mark it out differently or even add a note at the same screen instead? e.g. "**The Far East support options requires that you have Far East support in Windows**" (there are win32 software which can do CJK without OS support; e.g. some version of Acrobat reader is known to run under Wine, and I would expect it doesn't need extra windows bits to view CJK pdf's)...the misleading part was that the other additional options are absolutely harmless. Thanks a lot for the discussion. If I find any interesting R issues under Wine, I'll report back. Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 13, 2005 11:42 AM
> To: Uwe Ligges
> Cc: Paul Gilbert; r-devel@r-project.org; Dean, David P
> Subject: Re: [Rd] Installing R-2.2.0 package
>
> It works on Solaris 8 for me, and this is checked as part of the
> alpha/beta process.
>
> The code is the same on Linux and Solaris, after all, so this would have
> to be a Solaris shell bug.
I'm on Solaris 8 as well. R is compiled for 64-bits, but I wouldn't expect
that to be a factor. R was built and is run in an environment created with
OpenPKG and containing GNU equivalents to many utilities -- so it's not a
stock Solaris setup.
I'm not familiar with R internals but will be happy to try to debug if I
can. Does the installer call out to the shell somehow? Where would I start
to look for the relevant code?
Thanks!
David Dean
> On Thu, 13 Oct 2005, Uwe Ligges wrote:
>
> > Paul Gilbert wrote:
> >
> >>
> >>
> >> Uwe Ligges wrote:
> >>
> >>> Dean, David P wrote:
> >>>
> >>>
> >>>
> Dear list,
>
> I've just installed R-2.2.0 under Solaris and have a question about
> installing packages. If a package fails to install for any reason and
> I go
> to install another package, I get this message:
>
> $ R-2.2.0-64bit --vanilla CMD INSTALL
> ~/srca/cran/RSQLite_0.4-0.tar.gz ERROR: failed to lock directory
> '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
> Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>
> I can remove the lock directory by hand, and then the next package
> installs,
> but this makes it quite difficult to download and install a batch of
> packages from CRAN or Biocondctor! Is this lock directory a new
> feature with
> R-2.2.0? Is there a work around in the R build itself or the
> installation
> scripts?
>
> >>>
> >>>
> >>> No, not a new feature in R-2.2.0, it has been there for some time now.
> >>>
> >>>
> >> I have the impression the feature behaves slightly differently as of
> >> R-2.2.0. Now the 00LOCK file is not removed in Solaris when there is an
> >> unsuccessful install. (In Linux I think it does get removed.)
> >
> > Yes, under both Linux and Windows it is removed.
> >
> > Can anybody else check on Solaris, please? Or can David Dean debug on
> > his machine?
> >
> > In particular, we need exact system information, because it seems to be
> > an OS/platform specific problem.
> >
> > Uwe Ligges
> >
> >
> >
> >
> >> Paul Gilbert
> >>
> >>> After a *successful* installation, the 00LOCK directory should be
> >>> deleted by the installation tools themselves.
> >>> After an unsuccessful installation, the installation tools should
> >>> restore the stuff in the 00LOCK directory.
> >>> Do you abort the installtion manually (this is the only way I figured
> >>> out how not to remove 00LOCK automatically)?
> >>>
> >>> Uwe Ligges
> >>>
> >>>
> >>>
> >>>
> >>>
> Much thanks!!!
> - David P Dean
> Research Informatics
> PGRD Groton Labs
> (860)-441-5053
> [EMAIL PROTECTED]
> -
> -
> LEGAL NOTICE\ Unless expressly stated otherwise, this
> messag...{{dropped}}
>
> __
> 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
> >>>
> >>>
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 2005-10-13 at 16:45 +0100, Hin-Tak Leung wrote: > Prof Brian Ripley wrote: > > >> Now, the interesting questions are: (1) is Atlas multi-threaded on > >> *every* platform, or more specifically, on Windows?, > > > > > > By default it is not multi-threaded on any platform, and we have not > > succeeded in compiling a multi-threaded version on Windows except by > > using Cygwin extensions (i.e. not actually on Windows). > > Thanks for the explanations. As I said, my main interests in running > R under Wine is mostly about having a GUI, but the multi-threading > possibility is an interesting discussion; also re-compiling > the whole lot (either for win32 or linux) just for the *possibility* of > speeding up is a bit painful, so having drop-in dll replacement > (or a shared-library replacement) for trying-out sounds rather attractive. Sorry for jumping in here and no disrespect intended to anyone, but I am confused relative to the desire and benefits of running R under Wine on Linux simply for the sake of using the RGui.exe menus, when there are other substantive tradeoffs relative to running R natively on Linux, as Prof. Ripley has noted. The one "advantage" that I had seen some time ago, was the possibility of being able to generate metafile graphics for inclusion with MS Office apps by using the native Windows libs (in a dual-boot scenario as I recall). However other substantively better options for generating high quality graphics have been proposed and discussed here frequently. If you want a more "full featured" GUI, if you are uncomfortable coding from the command line, there is a list available at: http://www.sciviews.org/_rgui/ some of which are cross-platform compatible. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 13 Oct 2005, Marc Schwartz (via MN) wrote: > On Thu, 2005-10-13 at 16:45 +0100, Hin-Tak Leung wrote: >> Prof Brian Ripley wrote: >> Now, the interesting questions are: (1) is Atlas multi-threaded on *every* platform, or more specifically, on Windows?, >>> >>> >>> By default it is not multi-threaded on any platform, and we have not >>> succeeded in compiling a multi-threaded version on Windows except by >>> using Cygwin extensions (i.e. not actually on Windows). >> >> Thanks for the explanations. As I said, my main interests in running >> R under Wine is mostly about having a GUI, but the multi-threading >> possibility is an interesting discussion; also re-compiling >> the whole lot (either for win32 or linux) just for the *possibility* of >> speeding up is a bit painful, so having drop-in dll replacement >> (or a shared-library replacement) for trying-out sounds rather attractive. > > Sorry for jumping in here and no disrespect intended to anyone, but I am > confused relative to the desire and benefits of running R under Wine on > Linux simply for the sake of using the RGui.exe menus, when there are > other substantive tradeoffs relative to running R natively on Linux, as > Prof. Ripley has noted. One reason for doing so is to be able to prepare for teaching in a Windows environment: I believe this is why it is mentioned in the FAQ. (I personally test on the machine to be used just to be sure things work.) > The one "advantage" that I had seen some time ago, was the possibility > of being able to generate metafile graphics for inclusion with MS Office > apps by using the native Windows libs (in a dual-boot scenario as I > recall). However other substantively better options for generating high > quality graphics have been proposed and discussed here frequently. I am not 100% convinced that they are `substantively better' in all environments, and I still do that sometimes. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
On Thu, 13 Oct 2005, Dean, David P wrote:
>> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 13, 2005 11:42 AM
>> To: Uwe Ligges
>> Cc: Paul Gilbert; r-devel@r-project.org; Dean, David P
>> Subject: Re: [Rd] Installing R-2.2.0 package
>>
>> It works on Solaris 8 for me, and this is checked as part of the
>> alpha/beta process.
>>
>> The code is the same on Linux and Solaris, after all, so this would have
>> to be a Solaris shell bug.
>
> I'm on Solaris 8 as well. R is compiled for 64-bits, but I wouldn't expect
> that to be a factor.
I tested this on a 64-bit setup, as it happens.
> R was built and is run in an environment created with
> OpenPKG and containing GNU equivalents to many utilities -- so it's not a
> stock Solaris setup.
I hope /bin/sh is Solaris and not bash.
> I'm not familiar with R internals but will be happy to try to debug if I
> can. Does the installer call out to the shell somehow? Where would I start
> to look for the relevant code?
INSTALL _is_ a shell script.
Rather than mess about with past code, can you first please try the
current R-patched (see the FAQ) as I will shortly not have R-2.2.0 on
Solaris but rather R-patched (I already have R-devel in 4 flavours).
>
> Thanks!
> David Dean
>> On Thu, 13 Oct 2005, Uwe Ligges wrote:
>>
>>> Paul Gilbert wrote:
>>>
Uwe Ligges wrote:
> Dean, David P wrote:
>
>
>
>> Dear list,
>>
>> I've just installed R-2.2.0 under Solaris and have a question about
>> installing packages. If a package fails to install for any reason and
>> I go
>> to install another package, I get this message:
>>
>> $ R-2.2.0-64bit --vanilla CMD INSTALL
>> ~/srca/cran/RSQLite_0.4-0.tar.gz ERROR: failed to lock directory
>> '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
>> Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>>
>> I can remove the lock directory by hand, and then the next package
>> installs,
>> but this makes it quite difficult to download and install a batch of
>> packages from CRAN or Biocondctor! Is this lock directory a new
>> feature with
>> R-2.2.0? Is there a work around in the R build itself or the
>> installation
>> scripts?
>>
>
>
> No, not a new feature in R-2.2.0, it has been there for some time now.
>
>
I have the impression the feature behaves slightly differently as of
R-2.2.0. Now the 00LOCK file is not removed in Solaris when there is an
unsuccessful install. (In Linux I think it does get removed.)
>>>
>>> Yes, under both Linux and Windows it is removed.
>>>
>>> Can anybody else check on Solaris, please? Or can David Dean debug on
>>> his machine?
>>>
>>> In particular, we need exact system information, because it seems to be
>>> an OS/platform specific problem.
>>>
>>> Uwe Ligges
>>>
>>>
>>>
>>>
Paul Gilbert
> After a *successful* installation, the 00LOCK directory should be
> deleted by the installation tools themselves.
> After an unsuccessful installation, the installation tools should
> restore the stuff in the 00LOCK directory.
> Do you abort the installtion manually (this is the only way I figured
> out how not to remove 00LOCK automatically)?
>
> Uwe Ligges
>
>
>
>
>
>> Much thanks!!!
>> - David P Dean
>> Research Informatics
>> PGRD Groton Labs
>> (860)-441-5053
>> [EMAIL PROTECTED]
>> -
>> -
>> LEGAL NOTICE\ Unless expressly stated otherwise, this
>> messag...{{dropped}}
>>
>> __
>> 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
>
>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>> --
>> Brian D. Ripley, [EMAIL PROTECTED]
>> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
>> University of Oxford, Tel: +44 1865 272861 (self)
>> 1 South Parks Road, +44 1865 272866 (PA)
>> Oxford OX1 3TG, UKFax: +44 1865 272595
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
___
Re: [Rd] Installing R-2.2.0 package
I'm using SunOS 5.8, R compiled as a 32 bit app, and I didn't intend to
set up anything special. Below is an example installing RMySQL (twice).
The error the second time is because of the lock file. I think
ERROR: configuration failed for package 'RMySQL'
/apps/asd/unix/gnu/R/SunOS-sparc32/R-2.2.0/bin/INSTALL: test: argument
expected
may be a clue.
(BTW. If there is a simple answer to the libz problem then I would
appreciate hearing.)
Paul Gilbert
> install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
"http://cran.at.r-project.org";)
trying URL 'http://cran.at.r-project.org/src/contrib/RMySQL_0.5-5.tar.gz'
Content type 'application/x-tar' length 280328 bytes
opened URL
==
downloaded 273Kb
* Installing *source* package 'RMySQL' ...
creating cache ./config.cache
checking how to run the C preprocessor... /lib/cpp
checking for compress in -lz... no
checking for getopt_long in -lc... no
checking for mysql_init in -lmysqlclient... no
checking for mysql.h... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
checking for mysql_init in -lmysqlclient... no
Configuration error:
Could not locate the library "libz" required by MySQL.
INSTRUCTIONS:
The "libz" library is required by the MySQL client library
in order to compress/uncompress connections between clients
and the MySQL engine.
Make sure you have "libz" installed properly and/or included
in your $LD_LIBRARY_PATH. Perhaps it is not in any of the
standard directories (e.g., /usr/lib/, /usr/local/lib)?
Aborting the installation of RMySQL.
ERROR: configuration failed for package 'RMySQL'
/apps/asd/unix/gnu/R/SunOS-sparc32/R-2.2.0/bin/INSTALL: test: argument
expected
The downloaded packages are in
/tmp/Rtmp26660/downloaded_packages
Warning message:
installation of package 'RMySQL' had non-zero exit status in:
install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
"http://cran.at.r-project.org";)
> install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
"http://cran.at.r-project.org";)
trying URL 'http://cran.at.r-project.org/src/contrib/RMySQL_0.5-5.tar.gz'
Content type 'application/x-tar' length 280328 bytes
opened URL
==
downloaded 273Kb
ERROR: failed to lock directory
'/home/asd9/gnu/R/SunOS-sparc32/R-2.2.0/site-library' for modifying
Try removing '/home/asd9/gnu/R/SunOS-sparc32/R-2.2.0/site-library/00LOCK'
The downloaded packages are in
/tmp/Rtmp26660/downloaded_packages
Warning message:
installation of package 'RMySQL' had non-zero exit status in:
install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
"http://cran.at.r-project.org";)
>
Dean, David P wrote:
>>From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, October 13, 2005 11:42 AM
>>To: Uwe Ligges
>>Cc: Paul Gilbert; r-devel@r-project.org; Dean, David P
>>Subject: Re: [Rd] Installing R-2.2.0 package
>>
>>It works on Solaris 8 for me, and this is checked as part of the
>>alpha/beta process.
>>
>>The code is the same on Linux and Solaris, after all, so this would have
>>to be a Solaris shell bug.
>>
>>
>
>I'm on Solaris 8 as well. R is compiled for 64-bits, but I wouldn't expect
>that to be a factor. R was built and is run in an environment created with
>OpenPKG and containing GNU equivalents to many utilities -- so it's not a
>stock Solaris setup.
>
>I'm not familiar with R internals but will be happy to try to debug if I
>can. Does the installer call out to the shell somehow? Where would I start
>to look for the relevant code?
>
>Thanks!
>David Dean
>
>
>>On Thu, 13 Oct 2005, Uwe Ligges wrote:
>>
>>
>>
>>>Paul Gilbert wrote:
>>>
>>>
>>>
Uwe Ligges wrote:
>Dean, David P wrote:
>
>
>
>
>
>>Dear list,
>>
>>I've just installed R-2.2.0 under Solaris and have a question about
>>installing packages. If a package fails to install for any reason and
>>I go
>>to install another package, I get this message:
>>
>>$ R-2.2.0-64bit --vanilla CMD INSTALL
>>~/srca/cran/RSQLite_0.4-0.tar.gz ERROR: failed to lock directory
>>'/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
>>Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>>
>>I can remove the lock directory by hand, and then the next package
>>installs,
>>but this makes it quite difficult to download and install a batch of
>>packages from CRAN or Biocondctor! Is this lock directory a new
>>feature with
>>R-2.2.0? Is there a work around in the R build itself or the
>>installation
>>scripts?
>>
>>
>>
>No, not a new feature in R-2.2.0, it has been there for some time now.
>
>
>
>
I have the impre
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 2005-10-13 at 17:19 +0100, Prof Brian Ripley wrote: > On Thu, 13 Oct 2005, Marc Schwartz (via MN) wrote: > > > On Thu, 2005-10-13 at 16:45 +0100, Hin-Tak Leung wrote: > >> Prof Brian Ripley wrote: > >> > Now, the interesting questions are: (1) is Atlas multi-threaded on > *every* platform, or more specifically, on Windows?, > >>> > >>> > >>> By default it is not multi-threaded on any platform, and we have not > >>> succeeded in compiling a multi-threaded version on Windows except by > >>> using Cygwin extensions (i.e. not actually on Windows). > >> > >> Thanks for the explanations. As I said, my main interests in running > >> R under Wine is mostly about having a GUI, but the multi-threading > >> possibility is an interesting discussion; also re-compiling > >> the whole lot (either for win32 or linux) just for the *possibility* of > >> speeding up is a bit painful, so having drop-in dll replacement > >> (or a shared-library replacement) for trying-out sounds rather attractive. > > > > Sorry for jumping in here and no disrespect intended to anyone, but I am > > confused relative to the desire and benefits of running R under Wine on > > Linux simply for the sake of using the RGui.exe menus, when there are > > other substantive tradeoffs relative to running R natively on Linux, as > > Prof. Ripley has noted. > > One reason for doing so is to be able to prepare for teaching in a Windows > environment: I believe this is why it is mentioned in the FAQ. (I > personally test on the machine to be used just to be sure things work.) Good point. I had not considered that, not being in a teaching environment. Running on a laptop, I always have a known machine with me, even when doing presentations in front of a group/audience. > > The one "advantage" that I had seen some time ago, was the possibility > > of being able to generate metafile graphics for inclusion with MS Office > > apps by using the native Windows libs (in a dual-boot scenario as I > > recall). However other substantively better options for generating high > > quality graphics have been proposed and discussed here frequently. > > I am not 100% convinced that they are `substantively better' in all > environments, and I still do that sometimes. No disagreement if there is a specific need for this. Where that need is present, this is a better solution than using the Linux native libEMF functionality, which is problematic as has been discussed in those same threads. I was more focused (and confused) on the Rgui.exe menus as the principal justification for taking this approach, but again, perhaps I am lacking context. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
On Thu, 13 Oct 2005, Paul Gilbert wrote:
> I'm using SunOS 5.8, R compiled as a 32 bit app, and I didn't intend to
> set up anything special. Below is an example installing RMySQL (twice).
> The error the second time is because of the lock file. I think
>
> ERROR: configuration failed for package 'RMySQL'
> /apps/asd/unix/gnu/R/SunOS-sparc32/R-2.2.0/bin/INSTALL: test: argument
> expected
>
> may be a clue.
Please try R-patched, as I think it might already have been fixed (by
adding quotes for a different reason).
> (BTW. If there is a simple answer to the libz problem then I would
> appreciate hearing.)
Simple: install it.
> Paul Gilbert
>
> > install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
> "http://cran.at.r-project.org";)
> trying URL 'http://cran.at.r-project.org/src/contrib/RMySQL_0.5-5.tar.gz'
> Content type 'application/x-tar' length 280328 bytes
> opened URL
> ==
> downloaded 273Kb
>
> * Installing *source* package 'RMySQL' ...
> creating cache ./config.cache
> checking how to run the C preprocessor... /lib/cpp
> checking for compress in -lz... no
> checking for getopt_long in -lc... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql.h... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
> checking for mysql_init in -lmysqlclient... no
>
> Configuration error:
> Could not locate the library "libz" required by MySQL.
>
> INSTRUCTIONS:
>
> The "libz" library is required by the MySQL client library
> in order to compress/uncompress connections between clients
> and the MySQL engine.
>
> Make sure you have "libz" installed properly and/or included
> in your $LD_LIBRARY_PATH. Perhaps it is not in any of the
> standard directories (e.g., /usr/lib/, /usr/local/lib)?
>
> Aborting the installation of RMySQL.
>
> ERROR: configuration failed for package 'RMySQL'
> /apps/asd/unix/gnu/R/SunOS-sparc32/R-2.2.0/bin/INSTALL: test: argument
> expected
>
> The downloaded packages are in
>/tmp/Rtmp26660/downloaded_packages
> Warning message:
> installation of package 'RMySQL' had non-zero exit status in:
> install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
> "http://cran.at.r-project.org";)
> > install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
> "http://cran.at.r-project.org";)
> trying URL 'http://cran.at.r-project.org/src/contrib/RMySQL_0.5-5.tar.gz'
> Content type 'application/x-tar' length 280328 bytes
> opened URL
> ==
> downloaded 273Kb
>
> ERROR: failed to lock directory
> '/home/asd9/gnu/R/SunOS-sparc32/R-2.2.0/site-library' for modifying
> Try removing '/home/asd9/gnu/R/SunOS-sparc32/R-2.2.0/site-library/00LOCK'
>
> The downloaded packages are in
>/tmp/Rtmp26660/downloaded_packages
> Warning message:
> installation of package 'RMySQL' had non-zero exit status in:
> install.packages(c("RMySQL"), Sys.getenv("R_LIBS"), repos =
> "http://cran.at.r-project.org";)
> >
>
>
> Dean, David P wrote:
>
>>> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
>>> Sent: Thursday, October 13, 2005 11:42 AM
>>> To: Uwe Ligges
>>> Cc: Paul Gilbert; r-devel@r-project.org; Dean, David P
>>> Subject: Re: [Rd] Installing R-2.2.0 package
>>>
>>> It works on Solaris 8 for me, and this is checked as part of the
>>> alpha/beta process.
>>>
>>> The code is the same on Linux and Solaris, after all, so this would have
>>> to be a Solaris shell bug.
>>>
>>>
>>
>> I'm on Solaris 8 as well. R is compiled for 64-bits, but I wouldn't expect
>> that to be a factor. R was built and is run in an environment created with
>> OpenPKG and containing GNU equivalents to many utilities -- so it's not a
>> stock Solaris setup.
>>
>> I'm not familiar with R internals but will be happy to try to debug if I
>> can. Does the installer call out to the shell somehow? Where would I start
>> to look for the relevant code?
>>
>> Thanks!
>> David Dean
>>
>>
>>> On Thu, 13 Oct 2005, Uwe Ligges wrote:
>>>
>>>
>>>
Paul Gilbert wrote:
> Uwe Ligges wrote:
>
>
>
>> Dean, David P wrote:
>>
>>
>>
>>
>>
>>> Dear list,
>>>
>>> I've just installed R-2.2.0 under Solaris and have a question about
>>> installing packages. If a package fails to install for any reason and
>>> I go
>>> to install another package, I get this message:
>>>
>>> $ R-2.2.0-64bit --vanilla CMD INSTALL
>>> ~/srca/cran/RSQLite_0.4-0.tar.gz ERROR: failed to lock directory
>>> '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library' for modifying
>>> Try removing '/app/openpkg/lib/R-2.2.0-64bit/lib/R/library/00LOCK'
>>>
>>> I can remove the lock directory by hand, and then the next package
>>> installs,
>>> but this makes it quite difficult to download and install a batch
Re: [Rd] R, Wine, and multi-threadedness.
Prof Brian Ripley wrote: > On Thu, 13 Oct 2005, Marc Schwartz (via MN) wrote: >>Sorry for jumping in here and no disrespect intended to anyone, but I am >>confused relative to the desire and benefits of running R under Wine on >>Linux simply for the sake of using the RGui.exe menus, when there are >>other substantive tradeoffs relative to running R natively on Linux, as >>Prof. Ripley has noted. > > > One reason for doing so is to be able to prepare for teaching in a Windows > environment: I believe this is why it is mentioned in the FAQ. (I > personally test on the machine to be used just to be sure things work.) I agree; and being able to discuss it with another user who may be on windows. Having alternatives and choices is good. Actually my earlier failed incentive was to run the Sciview-R GUI. It most certainly looks very useful and functional from the screenshots, and I dare say it is probably one of the best available - it is hard to imagine one "better" - the unix fanatics around me told me about ESS and I do have it installed and configured, but it isn't anywhere close to the Sciview-R GUI - sadly it is heavily .NET based and won't run under wine, which only recently moved to emulate 2k as default and have very little support for xp, 2k3 and the more security-conscious part of the NT families. I did install sciview-R successfully, but as soon as I see the manifest files, I realise it won't run under wine, not a hope. Would be interesting to see if they are can port that to GTK#/mono on linux. >>The one "advantage" that I had seen some time ago, was the possibility >>of being able to generate metafile graphics for inclusion with MS Office >>apps by using the native Windows libs (in a dual-boot scenario as I >>recall). However other substantively better options for generating high >>quality graphics have been proposed and discussed here frequently. > > > I am not 100% convinced that they are `substantively better' in all > environments, and I still do that sometimes. I agree on principle - until the linux port can do *exactly* the same thing better and more, "substantively better" is a rather subjective description and is just for the fanatics. If it is missing just one feature, like WMF export - and since microsoft is not going bankrupt any time soon, MS office integration is fairly important to *some* people - one cannot say it is 'substantially better', because there is always one user who would judge that one missing feature, over and above any other advantage. Some software on linux uses libwmf for wmf import/export (I believe it is gimp). Maybe R can do the same. Hin-Tak Leung. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
Marc Schwartz (via MN) wrote: > I was more focused (and confused) on the Rgui.exe menus as the principal > justification for taking this approach, but again, perhaps I am lacking > context. I think you are confused about Rgui.exe, versus "having a GUI for R" (which is what I wrote - I never wrote "Rgui.exe", as that was *not* what I meant all along). I did try but failed with the Sciview-R - it would install but won't run. Since the actual GUI faq is hosted by sciview on "http://www.sciviews.org/_rgui/"; as you pointed out, by association, my first guess was that it is a good bet to try the Sciview-R one first. If anybody can name a "better" GUI than sciview-R, windows or linux, I am all ears - "better" in any sense of the word, preferably not in the ESS sense, as I already have that - nothing obviously against it, but I like alternatives, preferably covering different usage areas. Before anybody jump in again, the fact that sciview-R is somewhat .NET framework dependent (at least the binary installed by the default installer seems to be) is justifiably a development issue? Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 2005-10-13 at 18:02 +0100, Hin-Tak Leung wrote: > Prof Brian Ripley wrote: > > On Thu, 13 Oct 2005, Marc Schwartz (via MN) wrote: > > >>Sorry for jumping in here and no disrespect intended to anyone, but I am > >>confused relative to the desire and benefits of running R under Wine on > >>Linux simply for the sake of using the RGui.exe menus, when there are > >>other substantive tradeoffs relative to running R natively on Linux, as > >>Prof. Ripley has noted. > > > > > > One reason for doing so is to be able to prepare for teaching in a Windows > > environment: I believe this is why it is mentioned in the FAQ. (I > > personally test on the machine to be used just to be sure things work.) > > I agree; and being able to discuss it with another user who may be > on windows. Having alternatives and choices is good. No disagreement that choice is good and that is a significant predicate in the open source world. Please don't misconstrue my comments as being in the context of pure Linux advocacy. They are not. It was more to gain an understanding of the requirements you have to comprehend the desire to take this particular approach and to differentiate specific "isolated" requirements versus day-to-day routine needs. > Actually my earlier failed incentive was to run the Sciview-R GUI. It > most certainly looks very useful and functional from the screenshots, > and I dare say it is probably one of the best available - it is hard > to imagine one "better" - the unix fanatics around me told me about > ESS and I do have it installed and configured, but it isn't > anywhere close to the Sciview-R GUI - sadly it is heavily .NET based > and won't run under wine, which only recently moved to emulate 2k > as default and have very little support for xp, 2k3 and the > more security-conscious part of the NT families. I did install > sciview-R successfully, but as soon as I see the manifest files, > I realise it won't run under wine, not a hope. > > Would be interesting to see if they are can port that to GTK#/mono > on linux. Perhaps you would be willing to contribute your time to make that happen, presuming that the technical hurdles are resolvable. > >>The one "advantage" that I had seen some time ago, was the possibility > >>of being able to generate metafile graphics for inclusion with MS Office > >>apps by using the native Windows libs (in a dual-boot scenario as I > >>recall). However other substantively better options for generating high > >>quality graphics have been proposed and discussed here frequently. > > > > > > I am not 100% convinced that they are `substantively better' in all > > environments, and I still do that sometimes. > > I agree on principle - until the linux port can do *exactly* the > same thing better and more, "substantively better" is a > rather subjective description and is just for the fanatics. If > it is missing just one feature, like WMF export - and since microsoft > is not going bankrupt any time soon, MS office integration is > fairly important to *some* people - one cannot say it is > 'substantially better', because there is always one user who would > judge that one missing feature, over and above any other advantage. > > Some software on linux uses libwmf for wmf import/export (I believe > it is gimp). Maybe R can do the same. Well, we have shown that libEMF is problematic. So if you want better functionality here, you would be better served working with the libEMF developers to enhance their compatibility. Though, as Prof. Ripley has noted, there are problems with WMF/EMF files being imported into Office apps, even when natively generated on Windows. MS may not be going out of business in the near future, but the continued pressure of open standards (as just recently noted here in the Commonwealth of Massachusetts) will pressure MS over time to either adopt (and adapt to) open standards or to experience a decline in market share. It is suggested that the just announced inclusion of PDF functionality in the upcoming Office 12 is a direct result of the Massachusetts decision to require either OpenDoc or PDF formats. But that's a different discussion for a different forum... Relative to the "there is always one user" notion, being a firm believer in Pareto's 80/20 Rule, no business or venture, whether for profit or otherwise, can afford to meet the needs of 100% of the target marketplace. You will not survive if that is your goal. There are some users, for whom taking the time to meet their needs, will result in your inability to meet the needs of the majority of your users and you will ultimately lose them. That is called the "Opportunity Cost" and is intrinsic given the predicate that resources are finite. Having the discipline to say "No", that there is some "business" that is not worth having, is a critical part of the decision making process. The advantage of open source, is that you can build upon the basic "product" and tailor it to your specific need
Re: [Rd] R, Wine, and multi-threadedness.
On Thu, 2005-10-13 at 18:33 +0100, Hin-Tak Leung wrote: > Marc Schwartz (via MN) wrote: > > > I was more focused (and confused) on the Rgui.exe menus as the principal > > justification for taking this approach, but again, perhaps I am lacking > > context. > > I think you are confused about Rgui.exe, versus "having a GUI for R" > (which is what I wrote - I never wrote "Rgui.exe", as that was *not* > what I meant all along). Indeed. I stand corrected on that point, given your comments above and now going back to look at your prior posts. This helps to clarify my mis-perception. > I did try but failed with the Sciview-R - > it would install but won't run. Since the actual GUI faq is hosted > by sciview on "http://www.sciviews.org/_rgui/"; as you pointed out, > by association, my first guess was that it is a good bet to try > the Sciview-R one first. > > If anybody can name a "better" GUI than sciview-R, windows or linux, > I am all ears - "better" in any sense of the word, preferably > not in the ESS sense, as I already have that - nothing obviously > against it, but I like alternatives, preferably covering different > usage areas. If you are so motivated, you might consider subscribing to and contributing to the R-SIG-GUI list: https://stat.ethz.ch/mailman/listinfo/r-sig-gui As I mentioned in the post I just sent, this is a cooperative "venture" in which things happen because people selflessly contribute their time and energy to make it happen. > Before anybody jump in again, the fact that sciview-R is somewhat .NET > framework dependent (at least the binary installed by the > default installer seems to be) is justifiably a development issue? HTH, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Wine, and multi-threadedness.
Marc Schwartz (via MN) wrote: > If you are so motivated, you might consider subscribing to and > contributing to the R-SIG-GUI list: > > https://stat.ethz.ch/mailman/listinfo/r-sig-gui Another poster has suggested JGR. Don't particularly like Java much. At the moment I am more inclined (if it bugs me enough to do something myself about it) to try porting sciview-R as a hybrid libwine application with wingcc, and I did have a look at the 14MB source code bundle - it has a lot of binary-only bits which does not look as if they belong there or be redistributed. (Sigh...). Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 13, 2005 12:21 PM
> To: Dean, David P
> Cc: Uwe Ligges; r-devel@r-project.org; Paul Gilbert
> Subject: Re: [Rd] Installing R-2.2.0 package
>
> On Thu, 13 Oct 2005, Dean, David P wrote:
>
> >> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> >> Sent: Thursday, October 13, 2005 11:42 AM
> >> To: Uwe Ligges
> >> Cc: Paul Gilbert; r-devel@r-project.org; Dean, David P
> >> Subject: Re: [Rd] Installing R-2.2.0 package
> >>
> >> It works on Solaris 8 for me, and this is checked as part of the
> >> alpha/beta process.
> >>
> >> The code is the same on Linux and Solaris, after all, so this would
> have
> >> to be a Solaris shell bug.
> >
> > I'm on Solaris 8 as well. R is compiled for 64-bits, but I wouldn't
> expect
> > that to be a factor.
>
> I tested this on a 64-bit setup, as it happens.
>
> > R was built and is run in an environment created with
> > OpenPKG and containing GNU equivalents to many utilities -- so it's not
> a
> > stock Solaris setup.
>
> I hope /bin/sh is Solaris and not bash.
>
> > I'm not familiar with R internals but will be happy to try to debug if I
> > can. Does the installer call out to the shell somehow? Where would I
> start
> > to look for the relevant code?
>
> INSTALL _is_ a shell script.
>
> Rather than mess about with past code, can you first please try the
> current R-patched (see the FAQ) as I will shortly not have R-2.2.0 on
> Solaris but rather R-patched (I already have R-devel in 4 flavours).
>
> >
> > Thanks!
> > David Dean
OK, I'll try the current patched. I did locate the INSTALL script and added
a -x flag to see what is going on. (This is in the stock 2.2.0):
+ do_exit_on_error
remove_R_package_dir=yes
+ test -z
/net/gsun374/app/openpkg/lib/R-2.2.0-64bit/lib/R/bin/INSTALL: test: argument
expected
I think this line in do_exit_on_error causes an abend if bundlepkg isn't
set:
If test -z ${bundlepkg}; do
Cheers,
David Dean
--
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installing R-2.2.0 package
On Thu, 13 Oct 2005, Dean, David P wrote:
>> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 13, 2005 12:21 PM
>> To: Dean, David P
>> Cc: Uwe Ligges; r-devel@r-project.org; Paul Gilbert
>> Subject: Re: [Rd] Installing R-2.2.0 package
>>
>> On Thu, 13 Oct 2005, Dean, David P wrote:
>>
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 13, 2005 11:42 AM
To: Uwe Ligges
Cc: Paul Gilbert; r-devel@r-project.org; Dean, David P
Subject: Re: [Rd] Installing R-2.2.0 package
It works on Solaris 8 for me, and this is checked as part of the
alpha/beta process.
The code is the same on Linux and Solaris, after all, so this would
>> have
to be a Solaris shell bug.
>>>
>>> I'm on Solaris 8 as well. R is compiled for 64-bits, but I wouldn't
>> expect
>>> that to be a factor.
>>
>> I tested this on a 64-bit setup, as it happens.
>>
>>> R was built and is run in an environment created with
>>> OpenPKG and containing GNU equivalents to many utilities -- so it's not
>> a
>>> stock Solaris setup.
>>
>> I hope /bin/sh is Solaris and not bash.
>>
>>> I'm not familiar with R internals but will be happy to try to debug if I
>>> can. Does the installer call out to the shell somehow? Where would I
>> start
>>> to look for the relevant code?
>>
>> INSTALL _is_ a shell script.
>>
>> Rather than mess about with past code, can you first please try the
>> current R-patched (see the FAQ) as I will shortly not have R-2.2.0 on
>> Solaris but rather R-patched (I already have R-devel in 4 flavours).
>>
>>>
>>> Thanks!
>>> David Dean
>
> OK, I'll try the current patched. I did locate the INSTALL script and added
> a -x flag to see what is going on. (This is in the stock 2.2.0):
>
> + do_exit_on_error
> remove_R_package_dir=yes
> + test -z
> /net/gsun374/app/openpkg/lib/R-2.2.0-64bit/lib/R/bin/INSTALL: test: argument
> expected
>
> I think this line in do_exit_on_error causes an abend if bundlepkg isn't
> set:
>
> If test -z ${bundlepkg}; do
It is in R-patched, and indeed it has quotes too.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
Prof Brian Ripley wrote: >On Thu, 13 Oct 2005, Jennifer Lai wrote: > > > >>Hi, >> I"m a newbie on building R on Windows. I followed the instructions >>cited here, >>http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. >>Everything works fine up till when package base needs to be compiled. >>here is the error message, >> >>-- Making package base >> adding build stamp to DESCRIPTION >>Error in library.dynam(lib, package, package.lib) : >> shared library 'tools' not found >>Execution halted >>make[4]: *** [frontmatter] Error 1 >>make[3]: *** [all] Error 2 >>make[2]: *** [pkg-base] Error 2 >>make[1]: *** [rpackage] Error 2 >>make: *** [all] Error 2 >> >>Has anyone seen this error message before? Where can I find shared >>library tools? >> >> > >It was built at the bootstrapping phase, or should have been. > > > Is there something like config.log for Windows port? I didn't see anything suspcicious that helped me in finding where shared library tools should be built. There were couple of warning messges related to dlapack, but these are not related to tools, right? In file included from dlapack0.f:0: dlapack0.f:203: warning: 'ipv' might be used uninitialized in this function dlapack0.f:203: warning: 'jpv' might be used uninitialized in this function dlapack0.f:204: warning: 'smin' might be used uninitialized in this function Many Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
On Thu, 13 Oct 2005, Jennifer Lai wrote: > Prof Brian Ripley wrote: > >> On Thu, 13 Oct 2005, Jennifer Lai wrote: >> >> >>> Hi, >>> I"m a newbie on building R on Windows. I followed the instructions >>> cited here, >>> http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. >>> Everything works fine up till when package base needs to be compiled. >>> here is the error message, >>> >>> -- Making package base >>> adding build stamp to DESCRIPTION >>> Error in library.dynam(lib, package, package.lib) : >>> shared library 'tools' not found >>> Execution halted >>> make[4]: *** [frontmatter] Error 1 >>> make[3]: *** [all] Error 2 >>> make[2]: *** [pkg-base] Error 2 >>> make[1]: *** [rpackage] Error 2 >>> make: *** [all] Error 2 >>> >>> Has anyone seen this error message before? Where can I find shared >>> library tools? >>> >> >> It was built at the bootstrapping phase, or should have been. >> >> > Is there something like config.log for Windows port? No. You will need to start again and show us what happens around the boot it says it is bootstrapping. > I didn't see anything suspcicious that helped me in finding where shared > library tools should be built. > There were couple of warning messges related to dlapack, but these are not > related to tools, right? > > In file included from dlapack0.f:0: > dlapack0.f:203: warning: 'ipv' might be used uninitialized in this function > dlapack0.f:203: warning: 'jpv' might be used uninitialized in this function > dlapack0.f:204: warning: 'smin' might be used uninitialized in this function You will get many of those. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R on Windows
Prof Brian Ripley wrote: > On Thu, 13 Oct 2005, Jennifer Lai wrote: > >> Prof Brian Ripley wrote: >> >>> On Thu, 13 Oct 2005, Jennifer Lai wrote: >>> >>> Hi, I"m a newbie on building R on Windows. I followed the instructions cited here, http://www.murdoch-sutherland.com/Rtools/ to build R-2.2.0. Everything works fine up till when package base needs to be compiled. here is the error message, -- Making package base adding build stamp to DESCRIPTION Error in library.dynam(lib, package, package.lib) : shared library 'tools' not found Execution halted make[4]: *** [frontmatter] Error 1 make[3]: *** [all] Error 2 make[2]: *** [pkg-base] Error 2 make[1]: *** [rpackage] Error 2 make: *** [all] Error 2 Has anyone seen this error message before? Where can I find shared library tools? >>> >>> It was built at the bootstrapping phase, or should have been. >>> >>> >> Is there something like config.log for Windows port? > > > No. You will need to start again and show us what happens around the > boot it says it is bootstrapping. > > >> I didn't see anything suspcicious that helped me in finding where >> shared library tools should be built. >> There were couple of warning messges related to dlapack, but these >> are not related to tools, right? >> >> In file included from dlapack0.f:0: >> dlapack0.f:203: warning: 'ipv' might be used uninitialized in this >> function >> dlapack0.f:203: warning: 'jpv' might be used uninitialized in this >> function >> dlapack0.f:204: warning: 'smin' might be used uninitialized in this >> function > > > You will get many of those. > > I was able to build R for Windows successfully with a clean copy of R-2.2.0, rather than using "make clean" to remove all object files. Thanks, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R in Spanish?
Hi R developers: I want to ask if there is a Spanish R installation, if not, why not, and how can I help to make the Spanish version, if you tell me how I am willing to help with it. Kenneth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] expm1, R-2.2.0 and Windows
A user of 'eha' told me that it failed to load in R-2.2.0 on Windows, and ideed, I checked and it fails with the error message "The procedure entry point expm1 could not be located in the dynamic link libary R.dll". I'm using expm1 (from the C math library on Linux, I would guess) in a couple of C functions. This didn't happen with R-2.1.1 (and it doesn't happen with R-2.2.0 on debian), so I need advise about what to do. File a bug report? -- Göran Broström __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R in Spanish?
Kenneth Cabrera <[EMAIL PROTECTED]> writes: > Hi R developers: > > I want to ask if there is a Spanish R installation, http://developer.r-project.org/TranslationTeams.html doesn't seem to have a Spanish team. > if not, why not, well, someone has to write it I have been wondering about it, since Spanish is one of the Worlds' largest languages (if not _the_ largest), with a substantial proportion of non-English speakers. > and how can I help to > make the Spanish version, There's a fairly elaborate set of beginners instructions to .po files and all that, here: http://developer.r-project.org/Translations.html > if you tell me how > I am willing to help with it. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
