Re: [proteowizard-developer] Build Broken

[Robert Burke <robert.burke@pr...>]

Fixing it now.

On Fri, Oct 29, 2010 at 1:22 PM, Brendan MacLean <brendanx@...> wrote:
> [11:30:45]: MascotReader_dummy.cpp
> [11:30:45]: pwiz\data\mziddata\MascotReader_dummy.cpp(45) : error C3861:
> 'runtime_error': identifier not found
> [11:30:45]: pwiz\data\mziddata\MascotReader_dummy.cpp(52) : error C3861:
> 'runtime_error': identifier not found
> [11:30:45]: pwiz\data\mziddata\MascotReader_dummy.cpp(59) : error C3861:
> 'runtime_error': identifier not found
> [11:30:45]: call "c:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\vcvarsall.bat" x86 >nul
> [11:30:45]: cl /Zm800 -nologo
> @"C:\TeamCity\agent01\work\pwiz\build-nt-x86\pwiz\data\mziddata\msvc-9.0\release\asynch-exceptions-on\link-static\threading-multi\MascotReader_dummy.obj.rsp"
> [11:30:45]: ...failed compile-c-c++
> C:\TeamCity\agent01\work\pwiz\build-nt-x86\pwiz\data\mziddata\msvc-9.0\release\asynch-exceptions-on\link-static\threading-multi\MascotReader_dummy.obj...
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> proteowizard-developer mailing list
> proteowizard-developer@...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>

[proteowizard-developer] Build Broken

[Brendan MacLean <brendanx@pr...>]

*[11:30:45]:* MascotReader_dummy.cpp
*[11:30:45]:* pwiz\data\mziddata\MascotReader_dummy.cpp(45) : error C3861:
'runtime_error': identifier not found
*[11:30:45]:* pwiz\data\mziddata\MascotReader_dummy.cpp(52) : error C3861:
'runtime_error': identifier not found
*[11:30:45]:* pwiz\data\mziddata\MascotReader_dummy.cpp(59) : error C3861:
'runtime_error': identifier not found
*[11:30:45]:* call "c:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\vcvarsall.bat" x86 >nul
*[11:30:45]:* cl /Zm800 -nologo
@"C:\TeamCity\agent01\work\pwiz\build-nt-x86\pwiz\data\mziddata\msvc-9.0\release\asynch-exceptions-on\link-static\threading-multi\MascotReader_dummy.obj.rsp"

*[11:30:45]:* ...failed compile-c-c++
C:\TeamCity\agent01\work\pwiz\build-nt-x86\pwiz\data\mziddata\msvc-9.0\release\asynch-exceptions-on\link-static\threading-multi\MascotReader_dummy.obj...

[proteowizard-developer] ProteoWizard Languages on Source Forge

[Brendan MacLean <brendanx@pr...>]

Could someone update our languages on Source Forge to include C#?
Currently, it just says C++.

Thanks.

--Brendan

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[Matthew Chambers <matt.chambers42@gm...>]

Hi Rob,

Wow. 300mb of msparser binaries? I'm glad I'm not hosting this repository! :P I am amazed they could achieve this:
msparser_2_3_01_NT_X86\vs2008\lib\msparserS.lib - 90mb
msparser_2_3_01_NT_X86\vs2008\lib\msparserDS.lib - 113mb
msparser_2_3_01_NT_X86\vs2008\lib\msparser.lib+dll - 4.5mb
Is that every .obj in the .lib getting its own copies of the MSVC runtimes? At least it compresses reasonably well, just not nearly enough (there's a version of 
those in there for every MSVC version back to VC6 and also both x86 and x86_64).

We have to cut out those huge files even if means we have to pick just a small subset of linkage/release options that will have Mascot parsing enabled. I think 
we'll be fine to support only 32-bit Windows builds and runtime-link=shared, both of which are required for vendor support. It's theoretically possible that we 
could do 64-bit Windows builds with runtime-link=static with the 90mb .lib file, but I don't think it's worth it. For MSVC version, I think we should have VC9 
and VC10 (which they didn't provide). We can do the same for the Linux libraries (exclude the .so or .a, I'm not sure which we should choose).

Also, we'll have to repackage the zips as tarballs because there's no cmd.exe access to Windows' built-in zip support.

