Tracking this issue here: https://jira.duraspace.org/browse/FCREPO-944
On 5/19/11, ps552 <peri.stracch...@york.ac.uk> wrote: > bloomin 'eck man! its been a long day - read the newspaper and chill > out!!!!!!!!! ;-D > > > Cheers > Peri Stracchino > Digital Library Team > University of York > ext 4082 > new email address peri.stracch...@york.ac.uk > > > -----Original Message----- > From: Steve Bayliss [mailto:stephen.bayl...@acuityunlimited.net] > Sent: 19 May 2011 17:37 > To: 'Support and info exchange list for Fedora users.' > Subject: Re: [fcrepo-user] REST export API negative array index exception > > Hi Ben > > That sounds entirely sensible! > > Steve > >> -----Original Message----- >> From: Benjamin Armintor [mailto:armin...@gmail.com] >> Sent: 19 May 2011 15:04 >> To: Support and info exchange list for Fedora users. >> Subject: Re: [fcrepo-user] REST export API negative array index exception >> >> Steve- >> Maybe we create an issue for the 3.6 bucket to refactor serializers >> to return an inputstream, rather than serializing to a received >> inputstream? Seems reasonable enough. >> >> - Ben >> >> On 5/19/11, Scott Hammel <sc...@clemson.edu> wrote: >> > yeah! i figured Java must have something like that. >> > >> > have a great day and thanks for all you guys are doing! >> > >> > Scott >> > >> > On 05/19/2011 01:10 AM, Stephen Bayliss wrote: >> >> Thanks for looking at that Scott. >> >> It sounds like we need an alternative such as >> >> >> http://commons.apache.org/codec/apidocs/org/apache/commons/codec/binary/Ba >> se64InputStream.html >> >> which >> >> does streaming encoding (unlimited size). >> >> Steve >> >> >> >> -----Original Message----- >> >> *From:* Scott Hammel [mailto:sc...@clemson.edu] >> >> *Sent:* 18 May 2011 21:43 >> >> *To:* Support and info exchange list for Fedora users. >> >> *Subject:* Re: [fcrepo-user] REST export API negative array index >> >> exception >> >> >> >> One last thing then I'll quit gabbing so this list doesn't stay as >> >> busy as the Solr user's list :-) just to summarize: >> >> >> >> I poked into the source for Apache Commons base64 codec 1.3 at the >> >> line indicated in my error logs: it's a line in |encodeBase64() >> >> |where a byte array is allocated for storage. To compute the array >> >> size to allocate, the method multiplies the size of the incoming >> >> binary data array by 8. So 300 MB => 300 * 2^20 * 8 which is > max >> >> int, I do believe. >> >> >> >> Next limit is the practical limit of JVM RAM on a 32-bit server: >> >> really slightly less than 2 GB. >> >> >> >> Next limit is the fact that it looks like a ByteArrayOutputStream >> >> uses a byte array as a buffer, and the limit is max int again, but >> >> this time for # of bytes in the datastream (appx 2GB). >> >> >> >> Scott >> >> >> >> On 05/18/2011 03:53 PM, Scott Hammel wrote: >> >>> I see where you are going :-) >> >>> >> >>> I just ran a 400MB test with an ATOMZip export. Seems to have >> worked >> >>> just fine. >> >>> >> >>> A 900MB datastream export to ATOMZip test failed. No exception >> >>> generated >> >>> in the logs, just an internal server error. I noticed with 3.4.2 >> this >> >>> can indicate the JVM ran out memory (not surprising if the export >> is >> >>> still being collected into a ByteArrayOutputStream, I guess). >> >>> >> >>> Scott >> >>> >> >>> On 05/18/2011 11:53 AM, Stephen Bayliss wrote: >> >>>> Hi Scott >> >>>> >> >>>> Thanks for that feedback. >> >>>> >> >>>> It would be interesting to find out if you get the same problem >> >>>> using the >> >>>> AtomZip export format (info:fedora/fedora-system:ATOMZip-1.1) >> >>>> >> >>>> Steve >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Scott Hammel [mailto:sc...@clemson.edu] >> >>>>> Sent: 18 May 2011 16:16 >> >>>>> To: Support and info exchange list for Fedora users. >> >>>>> Subject: Re: [fcrepo-user] REST export API negative array >> >>>>> index exception >> >>>>> >> >>>>> >> >>>>> Scott, Steve, >> >>>>> >> >>>>> REST export in archive format still blows up with Fedora >> >>>>> 3.4.2. Actually >> >>>>> is crashing on a datastream< 300MB. I gave the JVM 1.5GB of >> >>>>> heap, BTW. >> >>>>> >> >>>>> Regardless, the exception that is in fedora.log is a negative >> array >> >>>>> index exception. It looks like it is actually occurring down in >> the >> >>>>> base64 encoder according to the stack trace. >> >>>>> >> >>>>> It occurs to me that building support for a full archival >> >>>>> export of an >> >>>>> object in memory for arbitrarily large objects might be >> >>>>> pragmatically >> >>>>> (is that a word?) impossible: e.g., on 32-bit systems I think >> >>>>> you bump >> >>>>> into problems giving the JVM more than ~1.8 GB of RAM. That >> >>>>> alone limits >> >>>>> the size of exportable objects to well under 2GB in that >> >>>>> environment. >> >>>>> >> >>>>> If I was more adept with Java, I'd volunteer to write an >> >>>>> exporter that >> >>>>> spooled to disk, but alas, I am not and it would take me >> >>>>> twice as long >> >>>>> as someone who is. :-( >> >>>>> >> >>>>> I can take one of several alternative paths with my >> >>>>> particular project, >> >>>>> so it isn't too big an issue to *me* .... I just have to do a >> >>>>> little >> >>>>> more coding in a middle-tier. Don't know about other folks, of >> >>>>> course. >> >>>>> >> >>>>> -Scott >> >>>>> >> >>>>> On 05/18/2011 01:08 AM, Stephen Bayliss wrote: >> >>>>>> Looking at those lines of code it looks like in theory >> >>>>> there would be >> >>>>>> a problem there. Once this is confirmed we should probably >> >>>>> add a test >> >>>>>> case to the large datastreams test suite. And it is likely >> >>>>> to cause a >> >>>>>> problem with datastreams smaller than 2GB (2^31-1 as maximum >> array >> >>>>>> index) due to the archive export base64-encoding the content. >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Scott Prater [mailto:pra...@wisc.edu] >> >>>>>>> Sent: 17 May 2011 18:33 >> >>>>>>> To: Support and info exchange list for Fedora users. >> >>>>>>> Subject: Re: [fcrepo-user] REST export API negative array >> index >> >>>>>>> exception >> >>>>>>> >> >>>>>>> >> >>>>>>> Yes, trying with the latest stable version (3.4.2) would >> >>>>> be useful, >> >>>>>>> if you don't mind. There were some lowlevel garbage >> collection >> >>>>>>> problems that were fixed in the 3.4.2 release; these problems >> >>>>>>> manifested themselves in a variety of ways. >> >>>>>>> >> >>>>>>> I'm not saying this is the issue, but it wouldn't hurt to >> >>>>> verify that >> >>>>>>> your problem can be reproduced in 3.4.2. >> >>>>>>> >> >>>>>>> thanks, >> >>>>>>> >> >>>>>>> -- Scott >> >>>>>>> >> >>>>>>> On 05/17/2011 12:22 PM, Scott Hammel wrote: >> >>>>>>>> I'm pretty sure it is 3.4.0 (from files on the server it >> >>>>>>> looks like an >> >>>>>>>> August 2010 build. The server is in a totally isolated >> >>>>> network with >> >>>>>>>> nothing with GUI support that can hit the admin tools). >> >>>>>>>> >> >>>>>>>> Tomcat is the version bundled with the Fedora installer. >> >>>>>>>> >> >>>>>>>> Would you like me to be sure I'm running at the latest >> >>>>>>> version and try >> >>>>>>>> the test scripts again before you go forward? >> >>>>>>>> >> >>>>>>>> Scott >> >>>>>>>> >> >>>>>>>> On 05/17/2011 12:45 PM, Scott Prater wrote: >> >>>>>>>>> Thanks, Scott. I'll try to reproduce the problem in my >> >>>>>>> environment, >> >>>>>>>>> Fedora 3.4.2. >> >>>>>>>>> >> >>>>>>>>> Can you tell me what version of Fedora and Tomcat (or >> >>>>> other webapp >> >>>>>>>>> server) you're using? >> >>>>>>>>> >> >>>>>>>>> -- Scott >> >>>>>>>>> >> >>>>>>>>> On 05/17/2011 11:08 AM, Scott Hammel wrote: >> >>>>>>>>>> Hey, Scott, >> >>>>>>>>>> >> >>>>>>>>>> Thanks for responding. I'm more a C/C++ programmer and >> >>>>> not a Java >> >>>>>>>>>> programmer (though I sometimes play one on the >> >>>>> Internet), so I'm >> >>>>>>>>>> just guessing on the array bounds -- feels like something >> >>>>>>>>>> incrementing an int into the sign bit, though I'd think >> >>>>>>> Java would >> >>>>>>>>>> throw some array bounds exception before that happened. >> >>>>>>> Figured I'd >> >>>>>>>>>> do a little math later maybe to test my hypothesis. >> >>>>>>>>>> >> >>>>>>>>>> Recall, this was all in a 32-bit environment. I really >> >>>>>>> hope it is a >> >>>>>>>>>> non-issue and something I'm doing in the end. Note >> >>>>>>> disseminating the >> >>>>>>>>>> datastream content directly appears to work OK, which >> >>>>>>> confuses me a >> >>>>>>>>>> little, though I haven't looked to see if the code for >> >>>>> that does >> >>>>>>>>>> things differently. >> >>>>>>>>>> >> >>>>>>>>>> Anyway, here's a series of commands (extracted from my >> >>>>>>> test scripts) >> >>>>>>>>>> that should reproduce the problem: >> >>>>>>>>>> >> >>>>>>>>>> mkdir /usr/fedora/tomcat/webapps/ROOT/ingestpool >> >>>>>>>>>> mkdir /tmp/fedrun >> >>>>>>>>>> dir=/tmp/fedrun >> >>>>>>>>>> pid=test:pid01 >> >>>>>>>>>> >> >>>>>>>>>> dd if=/dev/urandom >> >>>>>>>>>> of=/usr/fedora/tomcat/webapps/ROOT/ingestpool/sample.bin >> bs=1M >> >>>>>>>>>> count=400 >> >>>>>>>>>> >> >>>>>>>>>> ./makefoxml >> $pidhttp://localhost:8080/ingestpool/sample.bin> >> >>>>>>>>>> $dir/sample.xml >> >>>>>>>>>> >> >>>>>>>>>> /usr/fedora/client/bin/fedora-ingest.sh f $dir/sample.xml >> >>>>>>>>>> info:fedora/fedora-system:FOXML-1.1 localhost:8080 >> >>>>>>> fedoraAdmin<insert >> >>>>>>>>>> pwd here> http >> >>>>>>>>>> >> >>>>>>>>>> wget -O $dir/export.xml --auth-no-challenge >> >>>>>>> --http-user=fedoraAdmin >> >>>>>>>>>> --http-password=<insert pwd here> >> >>>>>>>>>> >> >>>>>>>>>> >> http://localhost:8080/fedora/objects/$pid/export?context=archive >> >>>>>>>>>> >> >>>>>>>>>> Note: I use the REST call via a wget rather than the >> >>>>>>> provided export >> >>>>>>>>>> client scripts because it looks to me from the Java heap >> >>>>>>> explosion >> >>>>>>>>>> that the export scripts must end up doing the export >> >>>>> via the SOAP >> >>>>>>>>>> API. >> >>>>>>>>>> -- >> >>>>>>>>>> The content of makefoxml: >> >>>>>>>>>> >> >>>>>>>>>> #!/bin/bash >> >>>>>>>>>> >> >>>>>>>>>> #usage: makefoxml<pid> <refurl> >> >>>>>>>>>> #escape slashes off the URL >> >>>>>>>>>> RF=${2//\//\\/} >> >>>>>>>>>> #if you need to escape ampersands as well, uncomment this: >> >>>>>>>>>> #RF=${RF//'&'/'\&'} >> >>>>>>>>>> >> >>>>>>>>>> # make substitutions .... >> >>>>>>>>>> sed ' >> >>>>>>>>>> s/PID=""/PID="'"$1"'"/ >> >>>>>>>>>> s/rdf:about=""/rdf:about="info:fedora\/'"$1"'"/ >> >>>>>>>>>> s/dc:identifier>/dc:identifier>'"$1"'/ >> >>>>>>>>>> s/REF=""/REF="'"${RF}"'"/ >> >>>>>>>>>> '< "foxml_tpl.xml" >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> The content of foxml_tmp.xml (the sed script above does >> >>>>> the edits >> >>>>>>>>>> noted in the xml comments in this template): >> >>>>>>>>>> >> >>>>>>>>>> <?xml version="1.0" encoding="UTF-8"?> >> >>>>>>>>>> <!-- following element: set the PID attribute --> >> >>>>>>>>>> <foxml:digitalObject VERSION="1.1" PID="" >> >>>>>>>>>> xmlns:foxml="info:fedora/fedora-system:def/foxml#" >> >>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema- >> instance" >> >>>>>>>>>> xsi:schemaLocation="info:fedora/fedora-system:def/foxml# >> >>>>>>>>>> http://www.fedora.info/definitions/1/0/foxml1-1.xsd";> >> >>>>>>>>>> >> >>>>>>>>>> <foxml:objectProperties> >> >>>>>>>>>> <foxml:property >> >>>>>>>>>> NAME="info:fedora/fedora-system:def/model#state" >> >>>>>>>>>> VALUE="A"/> <foxml:property >> >>>>>>>>>> NAME="info:fedora/fedora-system:def/model#label" >> VALUE=""/> >> >>>>>>>>>> <foxml:property >> >>>>> NAME="info:fedora/fedora-system:def/model#ownerId" >> >>>>>>>>>> VALUE="fedoraAdmin"/> >> >>>>>>>>>> </foxml:objectProperties> >> >>>>>>>>>> >> >>>>>>>>>> <foxml:datastream CONTROL_GROUP="X" ID="RELS-EXT"> >> >>>>>>>>>> <foxml:datastreamVersion >> >>>>>>>>>> FORMAT_URI="info:fedora/fedora-system:FedoraRELSExt-1.0" >> >>>>>>>>>> ID="RELS-EXT.0" LABEL="RDF Statements about >> >>>>>>> this Object" >> >>>>>>>>>> MIMETYPE="application/rdf+xml"> <foxml:xmlContent> >> >>>>>>>>>> <rdf:RDF >> >>>>>>>>>> xmlns:dc="http://purl.org/dc/elements/1.1/"; >> >>>>>>>>>> >> >>>>>>> xmlns:fedora="info:fedora/fedora-system:def/relations- >> external#" >> >>>>>>> xmlns:fedora-model="info:fedora/fedora-system:def/model#" >> >>>>>>> xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"; >> >>>>>>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; >> >>>>>>>>>> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";> >> >>>>>>>>>> <!-- following element: put the PID as the value for >> >>>>> the rdf:about >> >>>>>>>>>> attribute --> <rdf:description rdf:about=""> >> >>>>>>>>>> </rdf:description> >> >>>>>>>>>> </rdf:RDF> >> >>>>>>>>>> </foxml:xmlContent> >> >>>>>>>>>> </foxml:datastreamVersion> >> >>>>>>>>>> </foxml:datastream> >> >>>>>>>>>> >> >>>>>>>>>> <foxml:datastream CONTROL_GROUP="X" ID="DC" STATE="A" >> >>>>>>>>>> VERSIONABLE="true"> <foxml:datastreamVersion ID="DC.0" >> >>>>>>> LABEL="Dublin >> >>>>>>>>>> Core Record" MIMETYPE="text/xml"> <foxml:xmlContent> >> >>>>> <oai_dc:dc >> >>>>>>>>>> xmlns:dc="http://purl.org/dc/elements/1.1/"; >> >>>>>>>>>> >> >>>>>>> xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"; >> >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> >>>>>>>>>> >> >>>>>>>>>> xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ >> >>>>>>>>>> http://www.openarchives.org/OAI/2.0/oai_dc.xsd";> >> >>>>>>>>>> <dc:title></dc:title> >> >>>>>>>>>> <dc:creator>Test Program</dc:creator> >> >>>>>>>>>> <dc:description>A test object</dc:description> >> >>>>>>>>>> <!-- following element: put the PID between the tags --> >> >>>>>>>>>> <dc:identifier></dc:identifier> </oai_dc:dc> >> >>>>>>>>>> </foxml:xmlContent> >> >>>>>>>>>> </foxml:datastreamVersion> >> >>>>>>>>>> </foxml:datastream> >> >>>>>>>>>> >> >>>>>>>>>> <foxml:datastream CONTROL_GROUP="M" ID="Content" STATE="A"> >> >>>>>>>>>> <foxml:datastreamVersion ID="Content.0" LABEL="This is >> >>>>> the object >> >>>>>>>>>> content" MIMETYPE=" application/octet-stream"> >> >>>>>>>>>> <!-- following element: put the URL to the content file >> >>>>>>> as the value >> >>>>>>>>>> for the REF attribute --> >> >>>>>>>>>> <!-- must be an http URL, e.g., >> >>>>>>>>>> http://localhost:8080/ingestpool/foxmldoc.xml --> >> >>>>>>>>>> <!-- I just create a directory "ingestpool" under >> >>>>>>>>>> /usr/fedora/tomcat/webapps/ROOT and put the files there --> >> >>>>>>>>>> <foxml:contentLocation REF="" TYPE="URL" /> >> >>>>>>>>>> </foxml:datastreamVersion> </foxml:datastream> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> </foxml:digitalObject> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On 05/17/2011 10:00 AM, Scott Prater wrote: >> >>>>>>>>>>> Scott, >> >>>>>>>>>>> >> >>>>>>>>>>> Can you come up with a test case that confirms this >> >>>>>>> limitation? If >> >>>>>>>>>>> you can provide one, I'll open up a JIRA ticket for the >> >>>>>>>>>>> issue. >> >>>>>>>>>>> >> >>>>>>>>>>> thanks, >> >>>>>>>>>>> >> >>>>>>>>>>> -- Scott >> >>>>>>>>>>> >> >>>>>>>>>>> On 05/16/2011 10:45 AM, Scott Hammel wrote: >> >>>>>>>>>>>> Oh, I think I see: last line of the serializer's >> serialize >> >>>>>>>>>>>> function does >> >>>>>>>>>>>> this: >> >>>>>>>>>>>> bytes.toByteArray() >> >>>>>>>>>>>> where bytes is a ByteArrayOutputStream >> >>>>>>>>>>>> >> >>>>>>>>>>>> I *think* the max size of an array index in Java (32-bit) >> is >> >>>>>>>>>>>> 2,147,483,647 (i.e., 2^31 - 1, max value of a java >> >>>>>>> int). So, this >> >>>>>>>>>>>> function will throw an exception if a datastream >> >>>>>>> "archive" export >> >>>>>>>>>>>> is> ~2 GB. >> >>>>>>>>>>>> >> >>>>>>>>>>>> scott >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 05/16/2011 11:00 AM, Scott Hammel wrote: >> >>>>>>>>>>>>> Hi, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Running some export tests using Fedora's REST export >> >>>>>>> API, I get a >> >>>>>>>>>>>>> negative array index Java exception when doing an >> >>>>>>> "archive" export of an >> >>>>>>>>>>>>> object at around 400 MB (>320 MB,< 450 MB). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Fedora is version 3.4 something; running on 32-bit >> >>>>> CentOS 5.5, >> >>>>>>>>>>>>> Sun Java 1.6, 21 >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Is it just me or has anyone else seen something like >> that? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>> Scott >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>> -------------------------------------------------------------- >> --- >> >>>>>>>>>>>>> ------------- >> >>>>>>>>>>>>> Achieve unprecedented app performance and reliability >> What >> >>>>>>>>>>>>> every C/C++ and Fortran developer should know. Learn >> >>>>> how Intel >> >>>>>>>>>>>>> has extended the reach of its >> >>>>>>> next-generation tools >> >>>>>>>>>>>>> to help boost performance applications - inlcuding >> >>>>>>>>>>>>> clusters. >> >>>>>>>>>>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>>> Fedora-commons-users mailing list >> >>>>>>>>>>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>>>>>>>>>> >> >>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons- >> users >> >>>>>>> >> >>>>>>> ------------------------------------------------------------------ >> >>>>>>>>>>>> ------------ >> >>>>>>>>>>>> Achieve unprecedented app performance and reliability >> >>>>> What every >> >>>>>>>>>>>> C/C++ and Fortran developer should know. Learn how Intel >> has >> >>>>>>>>>>>> extended the reach of its >> >>>>>>> next-generation tools >> >>>>>>>>>>>> to help boost performance applications - inlcuding >> clusters. >> >>>>>>>>>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>> Fedora-commons-users mailing list >> >>>>>>>>>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>>>>>>>>> >> >>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons- >> users >> >>>>> >> >>>>> -------------------------------------------------------------------- >> >>>>>>>>>> ---------- >> >>>>>>>>>> Achieve unprecedented app performance and reliability >> >>>>> What every >> >>>>>>>>>> C/C++ and Fortran developer should know. Learn how Intel >> has >> >>>>>>>>>> extended the reach of its >> >>>>>>> next-generation tools >> >>>>>>>>>> to help boost performance applications - inlcuding >> clusters. >> >>>>>>>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> Fedora-commons-users mailing list >> >>>>>>>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>>>>>>> >> >>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons- >> users >> >>>>> >> >>>>> -------------------------------------------------------------------- >> - >> >>>>>>> - >> >>>>>>>> -------- >> >>>>>>>> Achieve unprecedented app performance and reliability >> >>>>>>>> What every C/C++ and Fortran developer should know. >> >>>>>>>> Learn how Intel has extended the reach of its >> >>>>> next-generation tools >> >>>>>>>> to help boost performance applications - inlcuding clusters. >> >>>>>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>>>>> _______________________________________________ >> >>>>>>>> Fedora-commons-users mailing list >> >>>>>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>>>>> >> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> >>>>>>> -- >> >>>>>>> Scott Prater >> >>>>>>> Library, Instructional, and Research Applications (LIRA) >> >>>>>>> Division of Information Technology (DoIT) University of >> >>>>>>> Wisconsin - madisonpra...@wisc.edu >> >>>>>>> >> >>>>>>> -------------------------------------------------------------- >> >>>>>>> ---------------- >> >>>>>>> Achieve unprecedented app performance and reliability >> >>>>>>> What every C/C++ and Fortran developer should know. >> >>>>>>> Learn how Intel has extended the reach of its >> >>>>> next-generation tools >> >>>>>>> to help boost performance applications - inlcuding clusters. >> >>>>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>>>> _______________________________________________ >> >>>>>>> Fedora-commons-users mailing list >> >>>>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons- >> users >> >>>>>>> >> >>>>> >> >>>>> -------------------------------------------------------------------- >> -- >> >>>>>> -------- >> >>>>>> What Every C/C++ and Fortran developer Should Know! >> >>>>>> Read this article and learn how Intel has extended the reach of >> >>>>>> its >> >>>>>> next-generation tools to help Windows* and Linux* C/C++ and >> >>>>>> Fortran >> >>>>>> developers boost performance applications - including clusters. >> >>>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>>> _______________________________________________ >> >>>>>> Fedora-commons-users mailing list >> >>>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons- >> users >> >>>>>> >> >>>>> -------------------------------------------------------------- >> >>>>> ---------------- >> >>>>> What Every C/C++ and Fortran developer Should Know! >> >>>>> Read this article and learn how Intel has extended the reach of >> its >> >>>>> next-generation tools to help Windows* and Linux* C/C++ and >> Fortran >> >>>>> developers boost performance applications - including clusters. >> >>>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>>> _______________________________________________ >> >>>>> Fedora-commons-users mailing list >> >>>>> Fedora-commons-users@lists.sourceforge.net >> >>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons- >> users >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> --------- >> >>>> What Every C/C++ and Fortran developer Should Know! >> >>>> Read this article and learn how Intel has extended the reach of >> its >> >>>> next-generation tools to help Windows* and Linux* C/C++ and >> Fortran >> >>>> developers boost performance applications - including clusters. >> >>>> http://p.sf.net/sfu/intel-dev2devmay >> >>>> _______________________________________________ >> >>>> Fedora-commons-users mailing list >> >>>> Fedora-commons-users@lists.sourceforge.net >> >>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> >>>> >> >>> >> >>> ---------------------------------------------------------------------- >> -------- >> >>> What Every C/C++ and Fortran developer Should Know! >> >>> Read this article and learn how Intel has extended the reach of >> its >> >>> next-generation tools to help Windows* and Linux* C/C++ and >> Fortran >> >>> developers boost performance applications - including clusters. >> >>> http://p.sf.net/sfu/intel-dev2devmay >> >>> _______________________________________________ >> >>> Fedora-commons-users mailing list >> >>> Fedora-commons-users@lists.sourceforge.net >> >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> >>> >> >> >> >> >> >> ----------------------------------------------------------------------- >> ------- >> >> What Every C/C++ and Fortran developer Should Know! >> >> Read this article and learn how Intel has extended the reach of its >> >> next-generation tools to help Windows* and Linux* C/C++ and Fortran >> >> developers boost performance applications - including clusters. >> >> http://p.sf.net/sfu/intel-dev2devmay >> >> >> >> >> >> _______________________________________________ >> >> Fedora-commons-users mailing list >> >> Fedora-commons-users@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> > >> > >> >> -------------------------------------------------------------------------- >> ---- >> What Every C/C++ and Fortran developer Should Know! >> Read this article and learn how Intel has extended the reach of its >> next-generation tools to help Windows* and Linux* C/C++ and Fortran >> developers boost performance applications - including clusters. >> http://p.sf.net/sfu/intel-dev2devmay >> _______________________________________________ >> Fedora-commons-users mailing list >> Fedora-commons-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > > > ---------------------------------------------------------------------------- > -- > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
