date:20161221

Re: [Rd] Fwd: Re: RSiteSearch, sos, rdocumentation.org, ...?

2016-12-21 Thread Jonathan Baron

Unfortunately, I am unable to get this search site working again. (The
message below explains why I had to rebuild it.)

The computer worked for the better part of a day downloading and
installing all the help files from all CRAN packages. Somehow it
failed to get the vignettes this time. But I pushed ahead and ran the
part of namazu that makes the search indices: mknmz. And you can see
the results if you go to finzi.psych.upenn.edu. The search works, but
then you can't get the actual help pages.

The problem seems to be that namazu search is ignoring the "Replace"
rules in the configuration file, namazurc. I have tried 4 versions of
that file, in combination with 3 versions of namazu-cgi, and nothing
works. Note that the last version of namzu was about 2009, the result
of some fixes by linux distribution maintainers, not by the original
creators, who gave up a few years before.

If someone wants to replace namazu with a different search engine, let
me know. I do have a server with all the help files.

And I can tell you how I made them if you want to do this somewhere
else. The trick is:

update.packages(dependencies=FALSE,INSTALL_opts=c("--no-configure","--no-test-load","--no-R","--no-clean-on-error","--no-libs","--no-data","--no-demo","--no-exec","--html"),repos=biocinstallRepos(),ask=F)

and

install.packages(m3,dependencies=FALSE,INSTALL_opts=c("--no-configure","--no-test-load","--no-R","--no-clean-on-error","--no-libs","--no-data","--no-demo","--no-exec","--html"),repos=biocinstallRepos())

This works as is in the fedora version of R, which I think is modified
(for my benefit, about 10 years ago) from the distribution version,
and I think I know what the modification is. The first is for packages
I already have. The second can be used to build the site.

(I use the bioconductor repository because most of the time it doesn't
matter, but there were once a few packages that were only there, ones
that I used myself, like multtest.)

Of course, if there is a human being who reads this and wants to
fiddle with namazu, he or she should contact me.

Jon

On 12/17/16 15:32, Jonathan Baron wrote:

Spencer and others.

I am going to have to take down the server for RSiteSearch, which is
finzi.psych.upenn.edu, for at least a couple of days starting Sunday
morning. It has been hacked. And I have another server that has also
been hacked, which is higher priority (sjdm.org). On Monday, I will
probably have time to rebuild that one, but I may not have time to
rebuild finzi for another week. I will try to get it all done in one
day, but I don't know if I can.

Sorry about this.

I thought that there was an alternative to this site, namely
http://rdocumentation.org/
but, as bad is my site is, that one, I think, is worse.

Jon