As a preliminary test, I made a new bz2 archive from the following:
msparser_2_3_01_NT_X86\vs2008\lib\msparser.lib+dll
msparser_2_3_01_NT_X86\vs2008\include
msparser_2_3_01_LINUX_X86\lib\msparser.so.1
msparser_2_3_01_LINUX_X86\include
msparser_2_3_01_LINUX_X86_64\lib\msparser.so.1
(I excluded the other Linux include directory since it's the same size byte-for-byte which probably indicates entirely redundant)
The result was a 4.8mb archive. Vs2010 and the msparserD.lib+dll would add some onto that, but it'll still be much better than 300mb...

Thoughts?
-Matt


On 10/5/2010 5:59 PM, Robert Burke wrote:
> Matt, that was my attempt to not include the java, perl, et al files
> from msparser (which I won't do). Then, any functionality pwiz's
> Mascot to mzid reader has in non-C++ languages will come through
> calling my C++ code and not loading any java/perl/what have you code
> from msparser. That's all.
>
> I'll start looking at the MSFileReader section and plan on going that direction.
>
> -RB
>
> On Mon, Oct 4, 2010 at 11:21 AM, Brendan MacLean<brendanx@...>  wrote:
>> This sounds like a good strategy.  It has the benefit of making a build
>> without Mascot Parser trivial.
>>
>> On Mon, Oct 4, 2010 at 11:11 AM, Matthew Chambers
>> <matt.chambers42@...>  wrote:
>>>   Hi Rob,
>>>
>>> What do you mean "pwiz uses swig to manage language?"
>>>
>>> As for the build system, it sounds like the setup here will be similar to
>>> MSFileReader where we can't redistribute the binaries so the build system
>>> will need to
>>> be able to work without it. I think we need to decide whether we will have
>>> other search engine result readers in and if so, we should put them in
>>> data/vendor_readers. I know it's certainly plausible to read Protein Pilot
>>> .group results in the same way as Mascot DAT. The same goes for Thermo SRF
>>> (which
>>> IIRC is just a zipped SQLite database?). Are there any other vendor search
>>> engine formats out there to consider (that aren't XML)?
>>>
>>> -Matt
>>>
>>>
>>> On 10/1/2010 5:01 PM, Robert Burke wrote:
>>>> Hello everyone,
>>>>
>>>> I'm finishing up the my Mascot to mzid converter and am getting down
>>>> to the last two issues to be resolved (not including bugs).
>>>>
>>>> The first is how to package the libraries and include files. The
>>>> msparser API has a wide variety of languages it supports. Since pwiz
>>>> uses swig to manage language, we only need the C libraries and
>>>> headers. I'd prefer grouping the platforms by OS, 32/64-bit, and
>>>> compiler and adding a switch in the Jamroot.jam file.
>>>>
>>>> This leads to the second item. The only hitch here is section 3, item
>>>> 3: "[you may not] redistribute, encumber, sell, rent, lease,
>>>> sublicense, or otherwise transfer rights to Mascot Parser." So, could
>>>> we/should we get a written addition that would allow for the include
>>>> files or could we/should we seek redistribution of the whole package
>>>> and add an unpacking target to the Jamfile.jam? I'm leaning toward the
>>>> former despite the additional work at each upgrade of the msparser
>>>> library. I'd like to hear all your thoughts.
>>>>
>>>> Also, although I've read the additional licenses the will follow
>>>> msparser and don't see any conflict I would like to know if I've
>>>> missed anything.
>>>>
>>>> Attached is the license on Mascot's download page, and the "3rd party
>>>> licenses" page included in the msparser documentation directory.
>>>>
>>>> Thank you ahead of time for your time.
>>>>
>>>> -RB

[proteowizard-developer] Subset source tarballs

[Matthew Chambers <matt.chambers42@gm...>]

Hi pwiz clients,

I changed the way we create subset source tarballs so you have much more control over what you download. There are now three components which can be excluded:
l = libraries (the directory)
t = tests and test data
v = vendor APIs

That legend should make these filenames comprehensible:
     * pwiz-src 40.85Mb
     * pwiz-src-without-l 36.28Mb
     * pwiz-src-without-lt 8.29Mb
     * pwiz-src-without-ltv 2.78Mb
     * pwiz-src-without-lv 30.77Mb
     * pwiz-src-without-t 12.86Mb
     * pwiz-src-without-tv 7.35Mb
     * pwiz-src-without-v 35.34Mb

The without-libraries variants won't build by themselves: they require the libraries directory to be checked out as an svn:external. That directory gets changed 
less often than the rest of pwiz though so using an svn:external should be a reasonable approach.

The "pwiz-src-without-tv" variant should be good for projects which want to incorporate pwiz and don't want the vendor support.

Switching to this system was a trivial change in Jamroot which I was induced to do because the comprehensive tarball was getting too big to update in my group's 
repo every time I needed a pwiz update.

This isn't the msdata.dll that some people have been waiting for, but it provides a much smaller package for those willing to build it from source in their 
projects.

-Matt

[proteowizard-developer] Fwd: License Certificate LC-400373-D350737883-0 for dotTrace Performance Profiler

[Brendan MacLean <brendanx@pr...>]

And here is the new license for dotTrace, a performance profiler that I have
used successfully with C++ code as well as C# code.

On Wed, Oct 20, 2010 at 10:59 AM, JetBrains License <sales@...>wrote:

> IMPORTANT: THIS IS TO CERTIFY THE RIGHT TO USE THE JETBRAINS SOFTWARE
> PRODUCT, GRANTED BY JETBRAINS S.R.O. UNDER THE TERMS AND CONDITIONS OF THE
> LICENSE AGREEMENT INCLUDED WITH THE SOFTWARE. PLEASE SAVE A COPY OF THIS
> EMAIL FOR FUTURE REFERENCES.
>
>
> ========LICENSE DETAILS========
>
> Type: Open Source License
> Reference No*: LC-400373-D350737883-0
> Date of Issue: 20 October 2010
> Expiration Date: 20 October 2011
>
> * Please quote this reference when contacting JetBrains
>
> ===========LICENSEE============
>
> Name: ProteoWizard
> Customer ID: 400373
> Address: <empty>, United States
>
> =======SOFTWARE PRODUCT========
>
> Product Name: dotTrace Performance Profiler Professional Edition
> Licensed Version: 4.0 and any new product release which is made generally
> available before 20 October 2011
>
> The software is shipped electronically and is available for download from:
> http://www.jetbrains.com/profiler/download/
>
> =========INSTALLATION==========
>
> Run dotTrace Performance Profiler and follow the Installation Wizard's
> instructions. To register for use of the software or change your existing
> registration details, go to Help/License Information menu of the software
> and enter the User Name and License Key(s) included below into the
> registration dialog:
>
>
> User Name: ProteoWizard
> License Key: 400373-tdLFwQ2k2SyzTPkY8PBhMUR2yXiK7Mol
>
> ===DOCUMENTATION AND SUPPORT===
>
> dotTrace Performance Profiler documentation:
> http://www.jetbrains.com/profiler/documentation/
>
> Available support resources:
> http://www.jetbrains.com/support/
>
> Technical support contact:
> support@...
>
> Contact for the license renewal requests:
> opensource@...
>
> For questions, please contact:
> sales@...
>
>
> JetBrains Sales Team
> http://www.jetbrains.com
> "Develop with pleasure!"
>

[proteowizard-developer] Fwd: License Certificate LC-400373-D350737883-2 for ReSharper

[Brendan MacLean <brendanx@pr...>]

Hi all,
Our JetBrains tools licenses will expire in the next few weeks.  Happily
they still feel ProteoWizard is an open source project worth supporting.

Here is the new license for ReSharper.

--Brendan

---------- Forwarded message ----------
From: JetBrains License <sales@...>
Date: Wed, Oct 20, 2010 at 10:59 AM
Subject: License Certificate LC-400373-D350737883-2 for ReSharper
To: brendanx@...


IMPORTANT: THIS IS TO CERTIFY THE RIGHT TO USE THE JETBRAINS SOFTWARE
PRODUCT, GRANTED BY JETBRAINS S.R.O. UNDER THE TERMS AND CONDITIONS OF THE
LICENSE AGREEMENT INCLUDED WITH THE SOFTWARE. PLEASE SAVE A COPY OF THIS
EMAIL FOR FUTURE REFERENCES.


========LICENSE DETAILS========

Type: Open Source License
Reference No*: LC-400373-D350737883-2
Date of Issue: 20 October 2010
Expiration Date: 20 October 2011

* Please quote this reference when contacting JetBrains

===========LICENSEE============

Name: ProteoWizard
Customer ID: 400373
Address: <empty>, United States

=======SOFTWARE PRODUCT========

Product Name: ReSharper Full Edition
Licensed Version: the current version and any new product release which is
made generally available before 20 October 2011

The software is shipped electronically and is available for download from:
http://www.jetbrains.com/resharper/download/

=========INSTALLATION==========

Run ReSharper and follow the Installation Wizard's instructions. To register
for use of the software or change your existing registration details, go to
Help/Register menu of the software and enter the included below the User
Name and License Key(s) into the registration dialog:

User Name: ProteoWizard
License Key: 400373-DD5j6/Q8jWEY0Y7yYUIoKrnGMDR8yT6W

===DOCUMENTATION AND SUPPORT===

ReSharper documentation:
http://www.jetbrains.com/resharper/documentation/

Available support resources:
http://www.jetbrains.com/support/

Technical support contact:
support@...

Contact for the license renewal requests:
opensource@...

For questions, please contact:
sales.resharper@...


JetBrains Sales Team
http://www.jetbrains.com
"Develop with pleasure!"

Re: [proteowizard-developer] SVN tag/branch for 2.0 ?

[Matthew Chambers <matt.chambers42@gm...>]

  Barbara Frewen added the 'libraries' and 'pwiz-lib.tar.bz2' targets to pwiz, but unfortunately some bug in bjam prevents pwiz-lib.tar.bz2 from working 
properly on Linux. It works fine on Windows (and you can download pwiz-lib-windows-x86*.tar.bz2 it from TeamCity). For Linux, try:
quickbuild.sh libraries --prefix=pwiz-lib and you'll have:
pwiz-lib/include
pwiz-lib/lib

You may not like the way the libraries aren't consolidated into a single .a file, but that's future work (it will require a lot of changes to work on Windows).

-Matt


On 10/14/2010 10:24 AM, Steffen Neumann wrote:
> On Thu, 2010-10-14 at 10:06 -0500, Matthew Chambers wrote:
>> I use pwiz trunk in my downstream projects so I am always mindful of keeping it in a state where it's ready to use
> A working state is not my concern, I guess you do well there :-)
>
> Since I use a modified build system (similar to TPP)
> I also need stability in my hacked-up Makefile.
>
> Or do you already build an libpwiz-dev_2.1_i386.deb ?
>
> Read: a library and included header files people
> can download and link against ? This has been a long-standing
> wishlist item ...
>
> Yours,
> Steffen
>

Re: [proteowizard-developer] SVN tag/branch for 2.0 ?

[Steffen Neumann <sneumann@ip...>]

On Thu, 2010-10-14 at 10:06 -0500, Matthew Chambers wrote:
> I use pwiz trunk in my downstream projects so I am always mindful of keeping it in a state where it's ready to use

A working state is not my concern, I guess you do well there :-)

Since I use a modified build system (similar to TPP)
I also need stability in my hacked-up Makefile.

Or do you already build an libpwiz-dev_2.1_i386.deb ?

Read: a library and included header files people 
can download and link against ? This has been a long-standing 
wishlist item ...

Yours,
Steffen

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

Re: [proteowizard-developer] SVN tag/branch for 2.0 ?

[Matthew Chambers <matt.chambers42@gm...>]

   Hi Steffen,

I use pwiz trunk in my downstream projects so I am always mindful of keeping it in a state where it's ready to use (or at least, the parts I use: msdata, 
proteome, CLI bindings, SeeMS, msconvert, most of spectrum_processing, on both Windows and Linux). If this ever becomes a barrier to development of new features 
we will switch to a branching system. It has been extremely convenient to rely on TeamCity for building/testing/hosting our trunk snapshot releases. Changing to 
a branching system will require a more complex TeamCity setup. Which isn't a big deal, it's just not going to happen until it's necessary. Until then I suggest 
you refer to specific revisions inside trunk instead of the HEAD revision (if that's what you're currently doing).

