From: Brendan M. <bre...@pr...> - 2009-06-21 20:02:48
|
Ah, yes, on my std::vector returns. I was following the lead of ToStdVector, which I copied along with the rest of WiffFile.cpp to get myself started. I had to add a special case for a zero length cli::array to mine, though, since otherwise it crashed the AgilentDataReader constructor out of the gate. If you think it is possible to have an zero length arrays for your values in WiffFile.cpp, you might want to do the same, or that case will crash. But this function does just return the std::vector, no? It led me to believe that they must be ref-counting the internal buffer, and doing a lightweight copy of the containing struct, as I believe strings do. Your response, however, seems to indicate otherwise. I'd love to see it cleaned up by someone other than me, though. ;-) Thanks again for the code review. --Brendan On Sun, Jun 21, 2009 at 12:39 PM, Brendan MacLean <bre...@pr...>wrote: > Comments in-line: > > On Sun, Jun 21, 2009 at 12:13 PM, Matt Chambers < > mat...@va...> wrote: > >> Hi Brendan, >> >> Nice work on porting Agilent to C++/CLI. There are some vectors being >> returned by value that should be returned (or passed) by reference but >> other than that it looks excellent - I will take a look at that Monday >> and see if it can be optimized with automation_vector or some adaptation >> of it (i.e. providing a std::vector interface, particularly iterators, >> as a light wrapper around a COM safearray or cli::array). > > > Thanks! Boy did I waste on enums before I realized I could just copy the > ones from the .tlh files. The VS Object Browser does not expose values. > > I knew you'd have some clean-up ideas. I am still pretty green on this > code, and even using stdlib and boost. I was unsure about returning > vectors, but thought I'd seen it elsewhere in the code. Anyway, thanks for > taking this on. > >> >> >> I have some concerns about the hack you put into Serializer_mzXML. A >> "Waters raw file" is not really a file. It's impossible to take a >> checksum of a directory (at least without a defined enumeration of all >> the files in the directory). So each DAT file must have its checksum and >> thus all DAT files should be listed as source files. I take this >> approach in Reader_Waters. If you made this change to deal with wolf-mrm >> or massWolf mzXML output, how are those converters giving a checksum for >> an entire directory? > > > Yes. Waters and Agilent both use directories, and both write this tag. > Ha! This is one from Trapper: > > <parentFile > fileName="file://HELOISE1/C/Heloise/MassHunterInstall/Data/fromChrisMiller/MixC-dMRM-06.d" > fileType="RAWData" fileSha1="" /> > > No checksum. And wolf-mrm, and I assume massWolf, since wolf-mrm and > massWolf started from the same code, but they may have fixed this? Anyway, > it has a god-awful number of these tags pointing just to the directory > itself, with a checksum for each: > > <parentFile fileName="file://QP20071218_SILAC_1_4_08.raw" > fileType="RAWData" > fileSha1="f6a00cf51f5103b07c62a198d5f06a580b25c395"/> > <parentFile fileName="file://QP20071218_SILAC_1_4_08.raw" > fileType="RAWData" > fileSha1="98f7efce2c0265b4a9ff83b6b5810f52d808bfd1"/> > <parentFile fileName="file://QP20071218_SILAC_1_4_08.raw" > fileType="RAWData" > ... > > How they hope to check any of these, I have no idea, but it is not as bad > as the T2DExtractor was when I first started work on it, and they wrote out > one of these tags for every row in an Oracle database. > > Yes, it is useful to know when a conversion is out of date with its source, > but in my opinion this feature has lead to more than an average amount of > bad software and confusion. > > Anyway, I do need Trapper mzXML to work, and it just seemed wrong to assign > Thermo to Waters mzXML. > >> >> >> Also, who released these converters which don't validate with the mzXML >> schema, which has since at least v2.1 restricted the scanType to an >> enumeration? >> <xs:enumeration value="Full"/> >> <xs:enumeration value="zoom"/> >> <xs:enumeration value="SIM"/> >> <xs:enumeration value="SRM"/> >> <xs:enumeration value="CRM"/> >> <xs:enumeration value="Q1"/> >> <xs:enumeration value="Q3"/> >> > > No argument there. I am sure you can imagine my grown when I went to look > why Trapper mzXML was not getting flagged as SRM scans. > >> >> >> Thanks, >> Matt >> >> >> ------------------------------------------------------------------------------ >> Are you an open source citizen? Join us for the Open Source Bridge >> conference! >> Portland, OR, June 17-19. Two days of sessions, one day of unconference: >> $250. >> Need another reason to go? 24-hour hacker lounge. Register today! >> >> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org >> _______________________________________________ >> proteowizard-developer mailing list >> pro...@li... >> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer >> > > |