--
Jonathan Baron, Professor of Psychology, University of Pennsylvania
Home page: http://www.sas.upenn.edu/~baron
Editor: Judgment and Decision Making (http://journal.sjdm.org)

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

Re: [Rd] different compilers and mzR build fails

2016-12-21 Thread Martin Morgan


On 12/21/2016 01:56 PM, lejeczek wrote:


I do this on a vanilla-clean R installation, simply:

biocLite("mzR")

it pulls some deps in which compile fine, only mzR fails.
... meanwhile...
I grabbed devtools and comiled github master - still fails.
Should I attach build log? One should not send attachments to the list..
I don't suppose?


My opinion is that the appropriate forum is the Bioconductor support 
site. I think you should EDIT your question on the Bioconductor support 
site to add the compiler output. If you feel like you can spot where 
things are going wrong, then edited to include those parts otherwise 
post the output in its entirety; the support site can mangle formatting, 
so I'd copy-and-paste the compiler output, and then select it and format 
it as 'code'.


If you feel that the current forum is more appropriate, then 
cut-and-paste the compiler output into an email message, avoding 
attachments.


Martin



On 21/12/16 17:06, Martin Morgan wrote:

mzR is a Bioconductor package, so better to ask on the Bioconductor
support forum

  https://support.bioconductor.org

Oh, I see you did, and then the advice is to avoid cross-posting!

The missing .o files would have been produced in an earlier
compilation step; they likely failed in some way, so you need to
provide the complete compilation output.

Did you do this on a version of the package that did not have any
previous build artifacts (e.g., via biocLite() or from a fresh svn
checkout)?

Martin

On 12/21/2016 12:00 PM, lejeczek via R-devel wrote:

I'm not sure if I should bother you team with this, apologies in case
it's a bother.

I'm trying gcc 6.2.1 (from devtoolset-6) with R, everything seems to
work just fine, except for mzR.
Here is failed build:

g++ -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o mzR.so cramp.o
ramp_base64.o ramp.o RcppRamp.o RcppRampModule.o rnetCDF.o RcppPwiz.o
RcppPwizModule.o RcppIdent.o RcppIdentModule.o
./boost/system/src/error_code.o ./boost/regex/src/posix_api.o
./boost/regex/src/fileiter.o ./boost/regex/src/regex_raw_buffer.o
./boost/regex/src/cregex.o ./boost/regex/src/regex_debug.o
./boost/regex/src/instances.o ./boost/regex/src/icu.o
./boost/regex/src/usinstances.o ./boost/regex/src/regex.o
./boost/regex/src/wide_posix_api.o
./boost/regex/src/regex_traits_defaults.o ./boost/regex/src/winstances.o
./boost/regex/src/wc_regex_traits.o ./boost/regex/src/c_regex_traits.o
./boost/regex/src/cpp_regex_traits.o ./boost/regex/src/static_mutex.o
./boost/regex/src/w32_regex_traits.o ./boost/iostreams/src/zlib.o
./boost/iostreams/src/file_descriptor.o ./boost/thread/pthread/once.o
./boost/thread/pthread/thread.o ./boost/filesystem/src/operations.o
./boost/filesystem/src/path.o
./boost/filesystem/src/utf8_codecvt_facet.o ./boost/chrono/src/chrono.o
./boost/chrono/src/process_cpu_clocks.o
./boost/chrono/src/thread_clock.o ./pwiz/data/msdata/Version.o
./pwiz/data/common/MemoryIndex.o ./pwiz/data/common/CVTranslator.o
./pwiz/data/common/cv.o ./pwiz/data/common/ParamTypes.o
./pwiz/data/common/BinaryIndexStream.o ./pwiz/data/common/diff_std.o
./pwiz/data/common/Unimod.o ./pwiz/data/msdata/SpectrumList_MGF.o
./pwiz/data/msdata/DefaultReaderList.o
./pwiz/data/msdata/ChromatogramList_mzML.o ./pwiz/data/msdata/examples.o
./pwiz/data/msdata/Serializer_mzML.o ./pwiz/data/msdata/Serializer_MSn.o
./pwiz/data/msdata/Reader.o ./pwiz/data/msdata/Serializer_MGF.o
./pwiz/data/msdata/Serializer_mzXML.o
./pwiz/data/msdata/SpectrumList_mzML.o
./pwiz/data/msdata/SpectrumList_MSn.o
./pwiz/data/msdata/BinaryDataEncoder.o ./pwiz/data/msdata/Diff.o
./pwiz/data/msdata/MSData.o ./pwiz/data/msdata/References.o
./pwiz/data/msdata/SpectrumList_mzXML.o ./pwiz/data/msdata/IO.o
./pwiz/data/msdata/SpectrumList_BTDX.o ./pwiz/data/msdata/SpectrumInfo.o
./pwiz/data/msdata/RAMPAdapter.o ./pwiz/data/msdata/LegacyAdapter.o
./pwiz/data/msdata/SpectrumIterator.o ./pwiz/data/msdata/MSDataFile.o
./pwiz/data/msdata/MSNumpress.o ./pwiz/data/msdata/SpectrumListCache.o
./pwiz/data/msdata/Index_mzML.o
./pwiz/data/msdata/SpectrumWorkerThreads.o
./pwiz/data/identdata/IdentDataFile.o ./pwiz/data/identdata/IdentData.o
./pwiz/data/identdata/DefaultReaderList.o ./pwiz/data/identdata/Reader.o
./pwiz/data/identdata/Serializer_protXML.o
./pwiz/data/identdata/Serializer_pepXML.o
./pwiz/data/identdata/Serializer_mzid.o ./pwiz/data/identdata/IO.o
./pwiz/data/identdata/References.o ./pwiz/data/identdata/MascotReader.o
./pwiz/data/proteome/Modification.o ./pwiz/data/proteome/Digestion.o
./pwiz/data/proteome/Peptide.o ./pwiz/data/proteome/AminoAcid.o
./pwiz/utility/minimxml/XMLWriter.o ./pwiz/utility/minimxml/SAXParser.o
./pwiz/utility/chemistry/Chemistry.o
./pwiz/utility/chemistry/ChemistryData.o
./pwiz/utility/chemistry/MZTolerance.o ./pwiz/utility/misc/IntegerSet.o
./pwiz/utility/misc/Base64.o ./pwiz/utility/misc/IterationListener.o
./pwiz/utility/misc/MSIHandler.o ./pwiz/utility/misc/Filesystem.o
./pwiz/utility/misc/TabReader.o

Re: [Rd] different compilers and mzR build fails

2016-12-21 Thread lejeczek via R-devel



I do this on a vanilla-clean R installation, simply:
> biocLite("mzR")
it pulls some deps in which compile fine, only mzR fails.
... meanwhile...
I grabbed devtools and comiled github master - still fails.
Should I attach build log? One should not send attachments 
to the list.. I don't suppose?


On 21/12/16 17:06, Martin Morgan wrote:
mzR is a Bioconductor package, so better to ask on the 
Bioconductor support forum


  https://support.bioconductor.org

Oh, I see you did, and then the advice is to avoid 
cross-posting!


The missing .o files would have been produced in an 
earlier compilation step; they likely failed in some way, 
so you need to provide the complete compilation output.


Did you do this on a version of the package that did not 
have any previous build artifacts (e.g., via biocLite() or 
from a fresh svn checkout)?


Martin

On 12/21/2016 12:00 PM, lejeczek via R-devel wrote:
I'm not sure if I should bother you team with this, 
apologies in case

it's a bother.

I'm trying gcc 6.2.1 (from devtoolset-6) with R, 
everything seems to

work just fine, except for mzR.
Here is failed build:

g++ -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o 
mzR.so cramp.o
ramp_base64.o ramp.o RcppRamp.o RcppRampModule.o 
rnetCDF.o RcppPwiz.o

RcppPwizModule.o RcppIdent.o RcppIdentModule.o
./boost/system/src/error_code.o 
./boost/regex/src/posix_api.o
./boost/regex/src/fileiter.o 
./boost/regex/src/regex_raw_buffer.o

./boost/regex/src/cregex.o ./boost/regex/src/regex_debug.o
./boost/regex/src/instances.o ./boost/regex/src/icu.o
./boost/regex/src/usinstances.o ./boost/regex/src/regex.o
./boost/regex/src/wide_posix_api.o
./boost/regex/src/regex_traits_defaults.o 
./boost/regex/src/winstances.o
./boost/regex/src/wc_regex_traits.o 
./boost/regex/src/c_regex_traits.o
./boost/regex/src/cpp_regex_traits.o 
./boost/regex/src/static_mutex.o
./boost/regex/src/w32_regex_traits.o 
./boost/iostreams/src/zlib.o
./boost/iostreams/src/file_descriptor.o 
./boost/thread/pthread/once.o
./boost/thread/pthread/thread.o 
./boost/filesystem/src/operations.o

./boost/filesystem/src/path.o
./boost/filesystem/src/utf8_codecvt_facet.o 
./boost/chrono/src/chrono.o

./boost/chrono/src/process_cpu_clocks.o
./boost/chrono/src/thread_clock.o 
./pwiz/data/msdata/Version.o
./pwiz/data/common/MemoryIndex.o 
./pwiz/data/common/CVTranslator.o

./pwiz/data/common/cv.o ./pwiz/data/common/ParamTypes.o
./pwiz/data/common/BinaryIndexStream.o 
./pwiz/data/common/diff_std.o
./pwiz/data/common/Unimod.o 
./pwiz/data/msdata/SpectrumList_MGF.o

./pwiz/data/msdata/DefaultReaderList.o
./pwiz/data/msdata/ChromatogramList_mzML.o 
./pwiz/data/msdata/examples.o
./pwiz/data/msdata/Serializer_mzML.o 
./pwiz/data/msdata/Serializer_MSn.o
./pwiz/data/msdata/Reader.o 
./pwiz/data/msdata/Serializer_MGF.o

./pwiz/data/msdata/Serializer_mzXML.o
./pwiz/data/msdata/SpectrumList_mzML.o
./pwiz/data/msdata/SpectrumList_MSn.o
./pwiz/data/msdata/BinaryDataEncoder.o 
./pwiz/data/msdata/Diff.o

./pwiz/data/msdata/MSData.o ./pwiz/data/msdata/References.o
./pwiz/data/msdata/SpectrumList_mzXML.o 
./pwiz/data/msdata/IO.o
./pwiz/data/msdata/SpectrumList_BTDX.o 
./pwiz/data/msdata/SpectrumInfo.o
./pwiz/data/msdata/RAMPAdapter.o 
./pwiz/data/msdata/LegacyAdapter.o
./pwiz/data/msdata/SpectrumIterator.o 
./pwiz/data/msdata/MSDataFile.o
./pwiz/data/msdata/MSNumpress.o 
./pwiz/data/msdata/SpectrumListCache.o

./pwiz/data/msdata/Index_mzML.o
./pwiz/data/msdata/SpectrumWorkerThreads.o
./pwiz/data/identdata/IdentDataFile.o 
./pwiz/data/identdata/IdentData.o
./pwiz/data/identdata/DefaultReaderList.o 
./pwiz/data/identdata/Reader.o

./pwiz/data/identdata/Serializer_protXML.o
./pwiz/data/identdata/Serializer_pepXML.o
./pwiz/data/identdata/Serializer_mzid.o 
./pwiz/data/identdata/IO.o
./pwiz/data/identdata/References.o 
./pwiz/data/identdata/MascotReader.o
./pwiz/data/proteome/Modification.o 
./pwiz/data/proteome/Digestion.o
./pwiz/data/proteome/Peptide.o 
./pwiz/data/proteome/AminoAcid.o
./pwiz/utility/minimxml/XMLWriter.o 
./pwiz/utility/minimxml/SAXParser.o

./pwiz/utility/chemistry/Chemistry.o
./pwiz/utility/chemistry/ChemistryData.o
./pwiz/utility/chemistry/MZTolerance.o 
./pwiz/utility/misc/IntegerSet.o
./pwiz/utility/misc/Base64.o 
./pwiz/utility/misc/IterationListener.o
./pwiz/utility/misc/MSIHandler.o 
./pwiz/utility/misc/Filesystem.o

./pwiz/utility/misc/TabReader.o
./pwiz/utility/misc/random_access_compressed_ifstream.o
./pwiz/utility/misc/SHA1.o 
./pwiz/utility/misc/SHA1Calculator.o
./pwiz/utility/misc/sha1calc.o ./random_access_gzFile.o 
./RcppExports.o
rampR.o R_init_mzR.o -lpthread -lnetcdf 
-L/usr/lib64/R/lib -lR

g++: error: cramp.o: No such file or directory
g++: error: ramp_base64.o: No such file or directory
g++: error: ramp.o: No such file or directory
g++: error: RcppRamp.o: No such file or directory
g++: error: RcppRampModule.o: No such file or directory
g++: error: rnetCDF.o: No such file or directory
g++: error: RcppPwiz.o: No such file or directory
g++: error:

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

2016-12-21 Thread Dirk Eddelbuettel


On 21 December 2016 at 09:42, Karl Millar via R-devel wrote:
| Currently what I do is to never unload DLLs.  If I need to replace
| one, then I just restart R.  It's less convenient, but it's always
| correct.

Same here. Ever since we built littler in 2006 (!!) I have been doing tests
at the command-line with fresh 'r' processes.  No surprises, no side effects.

Dirk

PS Spencer, if you are still reading, std::vector is describe inter alia here
http://en.cppreference.com/w/cpp/container/vector  My point of bringing it up
was a deeper one because that (really widely used) data structure grows as
needed. No pointers, no malloc, no horror stories you may have heard from C.

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

2016-12-21 Thread Karl Millar via R-devel

It does, but you'd still be relying on the R code ensuring that all of
these objects are dead prior to unloading the DLL, otherwise they'll
survive the GC.  Maybe if the package counted how many such objects
exist, it could work out when it's safe to remove the DLL.  I'm not
sure that it can be done automatically.

What could be done is to to keep the DLL loaded, but remove it from
R's table of loaded DLLs.  That way, there's no risk of dangling
function pointers and a new DLL of the same name could be loaded.  You
could still run into issues though as some DLLs assume that the
associated namespace exists.

Currently what I do is to never unload DLLs.  If I need to replace
one, then I just restart R.  It's less convenient, but it's always
correct.


On Wed, Dec 21, 2016 at 9:10 AM, Henrik Bengtsson
 wrote:
> On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar  wrote:
>> It's not always clear when it's safe to remove the DLL.
>>
>> The main problem that I'm aware of is that native objects with
>> finalizers might still exist (created by R_RegisterCFinalizer etc).
>> Even if there are no live references to such objects (which would be
>> hard to verify), it still wouldn't be safe to unload the DLL until a
>> full garbage collection has been done.
>>
>> If the DLL is unloaded, then the function pointer that was registered
>> now becomes a pointer into the memory where the DLL was, leading to an
>> almost certain crash when such objects get garbage collected.
>
> Very good point.
>
> Does base::gc() perform such a *full* garbage collection and thereby
> trigger all remaining finalizers to be called?  In other words, do you
> think an explicit call to base::gc() prior to cleaning out left-over
> DLLs (e.g. R.utils::gcDLLs()) would be sufficient?
>
> /Henrik
>
>>
>> A better approach would be to just remove the limit on the number of
>> DLLs, dynamically expanding the array if/when needed.
>>
>>
>> On Tue, Dec 20, 2016 at 3:40 AM, Jeroen Ooms  
>> wrote:
>>> On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson
>>>  wrote:
 On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some
 packages don't unload their DLLs when they being unloaded themselves.
>>>
>>> I am surprised by this. Why does R not do this automatically? What is
>>> the case for keeping the DLL loaded after the package has been
>>> unloaded? What happens if you reload another version of the same
>>> package from a different library after unloading?
>>>
>>> __
>>> 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] Request: Increasing MAX_NUM_DLLS in Rdynload.c