Trunk is already at 2.1 but it should really be 2.2 by now. When we have people using our mzIdentML support regularly (without many problems) we will bump to 3.0.

Thanks,
-Matt


On 10/14/2010 9:40 AM, Steffen Neumann wrote:
> Hi,
>
> is there any reason why there is neither
> a pwiz_2_0 branch nor tag in SVN ?
>
> In XCMS I use a hairy script to pull
> the code from your SVN, which I'd like
> to base against some rather stable branch
> and not trunk.
>
> BTW, what are the near future plans
> for something like e.g. a 2.1 ?
>
> Yours,
> Steffen
>

[proteowizard-developer] SVN tag/branch for 2.0 ?

[Steffen Neumann <sneumann@ip...>]

Hi,

is there any reason why there is neither 
a pwiz_2_0 branch nor tag in SVN ? 

In XCMS I use a hairy script to pull 
the code from your SVN, which I'd like 
to base against some rather stable branch
and not trunk.

BTW, what are the near future plans 
for something like e.g. a 2.1 ?

Yours,
Steffen

-- 
IPB Halle                    AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann          http://www.IPB-Halle.DE
Weinberg 3                   http://msbi.bic-gh.de
06120 Halle                  Tel. +49 (0) 345 5582 - 1470
                                  +49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE     Fax. +49 (0) 345 5582 - 1409

Re: [proteowizard-developer] .mgf parsing

[B. Frewen <frewen@u.washington.edu>]

OK, those changes are checked in.  Thanks for your help!

Barbara


On Wed, 13 Oct 2010, Matthew Chambers wrote:

>  Yes, I think that's a fair solution. Hopefully it's not a slippery slope. ;)
>
> -Matt
>
>
> On 10/13/2010 1:16 PM, B. Frewen wrote:
>> OK, I could use findSpotID.  Any objection to me implementing that as you
>> described?  SpectrumList_MGF would have a mapping of TITLE->IndexList and
>> findSpotID(title_string) would return that IndexList.
>>
>> Thanks,
>> Barbara
>>
>>
>> On Wed, 13 Oct 2010, Matthew Chambers wrote:
>>
>>>   Actually SpectrumList::find has to return a single index, so either you have to accept that sometimes you'll have duplicates and always return the first, or
>>> maybe findSpotID could just be used instead. Kind of evil, but since the only way to get the spot ID from MGF is probably from the TITLE field anyway, it makes
>>> a perverted kind of sense.
>>>
>>> -Matt
>>>
>>>
>>> On 10/13/2010 10:09 AM, Matthew Chambers wrote:
>>>>   Hi Barbara,
>>>>
>>>> That TODO is from mzML 1.0 when the nativeID formats weren't set in stone. Since mzML 1.1, the SpectrumIdentity::id MUST conform to a nativeID format. For MGF
>>>> the default is "index=123" but it's conceivable to parse some formats of the TITLE field and use it to create an id corresponding to a vendor type (or at
>>>> least a scan number, which is at least for Thermo/Agilent/Bruker almost as good as a real nativeID). We might consider porting some of TPP's mascot2xml logic
>>>> for this purpose, but I haven't had time to look at it.
>>>>
>>>> E.g.
>>>> TITLE=data.123.123.2 ->  scan number only nativeID format ->  scan=123
>>>> TITLE=Locus:4.1.1.123.2 ->  WIFF nativeID format ->  sample=1 period=1 cycle=1 experiment=2
>>>>
>>>> Now, on the other hand, there is a CV term for "spectrum title" which we could add to MGF spectra using the TITLE field as the value. It might even be
>>>> reasonable to have SpectrumList_MGF build an index of TITLE->IndexList (like SpectrumList::findSpotID) and then SpectrumList_MGF::find could take either a
>>>> nativeID OR a title. Is that what you want?
>>>>
>>>> -Matt
>>>>
>>>>
>>>> On 10/12/2010 6:12 PM, B. Frewen wrote:
>>>>> Hello,
>>>>>
>>>>> I am trying to write an application that parses .mgf files and I would
>>>>> like to be able to select a spectrum based on the string that follows
>>>>> 'TITLE='.  As far as I can tell, this field is not currently saved.  Is
>>>>> that true?
>>>>>
>>>>> I see a TODO in SpectrumList_MGF.cpp and a few lines of code that would
>>>>> use the TITLE= line as the id in the index.  Is there any reason for me
>>>>> not to uncomment these lines and check in the changes?  I tried a tiny
>>>>> test and it seemed to work as expected.  Just wanted to make sure there
>>>>> was not some outstanding issue that needs to be resolved first.
>>>>>
>>>>> Thanks,
>>>>> Barbara
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> proteowizard-developer mailing list
> proteowizard-developer@...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>

Re: [proteowizard-developer] .mgf parsing

[Matthew Chambers <matt.chambers42@gm...>]

  Yes, I think that's a fair solution. Hopefully it's not a slippery slope. ;)

-Matt


On 10/13/2010 1:16 PM, B. Frewen wrote:
> OK, I could use findSpotID.  Any objection to me implementing that as you
> described?  SpectrumList_MGF would have a mapping of TITLE->IndexList and
> findSpotID(title_string) would return that IndexList.
>
> Thanks,
> Barbara
>
>
> On Wed, 13 Oct 2010, Matthew Chambers wrote:
>
>>   Actually SpectrumList::find has to return a single index, so either you have to accept that sometimes you'll have duplicates and always return the first, or
>> maybe findSpotID could just be used instead. Kind of evil, but since the only way to get the spot ID from MGF is probably from the TITLE field anyway, it makes
>> a perverted kind of sense.
>>
>> -Matt
>>
>>
>> On 10/13/2010 10:09 AM, Matthew Chambers wrote:
>>>   Hi Barbara,
>>>
>>> That TODO is from mzML 1.0 when the nativeID formats weren't set in stone. Since mzML 1.1, the SpectrumIdentity::id MUST conform to a nativeID format. For MGF
>>> the default is "index=123" but it's conceivable to parse some formats of the TITLE field and use it to create an id corresponding to a vendor type (or at
>>> least a scan number, which is at least for Thermo/Agilent/Bruker almost as good as a real nativeID). We might consider porting some of TPP's mascot2xml logic
>>> for this purpose, but I haven't had time to look at it.
>>>
>>> E.g.
>>> TITLE=data.123.123.2 ->  scan number only nativeID format ->  scan=123
>>> TITLE=Locus:4.1.1.123.2 ->  WIFF nativeID format ->  sample=1 period=1 cycle=1 experiment=2
>>>
>>> Now, on the other hand, there is a CV term for "spectrum title" which we could add to MGF spectra using the TITLE field as the value. It might even be
>>> reasonable to have SpectrumList_MGF build an index of TITLE->IndexList (like SpectrumList::findSpotID) and then SpectrumList_MGF::find could take either a
>>> nativeID OR a title. Is that what you want?
>>>
>>> -Matt
>>>
>>>
>>> On 10/12/2010 6:12 PM, B. Frewen wrote:
>>>> Hello,
>>>>
>>>> I am trying to write an application that parses .mgf files and I would
>>>> like to be able to select a spectrum based on the string that follows
>>>> 'TITLE='.  As far as I can tell, this field is not currently saved.  Is
>>>> that true?
>>>>
>>>> I see a TODO in SpectrumList_MGF.cpp and a few lines of code that would
>>>> use the TITLE= line as the id in the index.  Is there any reason for me
>>>> not to uncomment these lines and check in the changes?  I tried a tiny
>>>> test and it seemed to work as expected.  Just wanted to make sure there
>>>> was not some outstanding issue that needs to be resolved first.
>>>>
>>>> Thanks,
>>>> Barbara

Re: [proteowizard-developer] .mgf parsing

[B. Frewen <frewen@u.washington.edu>]

OK, I could use findSpotID.  Any objection to me implementing that as you 
described?  SpectrumList_MGF would have a mapping of TITLE->IndexList and 
findSpotID(title_string) would return that IndexList.

Thanks,
Barbara


On Wed, 13 Oct 2010, Matthew Chambers wrote:

>  Actually SpectrumList::find has to return a single index, so either you have to accept that sometimes you'll have duplicates and always return the first, or
> maybe findSpotID could just be used instead. Kind of evil, but since the only way to get the spot ID from MGF is probably from the TITLE field anyway, it makes
> a perverted kind of sense.
>
> -Matt
>
>
> On 10/13/2010 10:09 AM, Matthew Chambers wrote:
>>  Hi Barbara,
>>
>> That TODO is from mzML 1.0 when the nativeID formats weren't set in stone. Since mzML 1.1, the SpectrumIdentity::id MUST conform to a nativeID format. For MGF
>> the default is "index=123" but it's conceivable to parse some formats of the TITLE field and use it to create an id corresponding to a vendor type (or at
>> least a scan number, which is at least for Thermo/Agilent/Bruker almost as good as a real nativeID). We might consider porting some of TPP's mascot2xml logic
>> for this purpose, but I haven't had time to look at it.
>>
>> E.g.
>> TITLE=data.123.123.2 -> scan number only nativeID format -> scan=123
>> TITLE=Locus:4.1.1.123.2 -> WIFF nativeID format -> sample=1 period=1 cycle=1 experiment=2
>>
>> Now, on the other hand, there is a CV term for "spectrum title" which we could add to MGF spectra using the TITLE field as the value. It might even be
>> reasonable to have SpectrumList_MGF build an index of TITLE->IndexList (like SpectrumList::findSpotID) and then SpectrumList_MGF::find could take either a
>> nativeID OR a title. Is that what you want?
>>
>> -Matt
>>
>>
>> On 10/12/2010 6:12 PM, B. Frewen wrote:
>>> Hello,
>>>
>>> I am trying to write an application that parses .mgf files and I would
>>> like to be able to select a spectrum based on the string that follows
>>> 'TITLE='.  As far as I can tell, this field is not currently saved.  Is
>>> that true?
>>>
>>> I see a TODO in SpectrumList_MGF.cpp and a few lines of code that would
>>> use the TITLE= line as the id in the index.  Is there any reason for me
>>> not to uncomment these lines and check in the changes?  I tried a tiny
>>> test and it seemed to work as expected.  Just wanted to make sure there
>>> was not some outstanding issue that needs to be resolved first.
>>>
>>> Thanks,
>>> Barbara
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> proteowizard-developer mailing list
> proteowizard-developer@...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>

Re: [proteowizard-developer] .mgf parsing

[B. Frewen <frewen@u.washington.edu>]

Hi Matt,

On Wed, 13 Oct 2010, Matthew Chambers wrote:

> Now, on the other hand, there is a CV term for "spectrum title" which we 
> could add to MGF spectra using the TITLE field as the value. It might 
> even be reasonable to have SpectrumList_MGF build an index of 
> TITLE->IndexList (like SpectrumList::findSpotID) and then 
> SpectrumList_MGF::find could take either a nativeID OR a title. Is that 
> what you want?
>
That would be perfect.  How would we determine if find had been passed a 
nativeID or a title?  Just try both indexes and see which one gave a 
result?  I should look at findSpotID to figure out what that is.

thanks,
Barbara

Re: [proteowizard-developer] .mgf parsing

[Matthew Chambers <matt.chambers42@gm...>]

  Actually SpectrumList::find has to return a single index, so either you have to accept that sometimes you'll have duplicates and always return the first, or 
maybe findSpotID could just be used instead. Kind of evil, but since the only way to get the spot ID from MGF is probably from the TITLE field anyway, it makes 
a perverted kind of sense.

-Matt