2016-12-21 Thread Henrik Bengtsson

On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar  wrote:
> It's not always clear when it's safe to remove the DLL.
>
> The main problem that I'm aware of is that native objects with
> finalizers might still exist (created by R_RegisterCFinalizer etc).
> Even if there are no live references to such objects (which would be
> hard to verify), it still wouldn't be safe to unload the DLL until a
> full garbage collection has been done.
>
> If the DLL is unloaded, then the function pointer that was registered
> now becomes a pointer into the memory where the DLL was, leading to an
> almost certain crash when such objects get garbage collected.

Very good point.

Does base::gc() perform such a *full* garbage collection and thereby
trigger all remaining finalizers to be called?  In other words, do you
think an explicit call to base::gc() prior to cleaning out left-over
DLLs (e.g. R.utils::gcDLLs()) would be sufficient?

/Henrik

>
> A better approach would be to just remove the limit on the number of
> DLLs, dynamically expanding the array if/when needed.
>
>
> On Tue, Dec 20, 2016 at 3:40 AM, Jeroen Ooms  
> wrote:
>> On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson
>>  wrote:
>>> On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some
>>> packages don't unload their DLLs when they being unloaded themselves.
>>
>> I am surprised by this. Why does R not do this automatically? What is
>> the case for keeping the DLL loaded after the package has been
>> unloaded? What happens if you reload another version of the same
>> package from a different library after unloading?
>>
>> __
>> 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] different compilers and mzR build fails