On 10/13/2010 10:09 AM, Matthew Chambers wrote:
>  Hi Barbara,
>
> That TODO is from mzML 1.0 when the nativeID formats weren't set in stone. Since mzML 1.1, the SpectrumIdentity::id MUST conform to a nativeID format. For MGF 
> the default is "index=123" but it's conceivable to parse some formats of the TITLE field and use it to create an id corresponding to a vendor type (or at 
> least a scan number, which is at least for Thermo/Agilent/Bruker almost as good as a real nativeID). We might consider porting some of TPP's mascot2xml logic 
> for this purpose, but I haven't had time to look at it.
>
> E.g.
> TITLE=data.123.123.2 -> scan number only nativeID format -> scan=123
> TITLE=Locus:4.1.1.123.2 -> WIFF nativeID format -> sample=1 period=1 cycle=1 experiment=2
>
> Now, on the other hand, there is a CV term for "spectrum title" which we could add to MGF spectra using the TITLE field as the value. It might even be 
> reasonable to have SpectrumList_MGF build an index of TITLE->IndexList (like SpectrumList::findSpotID) and then SpectrumList_MGF::find could take either a 
> nativeID OR a title. Is that what you want?
>
> -Matt
>
>
> On 10/12/2010 6:12 PM, B. Frewen wrote:
>> Hello,
>>
>> I am trying to write an application that parses .mgf files and I would
>> like to be able to select a spectrum based on the string that follows
>> 'TITLE='.  As far as I can tell, this field is not currently saved.  Is
>> that true?
>>
>> I see a TODO in SpectrumList_MGF.cpp and a few lines of code that would
>> use the TITLE= line as the id in the index.  Is there any reason for me
>> not to uncomment these lines and check in the changes?  I tried a tiny
>> test and it seemed to work as expected.  Just wanted to make sure there
>> was not some outstanding issue that needs to be resolved first.
>>
>> Thanks,
>> Barbara

Re: [proteowizard-developer] .mgf parsing

[Matthew Chambers <matt.chambers42@gm...>]

  Hi Barbara,

That TODO is from mzML 1.0 when the nativeID formats weren't set in stone. Since mzML 1.1, the SpectrumIdentity::id MUST conform to a nativeID format. For MGF 
the default is "index=123" but it's conceivable to parse some formats of the TITLE field and use it to create an id corresponding to a vendor type (or at least 
a scan number, which is at least for Thermo/Agilent/Bruker almost as good as a real nativeID). We might consider porting some of TPP's mascot2xml logic for this 
purpose, but I haven't had time to look at it.

E.g.
TITLE=data.123.123.2 -> scan number only nativeID format -> scan=123
TITLE=Locus:4.1.1.123.2 -> WIFF nativeID format -> sample=1 period=1 cycle=1 experiment=2

Now, on the other hand, there is a CV term for "spectrum title" which we could add to MGF spectra using the TITLE field as the value. It might even be 
reasonable to have SpectrumList_MGF build an index of TITLE->IndexList (like SpectrumList::findSpotID) and then SpectrumList_MGF::find could take either a 
nativeID OR a title. Is that what you want?

-Matt


On 10/12/2010 6:12 PM, B. Frewen wrote:
> Hello,
>
> I am trying to write an application that parses .mgf files and I would
> like to be able to select a spectrum based on the string that follows
> 'TITLE='.  As far as I can tell, this field is not currently saved.  Is
> that true?
>
> I see a TODO in SpectrumList_MGF.cpp and a few lines of code that would
> use the TITLE= line as the id in the index.  Is there any reason for me
> not to uncomment these lines and check in the changes?  I tried a tiny
> test and it seemed to work as expected.  Just wanted to make sure there
> was not some outstanding issue that needs to be resolved first.
>
> Thanks,
> Barbara

[proteowizard-developer] .mgf parsing

[B. Frewen <frewen@u.washington.edu>]

Hello,

I am trying to write an application that parses .mgf files and I would 
like to be able to select a spectrum based on the string that follows 
'TITLE='.  As far as I can tell, this field is not currently saved.  Is 
that true?

I see a TODO in SpectrumList_MGF.cpp and a few lines of code that would 
use the TITLE= line as the id in the index.  Is there any reason for me 
not to uncomment these lines and check in the changes?  I tried a tiny 
test and it seemed to work as expected.  Just wanted to make sure there 
was not some outstanding issue that needs to be resolved first.

Thanks,
Barbara

[proteowizard-developer] Scaffold .mzid files

[B. Frewen <frewen@u.washington.edu>]

Hello,

I am trying to build an application that parses mzIdentML files using a 
pwiz MzIdentMLFile object.  The mzIdentML files are produced by Scaffold. 
Both examples I have give me an error and I was wondering if anyone had 
worked with these files.  Perhaps there is a known issue?

I get the same error using the command line tool mzidtxt, as follows

$ ./mzidtxt orbi3protexport.mzid orbi3protexport.txt
[References::resolve()] Failed to resolve reference.
   object type: N4pwiz8mziddata11SpectraDataE
   reference id: Scaffold_Spectrum_DATA_o100720_3prot_02.RAW (F001608)
   referent list: 1
     Scaffold_Spectrum_DATA_o100720_3prot_01.RAW (F001607)

Suggestions?  I can provide the files on request.

Thanks,

Barbara Frewen

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[Robert Burke <robert.burke@pr...>]

Matt, that was my attempt to not include the java, perl, et al files
from msparser (which I won't do). Then, any functionality pwiz's
Mascot to mzid reader has in non-C++ languages will come through
calling my C++ code and not loading any java/perl/what have you code
from msparser. That's all.

I'll start looking at the MSFileReader section and plan on going that direction.

-RB

On Mon, Oct 4, 2010 at 11:21 AM, Brendan MacLean <brendanx@...> wrote:
> This sounds like a good strategy.  It has the benefit of making a build
> without Mascot Parser trivial.
>
> On Mon, Oct 4, 2010 at 11:11 AM, Matthew Chambers
> <matt.chambers42@...> wrote:
>>
>>  Hi Rob,
>>
>> What do you mean "pwiz uses swig to manage language?"
>>
>> As for the build system, it sounds like the setup here will be similar to
>> MSFileReader where we can't redistribute the binaries so the build system
>> will need to
>> be able to work without it. I think we need to decide whether we will have
>> other search engine result readers in and if so, we should put them in
>> data/vendor_readers. I know it's certainly plausible to read Protein Pilot
>> .group results in the same way as Mascot DAT. The same goes for Thermo SRF
>> (which
>> IIRC is just a zipped SQLite database?). Are there any other vendor search
>> engine formats out there to consider (that aren't XML)?
>>
>> -Matt
>>
>>
>> On 10/1/2010 5:01 PM, Robert Burke wrote:
>> > Hello everyone,
>> >
>> > I'm finishing up the my Mascot to mzid converter and am getting down
>> > to the last two issues to be resolved (not including bugs).
>> >
>> > The first is how to package the libraries and include files. The
>> > msparser API has a wide variety of languages it supports. Since pwiz
>> > uses swig to manage language, we only need the C libraries and
>> > headers. I'd prefer grouping the platforms by OS, 32/64-bit, and
>> > compiler and adding a switch in the Jamroot.jam file.
>> >
>> > This leads to the second item. The only hitch here is section 3, item
>> > 3: "[you may not] redistribute, encumber, sell, rent, lease,
>> > sublicense, or otherwise transfer rights to Mascot Parser." So, could
>> > we/should we get a written addition that would allow for the include
>> > files or could we/should we seek redistribution of the whole package
>> > and add an unpacking target to the Jamfile.jam? I'm leaning toward the
>> > former despite the additional work at each upgrade of the msparser
>> > library. I'd like to hear all your thoughts.
>> >
>> > Also, although I've read the additional licenses the will follow
>> > msparser and don't see any conflict I would like to know if I've
>> > missed anything.
>> >
>> > Attached is the license on Mascot's download page, and the "3rd party
>> > licenses" page included in the msparser documentation directory.
>> >
>> > Thank you ahead of time for your time.
>> >
>> > -RB
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization is moving to the mainstream and overtaking non-virtualized
>> environment for deploying applications. Does it make network security
>> easier or more difficult to achieve? Read this whitepaper to separate the
>> two and get a better understanding.
>> http://p.sf.net/sfu/hp-phase2-d2d
>> _______________________________________________
>> proteowizard-developer mailing list
>> proteowizard-developer@...
>> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> proteowizard-developer mailing list
> proteowizard-developer@...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[Brendan MacLean <brendanx@pr...>]

This sounds like a good strategy.  It has the benefit of making a build
without Mascot Parser trivial.

On Mon, Oct 4, 2010 at 11:11 AM, Matthew Chambers <matt.chambers42@...
> wrote:

>  Hi Rob,
>
> What do you mean "pwiz uses swig to manage language?"
>
> As for the build system, it sounds like the setup here will be similar to
> MSFileReader where we can't redistribute the binaries so the build system
> will need to
> be able to work without it. I think we need to decide whether we will have
> other search engine result readers in and if so, we should put them in
> data/vendor_readers. I know it's certainly plausible to read Protein Pilot
> .group results in the same way as Mascot DAT. The same goes for Thermo SRF
> (which
> IIRC is just a zipped SQLite database?). Are there any other vendor search
> engine formats out there to consider (that aren't XML)?
>
> -Matt
>
>
> On 10/1/2010 5:01 PM, Robert Burke wrote:
> > Hello everyone,
> >
> > I'm finishing up the my Mascot to mzid converter and am getting down
> > to the last two issues to be resolved (not including bugs).
> >
> > The first is how to package the libraries and include files. The
> > msparser API has a wide variety of languages it supports. Since pwiz
> > uses swig to manage language, we only need the C libraries and
> > headers. I'd prefer grouping the platforms by OS, 32/64-bit, and
> > compiler and adding a switch in the Jamroot.jam file.
> >
> > This leads to the second item. The only hitch here is section 3, item
> > 3: "[you may not] redistribute, encumber, sell, rent, lease,
> > sublicense, or otherwise transfer rights to Mascot Parser." So, could
> > we/should we get a written addition that would allow for the include
> > files or could we/should we seek redistribution of the whole package
> > and add an unpacking target to the Jamfile.jam? I'm leaning toward the
> > former despite the additional work at each upgrade of the msparser
> > library. I'd like to hear all your thoughts.
> >
> > Also, although I've read the additional licenses the will follow
> > msparser and don't see any conflict I would like to know if I've
> > missed anything.
> >
> > Attached is the license on Mascot's download page, and the "3rd party
> > licenses" page included in the msparser documentation directory.
> >
> > Thank you ahead of time for your time.
> >
> > -RB
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> proteowizard-developer mailing list
> proteowizard-developer@...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[Brendan MacLean <brendanx@pr...>]

One other thing I would like to point out is that Mascot Parser, when
statically linked, adds a good bit to the size of your executable.  I can't
remember the exact number, but I was surprised.  This was explained as being
caused by their use of Xerces to parse XML.

So, I get nervous about seeing that size increase in pwiz_bindings_cli.dll.
Any way around this?  When you do make this change, if you could remind us
how much exactly it impacts pwiz_bindings_cli.dll size exactly, if at all,
that would be nice.

Thanks.  Good luck.

--Brendan

On Mon, Oct 4, 2010 at 10:57 AM, Robert Burke <robert.burke@...
> wrote:

> Great! I'll be extracting the minimal files and checking in the
> changes over the week.
>
> Thank you both.
>
> -RB
>
> On Mon, Oct 4, 2010 at 4:07 AM, David Creasy <dcreasy@...>
> wrote:
> > Hi Robert,
> >
> > Yes, what Brendan says is correct. The aim of the license is to make it
> easy
> > for someone to download, install and run your application without
> requiring
> > them to install anything else. Hence item #2 specifically refers to the
> > "execution of your application".
> >
> >> Since pwizuses swig to manage language, we only need the C libraries and
> >> headers.
> > This presumably refers to you making the source of your application
> > available? The license doesn't cover that, so you would need to point
> people
> > to the Mascot parser download page and tell them where to unpack it so
> that
> > they can build pwiz. Is there a problem with this?
> >
> > --David
> >
> > Brendan MacLean wrote:
> >
> > Hi Robert,
> > The licensing scheme Parag, Matt and I came up with this week for
> > ProteoWizard should work fine for the Mascot Parser, because it roughly
> > parallels what I am already doing for Skyline, and that is fine for the
> > Mascot Parser.  I think you abbreviated your quote from the license a
> little
> > too much:
> >
> > "Except as expressly provided elsewhere in this agreement, you may not:"
> > ...
> > "redistribute, encumber, sell, rent, lease, sublicense, or otherwise
> > transfer rights to Mascot Parser; "
> >
> > And elsewhere says:
> >
> > If you write a software application that uses Mascot Parser, you may
> > distribute selected files from Mascot Parser as components of your
> > application, subject to the following conditions:
> >
> > You do not charge any form of licence fee for the application. Nominal
> > charges for media and shipping are acceptable, but if you want to
> > incorporate Mascot Parser into a commercial application, you cannot use
> this
> > licence.
> > You include only those files from Mascot Parser that are strictly
> necessary
> > to enable execution of your application. You may not redistribute other
> > files from Mascot Parser, such as the documentation.
> > Your application must add substantial new and independent functionality
> to
> > that of Mascot Parser. You must not expose individual Mascot Parser
> > functions and interfaces as separately invokable entities
> > Your application must acknowledge the use of Mascot Parser on the splash
> > screen or in the accompanying documentation.
> > There must be no suggestion that Matrix Science approves, endorses or
> > promotes your application, and you may not use any Matrix Science logo or
> > trademark outside the acknowledgement text and technical documentation.
> >
> > The Matrix Science guys have assured me that this was designed to work
> for
> > academic software like Skyline.  Definitely contact them, but I would
> expect
> > them to agree that their license already works for ProteoWizard to the
> same
> > extent that the vendor licenses we are working on will work for
> > ProteoWizard.  For profit ventures that use the library will still have
> to
> > seek a different license from Matrix Science, just as they will from the
> > vendors, if they want to redistribute their libraries.  Academic
> protoemics
> > software with no associated commercial gain should be able to
> redistribute
> > under these licenses.
> >
> > --Brendan
> >
> > On Fri, Oct 1, 2010 at 3:01 PM, Robert Burke <
> robert.burke@...>
> > wrote:
> >>
> >> Hello everyone,
> >>
> >> I'm finishing up the my Mascot to mzid converter and am getting down
> >> to the last two issues to be resolved (not including bugs).
> >>
> >> The first is how to package the libraries and include files. The
> >> msparser API has a wide variety of languages it supports. Since pwiz
> >> uses swig to manage language, we only need the C libraries and
> >> headers. I'd prefer grouping the platforms by OS, 32/64-bit, and
> >> compiler and adding a switch in the Jamroot.jam file.
> >>
> >> This leads to the second item. The only hitch here is section 3, item
> >> 3: "[you may not] redistribute, encumber, sell, rent, lease,
> >> sublicense, or otherwise transfer rights to Mascot Parser." So, could
> >> we/should we get a written addition that would allow for the include
> >> files or could we/should we seek redistribution of the whole package
> >> and add an unpacking target to the Jamfile.jam? I'm leaning toward the
> >> former despite the additional work at each upgrade of the msparser
> >> library. I'd like to hear all your thoughts.
> >>
> >> Also, although I've read the additional licenses the will follow
> >> msparser and don't see any conflict I would like to know if I've
> >> missed anything.
> >>
> >> Attached is the license on Mascot's download page, and the "3rd party
> >> licenses" page included in the msparser documentation directory.
> >>
> >> Thank you ahead of time for your time.
> >>
> >> -RB
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Start uncovering the many advantages of virtual appliances
> >> and start using them to simplify application deployment and
> >> accelerate your shift to cloud computing.
> >> http://p.sf.net/sfu/novell-sfdev2dev
> >> _______________________________________________
> >> proteowizard-developer mailing list
> >> proteowizard-developer@...
> >> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
> >>
> >
> >
> > --
> > David Creasy
> > Matrix Science
> > 64 Baker Street
> > London W1U 7GB, UK
> > Tel: +44 (0)20 7486 1050
> > Fax: +44 (0)20 7224 1344
> >
> > dcreasy@...
> > http://www.matrixscience.com
> >
> > Matrix Science Ltd. is registered in England and Wales
> > Company number 3533898
> >
> >
> ------------------------------------------------------------------------------
> > Virtualization is moving to the mainstream and overtaking non-virtualized
> > environment for deploying applications. Does it make network security
> > easier or more difficult to achieve? Read this whitepaper to separate the
> > two and get a better understanding.
> > http://p.sf.net/sfu/hp-phase2-d2d
> > _______________________________________________
> > proteowizard-developer mailing list
> > proteowizard-developer@...
> > https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
> >
> >
>

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[Matthew Chambers <matt.chambers42@gm...>]

  Hi Rob,

What do you mean "pwiz uses swig to manage language?"

As for the build system, it sounds like the setup here will be similar to MSFileReader where we can't redistribute the binaries so the build system will need to 
be able to work without it. I think we need to decide whether we will have other search engine result readers in and if so, we should put them in 
data/vendor_readers. I know it's certainly plausible to read Protein Pilot .group results in the same way as Mascot DAT. The same goes for Thermo SRF (which 
IIRC is just a zipped SQLite database?). Are there any other vendor search engine formats out there to consider (that aren't XML)?

-Matt


On 10/1/2010 5:01 PM, Robert Burke wrote:
> Hello everyone,
>
> I'm finishing up the my Mascot to mzid converter and am getting down
> to the last two issues to be resolved (not including bugs).
>
> The first is how to package the libraries and include files. The
> msparser API has a wide variety of languages it supports. Since pwiz
> uses swig to manage language, we only need the C libraries and
> headers. I'd prefer grouping the platforms by OS, 32/64-bit, and
> compiler and adding a switch in the Jamroot.jam file.
>
> This leads to the second item. The only hitch here is section 3, item
> 3: "[you may not] redistribute, encumber, sell, rent, lease,
> sublicense, or otherwise transfer rights to Mascot Parser." So, could
> we/should we get a written addition that would allow for the include
> files or could we/should we seek redistribution of the whole package
> and add an unpacking target to the Jamfile.jam? I'm leaning toward the
> former despite the additional work at each upgrade of the msparser
> library. I'd like to hear all your thoughts.
>
> Also, although I've read the additional licenses the will follow
> msparser and don't see any conflict I would like to know if I've
> missed anything.
>
> Attached is the license on Mascot's download page, and the "3rd party
> licenses" page included in the msparser documentation directory.
>
> Thank you ahead of time for your time.
>
> -RB

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[Robert Burke <robert.burke@pr...>]

Great! I'll be extracting the minimal files and checking in the
changes over the week.

Thank you both.

-RB

On Mon, Oct 4, 2010 at 4:07 AM, David Creasy <dcreasy@...> wrote:
> Hi Robert,
>
> Yes, what Brendan says is correct. The aim of the license is to make it easy
> for someone to download, install and run your application without requiring
> them to install anything else. Hence item #2 specifically refers to the
> "execution of your application".
>
>> Since pwizuses swig to manage language, we only need the C libraries and
>> headers.
> This presumably refers to you making the source of your application
> available? The license doesn't cover that, so you would need to point people
> to the Mascot parser download page and tell them where to unpack it so that
> they can build pwiz. Is there a problem with this?
>
> --David
>
> Brendan MacLean wrote:
>
> Hi Robert,
> The licensing scheme Parag, Matt and I came up with this week for
> ProteoWizard should work fine for the Mascot Parser, because it roughly
> parallels what I am already doing for Skyline, and that is fine for the
> Mascot Parser.  I think you abbreviated your quote from the license a little
> too much:
>
> "Except as expressly provided elsewhere in this agreement, you may not:"
> ...
> "redistribute, encumber, sell, rent, lease, sublicense, or otherwise
> transfer rights to Mascot Parser; "
>
> And elsewhere says:
>
> If you write a software application that uses Mascot Parser, you may
> distribute selected files from Mascot Parser as components of your
> application, subject to the following conditions:
>
> You do not charge any form of licence fee for the application. Nominal
> charges for media and shipping are acceptable, but if you want to
> incorporate Mascot Parser into a commercial application, you cannot use this
> licence.
> You include only those files from Mascot Parser that are strictly necessary
> to enable execution of your application. You may not redistribute other
> files from Mascot Parser, such as the documentation.
> Your application must add substantial new and independent functionality to
> that of Mascot Parser. You must not expose individual Mascot Parser
> functions and interfaces as separately invokable entities
> Your application must acknowledge the use of Mascot Parser on the splash
> screen or in the accompanying documentation.
> There must be no suggestion that Matrix Science approves, endorses or
> promotes your application, and you may not use any Matrix Science logo or
> trademark outside the acknowledgement text and technical documentation.
>
> The Matrix Science guys have assured me that this was designed to work for
> academic software like Skyline.  Definitely contact them, but I would expect
> them to agree that their license already works for ProteoWizard to the same
> extent that the vendor licenses we are working on will work for
> ProteoWizard.  For profit ventures that use the library will still have to
> seek a different license from Matrix Science, just as they will from the
> vendors, if they want to redistribute their libraries.  Academic protoemics
> software with no associated commercial gain should be able to redistribute
> under these licenses.
>
> --Brendan
>
> On Fri, Oct 1, 2010 at 3:01 PM, Robert Burke <robert.burke@...>
> wrote:
>>
>> Hello everyone,
>>
>> I'm finishing up the my Mascot to mzid converter and am getting down
>> to the last two issues to be resolved (not including bugs).
>>
>> The first is how to package the libraries and include files. The
>> msparser API has a wide variety of languages it supports. Since pwiz
>> uses swig to manage language, we only need the C libraries and
>> headers. I'd prefer grouping the platforms by OS, 32/64-bit, and
>> compiler and adding a switch in the Jamroot.jam file.
>>
>> This leads to the second item. The only hitch here is section 3, item
>> 3: "[you may not] redistribute, encumber, sell, rent, lease,
>> sublicense, or otherwise transfer rights to Mascot Parser." So, could
>> we/should we get a written addition that would allow for the include
>> files or could we/should we seek redistribution of the whole package
>> and add an unpacking target to the Jamfile.jam? I'm leaning toward the
>> former despite the additional work at each upgrade of the msparser
>> library. I'd like to hear all your thoughts.
>>
>> Also, although I've read the additional licenses the will follow
>> msparser and don't see any conflict I would like to know if I've
>> missed anything.
>>
>> Attached is the license on Mascot's download page, and the "3rd party
>> licenses" page included in the msparser documentation directory.
>>
>> Thank you ahead of time for your time.
>>
>> -RB
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> proteowizard-developer mailing list
>> proteowizard-developer@...
>> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>>
>
>
> --
> David Creasy
> Matrix Science
> 64 Baker Street
> London W1U 7GB, UK
> Tel: +44 (0)20 7486 1050
> Fax: +44 (0)20 7224 1344
>
> dcreasy@...
> http://www.matrixscience.com
>
> Matrix Science Ltd. is registered in England and Wales
> Company number 3533898
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> proteowizard-developer mailing list
> proteowizard-developer@...
> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer
>
>

Re: [proteowizard-developer] Addition of Mascot -> MzIdentML libraries and licensing to proteowizard

[David Creasy <dcreasy@ma...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Robert,<br>
<br>
Yes, what Brendan says is correct. The aim of the license is to make it
easy for someone to download, install and run your application without
requiring them to install anything else. Hence item #2 specifically
refers to the "execution of your application". <br>
<br>
&gt; Since pwizuses swig to manage language, we only need the C
libraries and<br>
&gt; headers.<br>
This presumably refers to you making the source of your application
available? The license doesn't cover that, so you would need to point
people to the Mascot parser download page and tell them where to unpack
it so that they can build pwiz. Is there a problem with this?<br>
<br>
--David<br>
<br>
Brendan MacLean wrote:
<blockquote
 cite="mid:AANLkTikrEU+7BkHMFDT=UQLuntv4m1t3Sc-p5OiJSQ=M@..."
 type="cite">Hi Robert,<br>
The licensing scheme Parag, Matt and I came up with this week for
ProteoWizard should work fine for the Mascot Parser, because it roughly
parallels what I am already doing for Skyline, and that is fine for the
Mascot Parser.&nbsp; I think you abbreviated your quote from the license a
little too much:<br>
  <br>
"Except as expressly provided elsewhere in this agreement, you may not:"<br>
...<br>
"redistribute, encumber, sell, rent, lease, sublicense, or otherwise
transfer rights to Mascot Parser; "<br>
  <br>
And elsewhere says:<br>
  <p>If you write a software application that uses Mascot Parser, you
may distribute selected files from Mascot Parser as components of your
application, subject to the following conditions:
  </p>
  <ol>
    <li>You do not charge any form of licence fee for the application.
Nominal charges for media and shipping are acceptable, but if you want
to incorporate Mascot Parser
into a commercial application, you cannot use this licence. </li>
    <li>You include only those files from Mascot Parser that are
strictly necessary to enable execution of your application. You may not
redistribute other files from Mascot Parser, such as the documentation.
    </li>
    <li>Your application must add substantial new and independent
functionality to that of Mascot Parser.
You must not expose individual Mascot Parser functions and interfaces
as separately invokable entities </li>
    <li>Your application must acknowledge the use of Mascot Parser on
the splash screen or in the accompanying documentation.
    </li>
    <li>There must be no suggestion that Matrix Science approves,
endorses or promotes your application, and
you may not use any Matrix Science logo or trademark outside the
acknowledgement text and technical documentation.
    </li>
  </ol>
The Matrix Science guys have assured me that this was designed to work
for academic software like Skyline.&nbsp; Definitely contact them, but I
would expect them to agree that their license already works for
ProteoWizard to the same extent that the vendor licenses we are working
on will work for ProteoWizard.&nbsp; For profit ventures that use the
library will still have to seek a different license from Matrix
Science, just as they will from the vendors, if they want to
redistribute their libraries.&nbsp; Academic protoemics software with no
associated commercial gain should be able to redistribute under these
licenses.<br>
  <br>
--Brendan <br>
  <br>
  <div class="gmail_quote">On Fri, Oct 1, 2010 at 3:01 PM, Robert Burke
  <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:robert.burke@...">robert.burke@...</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello
everyone,<br>
    <br>
I'm finishing up the my Mascot to mzid converter and am getting down<br>
to the last two issues to be resolved (not including bugs).<br>
    <br>
The first is how to package the libraries and include files. The<br>
msparser API has a wide variety of languages it supports. Since pwiz<br>
uses swig to manage language, we only need the C libraries and<br>
headers. I'd prefer grouping the platforms by OS, 32/64-bit, and<br>
compiler and adding a switch in the Jamroot.jam file.<br>
    <br>
This leads to the second item. The only hitch here is section 3, item<br>
3: "[you may not] redistribute, encumber, sell, rent, lease,<br>
sublicense, or otherwise transfer rights to Mascot Parser." So, could<br>
we/should we get a written addition that would allow for the include<br>
files or could we/should we seek redistribution of the whole package<br>
and add an unpacking target to the Jamfile.jam? I'm leaning toward the<br>
former despite the additional work at each upgrade of the msparser<br>
library. I'd like to hear all your thoughts.<br>
    <br>
Also, although I've read the additional licenses the will follow<br>
msparser and don't see any conflict I would like to know if I've<br>
missed anything.<br>
    <br>
Attached is the license on Mascot's download page, and the "3rd party<br>
licenses" page included in the msparser documentation directory.<br>
    <br>
Thank you ahead of time for your time.<br>
    <font color="#888888"><br>
-RB<br>
    </font><br>
------------------------------------------------------------------------------<br>
Start uncovering the many advantages of virtual appliances<br>
and start using them to simplify application deployment and<br>
accelerate your shift to cloud computing.<br>
    <a moz-do-not-send="true"
 href="http://p.sf.net/sfu/novell-sfdev2dev"; target="_blank">http://p.sf.net/sfu/novell-sfdev2dev</a><br>;
_______________________________________________<br>
proteowizard-developer mailing list<br>
    <a moz-do-not-send="true"
 href="mailto:proteowizard-developer@...">proteowizard-developer@...</a><br>
    <a moz-do-not-send="true"
 href="https://lists.sourceforge.net/lists/listinfo/proteowizard-developer";
 target="_blank">https://lists.sourceforge.net/lists/listinfo/proteowizard-developer</a><br>;
    <br>
  </blockquote>
  </div>
  <br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
David Creasy
Matrix Science
64 Baker Street
London W1U 7GB, UK
Tel: +44 (0)20 7486 1050
Fax: +44 (0)20 7224 1344

<a class="moz-txt-link-abbreviated" href="mailto:dcreasy@...">dcreasy@...</a>
<a class="moz-txt-link-freetext" href="http://www.matrixscience.com">http://www.matrixscience.com</a>;

Matrix Science Ltd. is registered in England and Wales
Company number 3533898</pre>
</body>
</html>