2016-12-21 Thread Martin Morgan

mzR is a Bioconductor package, so better to ask on the Bioconductor 
support forum


  https://support.bioconductor.org

Oh, I see you did, and then the advice is to avoid cross-posting!

The missing .o files would have been produced in an earlier compilation 
step; they likely failed in some way, so you need to provide the 
complete compilation output.


Did you do this on a version of the package that did not have any 
previous build artifacts (e.g., via biocLite() or from a fresh svn 
checkout)?


Martin

On 12/21/2016 12:00 PM, lejeczek via R-devel wrote:

I'm not sure if I should bother you team with this, apologies in case
it's a bother.

I'm trying gcc 6.2.1 (from devtoolset-6) with R, everything seems to
work just fine, except for mzR.
Here is failed build:

g++ -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o mzR.so cramp.o
ramp_base64.o ramp.o RcppRamp.o RcppRampModule.o rnetCDF.o RcppPwiz.o
RcppPwizModule.o RcppIdent.o RcppIdentModule.o
./boost/system/src/error_code.o ./boost/regex/src/posix_api.o
./boost/regex/src/fileiter.o ./boost/regex/src/regex_raw_buffer.o
./boost/regex/src/cregex.o ./boost/regex/src/regex_debug.o
./boost/regex/src/instances.o ./boost/regex/src/icu.o
./boost/regex/src/usinstances.o ./boost/regex/src/regex.o
./boost/regex/src/wide_posix_api.o
./boost/regex/src/regex_traits_defaults.o ./boost/regex/src/winstances.o
./boost/regex/src/wc_regex_traits.o ./boost/regex/src/c_regex_traits.o
./boost/regex/src/cpp_regex_traits.o ./boost/regex/src/static_mutex.o
./boost/regex/src/w32_regex_traits.o ./boost/iostreams/src/zlib.o
./boost/iostreams/src/file_descriptor.o ./boost/thread/pthread/once.o
./boost/thread/pthread/thread.o ./boost/filesystem/src/operations.o
./boost/filesystem/src/path.o
./boost/filesystem/src/utf8_codecvt_facet.o ./boost/chrono/src/chrono.o
./boost/chrono/src/process_cpu_clocks.o
./boost/chrono/src/thread_clock.o ./pwiz/data/msdata/Version.o
./pwiz/data/common/MemoryIndex.o ./pwiz/data/common/CVTranslator.o
./pwiz/data/common/cv.o ./pwiz/data/common/ParamTypes.o
./pwiz/data/common/BinaryIndexStream.o ./pwiz/data/common/diff_std.o
./pwiz/data/common/Unimod.o ./pwiz/data/msdata/SpectrumList_MGF.o
./pwiz/data/msdata/DefaultReaderList.o
./pwiz/data/msdata/ChromatogramList_mzML.o ./pwiz/data/msdata/examples.o
./pwiz/data/msdata/Serializer_mzML.o ./pwiz/data/msdata/Serializer_MSn.o
./pwiz/data/msdata/Reader.o ./pwiz/data/msdata/Serializer_MGF.o
./pwiz/data/msdata/Serializer_mzXML.o
./pwiz/data/msdata/SpectrumList_mzML.o
./pwiz/data/msdata/SpectrumList_MSn.o
./pwiz/data/msdata/BinaryDataEncoder.o ./pwiz/data/msdata/Diff.o
./pwiz/data/msdata/MSData.o ./pwiz/data/msdata/References.o
./pwiz/data/msdata/SpectrumList_mzXML.o ./pwiz/data/msdata/IO.o
./pwiz/data/msdata/SpectrumList_BTDX.o ./pwiz/data/msdata/SpectrumInfo.o
./pwiz/data/msdata/RAMPAdapter.o ./pwiz/data/msdata/LegacyAdapter.o
./pwiz/data/msdata/SpectrumIterator.o ./pwiz/data/msdata/MSDataFile.o
./pwiz/data/msdata/MSNumpress.o ./pwiz/data/msdata/SpectrumListCache.o
./pwiz/data/msdata/Index_mzML.o
./pwiz/data/msdata/SpectrumWorkerThreads.o
./pwiz/data/identdata/IdentDataFile.o ./pwiz/data/identdata/IdentData.o
./pwiz/data/identdata/DefaultReaderList.o ./pwiz/data/identdata/Reader.o
./pwiz/data/identdata/Serializer_protXML.o
./pwiz/data/identdata/Serializer_pepXML.o
./pwiz/data/identdata/Serializer_mzid.o ./pwiz/data/identdata/IO.o
./pwiz/data/identdata/References.o ./pwiz/data/identdata/MascotReader.o
./pwiz/data/proteome/Modification.o ./pwiz/data/proteome/Digestion.o
./pwiz/data/proteome/Peptide.o ./pwiz/data/proteome/AminoAcid.o
./pwiz/utility/minimxml/XMLWriter.o ./pwiz/utility/minimxml/SAXParser.o
./pwiz/utility/chemistry/Chemistry.o
./pwiz/utility/chemistry/ChemistryData.o
./pwiz/utility/chemistry/MZTolerance.o ./pwiz/utility/misc/IntegerSet.o
./pwiz/utility/misc/Base64.o ./pwiz/utility/misc/IterationListener.o
./pwiz/utility/misc/MSIHandler.o ./pwiz/utility/misc/Filesystem.o
./pwiz/utility/misc/TabReader.o
./pwiz/utility/misc/random_access_compressed_ifstream.o
./pwiz/utility/misc/SHA1.o ./pwiz/utility/misc/SHA1Calculator.o
./pwiz/utility/misc/sha1calc.o ./random_access_gzFile.o ./RcppExports.o
rampR.o R_init_mzR.o -lpthread -lnetcdf -L/usr/lib64/R/lib -lR
g++: error: cramp.o: No such file or directory
g++: error: ramp_base64.o: No such file or directory
g++: error: ramp.o: No such file or directory
g++: error: RcppRamp.o: No such file or directory
g++: error: RcppRampModule.o: No such file or directory
g++: error: rnetCDF.o: No such file or directory
g++: error: RcppPwiz.o: No such file or directory
g++: error: RcppPwizModule.o: No such file or directory
g++: error: RcppIdent.o: No such file or directory
g++: error: RcppIdentModule.o: No such file or directory
/usr/share/R/make/shlib.mk:6: recipe for target 'mzR.so' failed
make: *** [mzR.so] Error 1

It did compile with 5.2.x (from devtoolset-4) and worked fine.
I'm hoping you guys could confirm it is purely compiler problem? Or
point me(not a real

[Rd] different compilers and mzR build fails

2016-12-21 Thread lejeczek via R-devel

I'm not sure if I should bother you team with this, 
apologies in case it's a bother.


I'm trying gcc 6.2.1 (from devtoolset-6) with R, everything 
seems to work just fine, except for mzR.

Here is failed build:

g++ -m64 -shared -L/usr/lib64/R/lib -Wl,-z,relro -o mzR.so 
cramp.o ramp_base64.o ramp.o RcppRamp.o RcppRampModule.o 
rnetCDF.o RcppPwiz.o RcppPwizModule.o RcppIdent.o 
RcppIdentModule.o ./boost/system/src/error_code.o 
./boost/regex/src/posix_api.o ./boost/regex/src/fileiter.o 
./boost/regex/src/regex_raw_buffer.o 
./boost/regex/src/cregex.o ./boost/regex/src/regex_debug.o 
./boost/regex/src/instances.o ./boost/regex/src/icu.o 
./boost/regex/src/usinstances.o ./boost/regex/src/regex.o 
./boost/regex/src/wide_posix_api.o 
./boost/regex/src/regex_traits_defaults.o 
./boost/regex/src/winstances.o 
./boost/regex/src/wc_regex_traits.o 
./boost/regex/src/c_regex_traits.o 
./boost/regex/src/cpp_regex_traits.o 
./boost/regex/src/static_mutex.o 
./boost/regex/src/w32_regex_traits.o 
./boost/iostreams/src/zlib.o 
./boost/iostreams/src/file_descriptor.o 
./boost/thread/pthread/once.o 
./boost/thread/pthread/thread.o 
./boost/filesystem/src/operations.o 
./boost/filesystem/src/path.o 
./boost/filesystem/src/utf8_codecvt_facet.o 
./boost/chrono/src/chrono.o 
./boost/chrono/src/process_cpu_clocks.o 
./boost/chrono/src/thread_clock.o 
./pwiz/data/msdata/Version.o 
./pwiz/data/common/MemoryIndex.o 
./pwiz/data/common/CVTranslator.o ./pwiz/data/common/cv.o 
./pwiz/data/common/ParamTypes.o 
./pwiz/data/common/BinaryIndexStream.o 
./pwiz/data/common/diff_std.o ./pwiz/data/common/Unimod.o 
./pwiz/data/msdata/SpectrumList_MGF.o 
./pwiz/data/msdata/DefaultReaderList.o 
./pwiz/data/msdata/ChromatogramList_mzML.o 
./pwiz/data/msdata/examples.o 
./pwiz/data/msdata/Serializer_mzML.o 
./pwiz/data/msdata/Serializer_MSn.o 
./pwiz/data/msdata/Reader.o 
./pwiz/data/msdata/Serializer_MGF.o 
./pwiz/data/msdata/Serializer_mzXML.o 
./pwiz/data/msdata/SpectrumList_mzML.o 
./pwiz/data/msdata/SpectrumList_MSn.o 
./pwiz/data/msdata/BinaryDataEncoder.o 
./pwiz/data/msdata/Diff.o ./pwiz/data/msdata/MSData.o 
./pwiz/data/msdata/References.o 
./pwiz/data/msdata/SpectrumList_mzXML.o 
./pwiz/data/msdata/IO.o 
./pwiz/data/msdata/SpectrumList_BTDX.o 
./pwiz/data/msdata/SpectrumInfo.o 
./pwiz/data/msdata/RAMPAdapter.o 
./pwiz/data/msdata/LegacyAdapter.o 
./pwiz/data/msdata/SpectrumIterator.o 
./pwiz/data/msdata/MSDataFile.o 
./pwiz/data/msdata/MSNumpress.o 
./pwiz/data/msdata/SpectrumListCache.o 
./pwiz/data/msdata/Index_mzML.o 
./pwiz/data/msdata/SpectrumWorkerThreads.o 
./pwiz/data/identdata/IdentDataFile.o 
./pwiz/data/identdata/IdentData.o 
./pwiz/data/identdata/DefaultReaderList.o 
./pwiz/data/identdata/Reader.o 
./pwiz/data/identdata/Serializer_protXML.o 
./pwiz/data/identdata/Serializer_pepXML.o 
./pwiz/data/identdata/Serializer_mzid.o 
./pwiz/data/identdata/IO.o 
./pwiz/data/identdata/References.o 
./pwiz/data/identdata/MascotReader.o 
./pwiz/data/proteome/Modification.o 
./pwiz/data/proteome/Digestion.o 
./pwiz/data/proteome/Peptide.o 
./pwiz/data/proteome/AminoAcid.o 
./pwiz/utility/minimxml/XMLWriter.o 
./pwiz/utility/minimxml/SAXParser.o 
./pwiz/utility/chemistry/Chemistry.o 
./pwiz/utility/chemistry/ChemistryData.o 
./pwiz/utility/chemistry/MZTolerance.o 
./pwiz/utility/misc/IntegerSet.o 
./pwiz/utility/misc/Base64.o 
./pwiz/utility/misc/IterationListener.o 
./pwiz/utility/misc/MSIHandler.o 
./pwiz/utility/misc/Filesystem.o 
./pwiz/utility/misc/TabReader.o 
./pwiz/utility/misc/random_access_compressed_ifstream.o 
./pwiz/utility/misc/SHA1.o 
./pwiz/utility/misc/SHA1Calculator.o 
./pwiz/utility/misc/sha1calc.o ./random_access_gzFile.o 
./RcppExports.o rampR.o R_init_mzR.o -lpthread -lnetcdf 
-L/usr/lib64/R/lib -lR

g++: error: cramp.o: No such file or directory
g++: error: ramp_base64.o: No such file or directory
g++: error: ramp.o: No such file or directory
g++: error: RcppRamp.o: No such file or directory
g++: error: RcppRampModule.o: No such file or directory
g++: error: rnetCDF.o: No such file or directory
g++: error: RcppPwiz.o: No such file or directory
g++: error: RcppPwizModule.o: No such file or directory
g++: error: RcppIdent.o: No such file or directory
g++: error: RcppIdentModule.o: No such file or directory
/usr/share/R/make/shlib.mk:6: recipe for target 'mzR.so' failed
make: *** [mzR.so] Error 1

It did compile with 5.2.x (from devtoolset-4) and worked fine.
I'm hoping you guys could confirm it is purely compiler 
problem? Or point me(not a real programmer) a way to 
troubleshoot it properly?

many thanks,
L.

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

Re: [Rd] Very small numbers in hexadecimal notation parsed as zero

2016-12-21 Thread Martin Maechler

> Florent Angly 
> on Tue, 20 Dec 2016 13:26:36 +0100 writes:

> Hi all,
> I have noticed incorrect parsing of very small hexadecimal numbers
> like "0x1.dp-987". Such a hexadecimal representation can
> can be produced by sprintf() using the %a flag. The return value is
> incorrectly reported as 0 when coercing these numbers to double using
> as.double()/as.numeric(), as illustrated in the three examples below:

> as.double("0x1.dp-987")# should be 7.645296e-298
> as.double("0x1.0p-1022")  # should be 2.225074e-308
> as.double("0x1.f89fc1a6f6613p-974")  # should be 1.23456e-293

> The culprit seems to be the src/main/util.c:R_strtod function and in
> some cases, removing the zeroes directly before the 'p' leads to
> correct parsing:

> as.double("0x1.dp-987") # 7.645296e-298, as expected
> as.double("0x1.p-1022") # 2.225074e-308, as expected

Yes, this looks like a bug, indeed.
Similarly convincing is a simple comparison (of even less extreme)

> as.double("0x1p-987")
[1] 7.645296e-298
> as.double("0x1.00p-987")
[1] 0
> 

The "bug boundary" seems around here:

> as.double("0x1.p-928") # fails
[1] 0
> as.double("0x1p-928")
[1] 4.407213e-280
> 

> as.double("0x1.p-927") # works
[1] 8.814426e-280

but then adding more zeros before "p-927" also underflows.

--> I have created an R bugzilla account for you; so you now
 can submit bug reports (including patch proposals to the source (hint!) ;-)

Thank you, Florent!
Martin

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

Re: [Rd] Fwd: Re: RSiteSearch, sos, rdocumentation.org, ...?

Re: [Rd] different compilers and mzR build fails

Re: [Rd] different compilers and mzR build fails

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

Re: [Rd] Request: Increasing MAX_NUM_DLLS in Rdynload.c

Re: [Rd] different compilers and mzR build fails

[Rd] different compilers and mzR build fails

Re: [Rd] Very small numbers in hexadecimal notation parsed as zero

9 matches

Site Navigation

Mail list logo

Footer information