From f.buske@uq.edu.au Tue Jun 08 05:36:02 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OLpbd-0005xP-7o>; Tue, 08 Jun 2010 05:36:01 +0200 Received: from mailhub4.uq.edu.au ([130.102.149.131]) by relay1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OLpbc-0008BT-Bo>; Tue, 08 Jun 2010 05:36:01 +0200 Received: from smtp4.uq.edu.au (smtp4.uq.edu.au [130.102.128.19]) by mailhub4.uq.edu.au (8.13.8/8.13.8) with ESMTP id o583Zu0G005727 for ; Tue, 8 Jun 2010 13:35:57 +1000 Received: from tlb-sumo.imb.uq.edu.au (tlb-sumo.imb.uq.edu.au [130.102.118.111]) (authenticated bits=0) by smtp4.uq.edu.au (8.13.8/8.13.8) with ESMTP id o583ZtdG014597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 8 Jun 2010 13:35:56 +1000 Message-ID: <4C0DBA9C.9040309@uq.edu.au> Date: Tue, 08 Jun 2010 13:35:56 +1000 From: Fabian Buske User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: SeqAn Development Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UQ-FilterTime: 1275968157 X-Scanned-By: MIMEDefang 2.58 on UQ Mailhub on 130.102.149.131 X-Originating-IP: 130.102.149.131 X-purgate: clean X-purgate-ID: 151147::1275968161-000051C5-9B0E61EE/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none Subject: [Seqan-dev] loading SeedSets cargos into maps X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 03:36:02 -0000 Hi, I tried to use a map (skiplist) loaded with an __int64 key and a seedSet cargo but get a compiler error. Is there a size limit as to what load of a cargo or what type of cargo can be used? Sample code: typedef SeedSet< int, SimpleSeed, DefaultNoScore , void > TSeedSet; typedef Pair< int, TSeedSet> TSkipValue; typedef Map< TSkipValue , Skiplist< > > TDiagMap; SeedSet< int, SimpleSeed, DefaultNoScore , void > seedset(100, 0); TDiagMap diagMap; insert(diagMap, 1, seedset); throws: seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const seqan::Seed >' to 'size_t' in assignment seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const seqan::Seed >' to 'size_t' in assignment seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const seqan::Seed >' to 'size_t' in assignment I did put in a ticket for this as well. On a minor note seed_base and the seedSet_base are missing the "= operator" implementation. Seed & operator = (Seed const &orig) Cheers, Fabian -- Fabian Buske Institute for Molecular Bioscience The University of Queensland Brisbane, Qld. 4072 Australia Phone: (61)-(7)-334-62608 From f.buske@uq.edu.au Mon Jun 21 09:30:59 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQbT8-0002L1-7X>; Mon, 21 Jun 2010 09:30:58 +0200 Received: from mailhub3.uq.edu.au ([130.102.148.131]) by relay1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQbT7-0007bq-1v>; Mon, 21 Jun 2010 09:30:58 +0200 Received: from smtp4.uq.edu.au (smtp4.uq.edu.au [130.102.128.19]) by mailhub3.uq.edu.au (8.13.8/8.13.8) with ESMTP id o5L7Uq25028927 for ; Mon, 21 Jun 2010 17:30:53 +1000 Received: from tlb-sumo.imb.uq.edu.au (tlb-sumo.imb.uq.edu.au [130.102.118.111]) (authenticated bits=0) by smtp4.uq.edu.au (8.13.8/8.13.8) with ESMTP id o5L7UqHC027774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Jun 2010 17:30:52 +1000 Message-ID: <4C1F152C.8030402@uq.edu.au> Date: Mon, 21 Jun 2010 17:30:52 +1000 From: Fabian Buske User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: SeqAn Development References: <4C0DBA9C.9040309@uq.edu.au> In-Reply-To: <4C0DBA9C.9040309@uq.edu.au> Content-Type: multipart/alternative; boundary="------------080901010504030804090204" X-UQ-FilterTime: 1277105453 X-Scanned-By: MIMEDefang 2.58 on UQ Mailhub on 130.102.148.131 X-Originating-IP: 130.102.148.131 X-ZEDAT-Hint: A X-purgate: clean X-purgate-ID: 151147::1277105458-000051C5-6677F390/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Benin.ZEDAT.FU-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=HTML_30_40,HTML_MESSAGE Subject: Re: [Seqan-dev] loading SeedSets cargos into maps X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 07:31:00 -0000 This is a multi-part message in MIME format. --------------080901010504030804090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, After not attracting any attention on this one I worked myself through the MemoryManager, which seems to cause all the problems. First, the part the compiler complains about doesn't make any sense to me at all. So I put the following lines in comments: memoryManager_int.h: //hmmmmmmmmmmm < this was not my comment; its not useful whatsoever size_t x = supremumValue(); while (tmpSource != x){ tmpSource = source[tmpSource]; target[tmpTarget] = tmpSource; tmpTarget = target[tmpTarget]; } I also had to change a couple of lines above to prevent a bad memory access. Changed: target.lastValue = &target[length(source)-1]; to if (length(source) > 0) target.lastValue = &target[length(source)-1]; I also have the other bugfixes that I did submit to the bug-tracker (bug + fix) but unfortunately nobody has actually made the changes in the library so far. *What I figured out:* The SeedSet is instantiated as a local variable and then added to the map. That means everything is copied, at least it should, otherwise its lost when the program leaves the scope of the SeedSet. However, the memoryManager seems to recycle certain memory regions that contain seeds. At least I loose the seed data when I leave the scope. TMap map; { TSeedSet seedset(100, 0); TSeed seed(1, 2, 4); if (!addSeed(seedset, seed, Single())) ::std::cerr << "adding seed went wrong" << ::std::endl; insert(map, 0, seedset); // insert the seedset at key=0 printMap(map,-2,2); // Seeds still in map } printMap(map,-2,2); // Seeds gone from map Here, the second printMap() throws a memory access exception. The data for the seed are lost: first printMap(map,-2,2): -2 missed -1 missed 0 found 1 1-4 2-5 1 missed second printMap(map,-2,2): -2 missed -1 missed 0 found Current language: auto; currently c++ Program received signal: "EXC_BAD_ACCESS". Any idea on how to fix this is very much appreciated since this bug proves himself a stopper. Thanks a lot! Cheers, Fabian Fabian Buske wrote: > Hi, > > I tried to use a map (skiplist) loaded with an __int64 key and a > seedSet cargo but get a compiler error. > Is there a size limit as to what load of a cargo or what type of cargo > can be used? > > Sample code: > > typedef SeedSet< int, SimpleSeed, DefaultNoScore , void > TSeedSet; > typedef Pair< int, TSeedSet> TSkipValue; > typedef Map< TSkipValue , Skiplist< > > TDiagMap; > SeedSet< int, SimpleSeed, DefaultNoScore , void > seedset(100, 0); > TDiagMap diagMap; > insert(diagMap, 1, seedset); > > throws: > > seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const > seqan::Seed >' to 'size_t' > in assignment > seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const > seqan::Seed >' to 'size_t' > in assignment > seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const > seqan::Seed >' to 'size_t' > in assignment > > I did put in a ticket for this as well. > > On a minor note seed_base and the seedSet_base are missing the "= > operator" implementation. > > Seed & operator = (Seed const &orig) > > > Cheers, > Fabian > -- Fabian Buske Institute for Molecular Bioscience The University of Queensland Brisbane, Qld. 4072 Australia Phone: (61)-(7)-334-62608 --------------080901010504030804090204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

After not attracting any attention on this one I worked myself through the MemoryManager, which seems to cause all the problems.

First, the part the compiler complains about doesn't make any sense to me at all. So I put the following lines in comments:

memoryManager_int.h:

    //hmmmmmmmmmmm < this was not my comment; its not useful whatsoever
    size_t x = supremumValue<size_t>();
    while (tmpSource != x){
        tmpSource = source[tmpSource];
        target[tmpTarget] = tmpSource;
        tmpTarget = target[tmpTarget];
    }

I also had to change a couple of lines above to prevent a bad memory access. Changed:

    target.lastValue = &target[length(source)-1];

to
    if (length(source) > 0) target.lastValue = &target[length(source)-1];

I also have the other bugfixes that I did submit to the bug-tracker (bug + fix) but unfortunately nobody has actually made the changes in the library so far.

What I figured out:
The SeedSet is instantiated as a local variable and then added to the map. That means everything is copied, at least it should, otherwise its lost when the program leaves the scope of the SeedSet. However, the memoryManager seems to recycle certain memory regions that contain seeds. At least I loose the seed data when I leave the scope.

    TMap map;
    {
        TSeedSet seedset(100, 0);
        TSeed seed(1, 2, 4);
        if (!addSeed(seedset, seed, Single()))
            ::std::cerr << "adding seed went wrong" << ::std::endl;
        insert(map, 0, seedset); // insert the seedset at key=0
        printMap(map,-2,2); // Seeds still in map
    }
    printMap(map,-2,2); // Seeds gone from map

Here, the second printMap() throws a memory access exception. The data for the seed are lost:

first printMap(map,-2,2):
-2 missed
-1 missed
0 found
1 1-4     2-5
1 missed

second printMap(map,-2,2):
-2 missed
-1 missed
0 found
Current language:  auto; currently c++
Program received signal:  “EXC_BAD_ACCESS”.

Any idea on how to fix this is very much appreciated since this bug proves himself a stopper.

Thanks a lot!

Cheers,
Fabian

Fabian Buske wrote:
Hi,

I tried to use a map (skiplist) loaded with an __int64 key and a seedSet cargo but get a compiler error.
Is there a size limit as to what load of a cargo or what type of cargo can be used?

Sample code:

typedef SeedSet< int, SimpleSeed,  DefaultNoScore , void > TSeedSet;
typedef Pair< int, TSeedSet> TSkipValue;
typedef Map< TSkipValue , Skiplist< > > TDiagMap;
SeedSet< int, SimpleSeed,  DefaultNoScore , void > seedset(100, 0);
TDiagMap diagMap;
insert(diagMap, 1, seedset);

throws:

seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const seqan::Seed<int, const seqan::Tag<seqan::_Seed_simple> >' to 'size_t' in assignment
seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const seqan::Seed<int, const seqan::Tag<seqan::_Seed_simple> >' to 'size_t' in assignment
seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const seqan::Seed<int, const seqan::Tag<seqan::_Seed_simple> >' to 'size_t' in assignment

I did put in a ticket for this as well.

On a minor note seed_base and the seedSet_base are missing the "= operator" implementation.

Seed & operator = (Seed const &orig)


Cheers,
Fabian 



-- 
Fabian Buske
Institute for Molecular Bioscience
The University of Queensland 
Brisbane, Qld. 4072 Australia
Phone: (61)-(7)-334-62608
--------------080901010504030804090204-- From f.buske@uq.edu.au Tue Jun 22 03:51:13 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQsdr-00051A-Ss>; Tue, 22 Jun 2010 03:51:11 +0200 Received: from mailhub3.uq.edu.au ([130.102.148.131]) by relay1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQsdr-0001Ji-3E>; Tue, 22 Jun 2010 03:51:11 +0200 Received: from smtp3.uq.edu.au (smtp3.uq.edu.au [130.102.128.18]) by mailhub3.uq.edu.au (8.13.8/8.13.8) with ESMTP id o5M1p79E008669 for ; Tue, 22 Jun 2010 11:51:07 +1000 Received: from tlb-sumo.imb.uq.edu.au (tlb-sumo.imb.uq.edu.au [130.102.118.111]) (authenticated bits=0) by smtp3.uq.edu.au (8.13.8/8.13.8) with ESMTP id o5M1p6vw012308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Jun 2010 11:51:06 +1000 Message-ID: <4C20170A.4000205@uq.edu.au> Date: Tue, 22 Jun 2010 11:51:06 +1000 From: Fabian Buske User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: SeqAn Development References: <4C0DBA9C.9040309@uq.edu.au> <4C1F152C.8030402@uq.edu.au> In-Reply-To: <4C1F152C.8030402@uq.edu.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-UQ-FilterTime: 1277171467 X-Scanned-By: MIMEDefang 2.58 on UQ Mailhub on 130.102.148.131 X-Originating-IP: 130.102.148.131 X-purgate: clean X-purgate-ID: 151147::1277171471-000051C5-9C45A595/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Gabun.ZEDAT.FU-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none Subject: Re: [Seqan-dev] loading SeedSets cargos into maps X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 01:51:13 -0000 Hi, I figured out a solution for the issue. Basically, the missing assignment operator (=) in several classes were causing the problem. I'm in the process of updating the related bug report in the bugtracker (which seems awfully slow by the way). I will attach all files modified by myself. I recommend a prompt merge with the current version of the library to avoid conflicts with subsequent file changes. Thanks & cheers, Fabian Fabian Buske wrote: > Hi, > > After not attracting any attention on this one I worked myself through > the MemoryManager, which seems to cause all the problems. > > First, the part the compiler complains about doesn't make any sense to > me at all. So I put the following lines in comments: > > memoryManager_int.h: > > //hmmmmmmmmmmm < this was not my comment; its not useful whatsoever > size_t x = supremumValue(); > while (tmpSource != x){ > tmpSource = source[tmpSource]; > target[tmpTarget] = tmpSource; > tmpTarget = target[tmpTarget]; > } > > I also had to change a couple of lines above to prevent a bad memory > access. Changed: > > target.lastValue = &target[length(source)-1]; > > to > if (length(source) > 0) target.lastValue = &target[length(source)-1]; > > I also have the other bugfixes that I did submit to the bug-tracker > (bug + fix) but unfortunately nobody has actually made the changes in > the library so far. > > *What I figured out:* > The SeedSet is instantiated as a local variable and then added to the > map. That means everything is copied, at least it should, otherwise > its lost when the program leaves the scope of the SeedSet. However, > the memoryManager seems to recycle certain memory regions that contain > seeds. At least I loose the seed data when I leave the scope. > > TMap map; > { > TSeedSet seedset(100, 0); > TSeed seed(1, 2, 4); > if (!addSeed(seedset, seed, Single())) > ::std::cerr << "adding seed went wrong" << ::std::endl; > insert(map, 0, seedset); // insert the seedset at key=0 > printMap(map,-2,2); // Seeds still in map > } > printMap(map,-2,2); // Seeds gone from map > > Here, the second printMap() throws a memory access exception. The data > for the seed are lost: > > first printMap(map,-2,2): > -2 missed > -1 missed > 0 found > 1 1-4 2-5 > 1 missed > > second printMap(map,-2,2): > -2 missed > -1 missed > 0 found > Current language: auto; currently c++ > Program received signal: “EXC_BAD_ACCESS”. > > Any idea on how to fix this is very much appreciated since this bug > proves himself a stopper. > > Thanks a lot! > > Cheers, > Fabian > > Fabian Buske wrote: >> Hi, >> >> I tried to use a map (skiplist) loaded with an __int64 key and a >> seedSet cargo but get a compiler error. >> Is there a size limit as to what load of a cargo or what type of >> cargo can be used? >> >> Sample code: >> >> typedef SeedSet< int, SimpleSeed, DefaultNoScore , void > TSeedSet; >> typedef Pair< int, TSeedSet> TSkipValue; >> typedef Map< TSkipValue , Skiplist< > > TDiagMap; >> SeedSet< int, SimpleSeed, DefaultNoScore , void > seedset(100, 0); >> TDiagMap diagMap; >> insert(diagMap, 1, seedset); >> >> throws: >> >> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const >> seqan::Seed >' to 'size_t' >> in assignment >> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const >> seqan::Seed >' to 'size_t' >> in assignment >> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const >> seqan::Seed >' to 'size_t' >> in assignment >> >> I did put in a ticket for this as well. >> >> On a minor note seed_base and the seedSet_base are missing the "= >> operator" implementation. >> >> Seed & operator = (Seed const &orig) >> >> >> Cheers, >> Fabian >> > > > -- > Fabian Buske > Institute for Molecular Bioscience > The University of Queensland > Brisbane, Qld. 4072 Australia > Phone: (61)-(7)-334-62608 > -- Fabian Buske Institute for Molecular Bioscience The University of Queensland Brisbane, Qld. 4072 Australia Phone: (61)-(7)-334-62608 From Knut.Reinert@fu-berlin.de Tue Jun 22 07:43:18 2010 Received: from outpost1.zedat.fu-berlin.de ([130.133.4.66]) by list1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQwGS-0003PY-Kl>; Tue, 22 Jun 2010 07:43:16 +0200 Received: from relay2.zedat.fu-berlin.de ([130.133.4.80]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQwGS-0006Uw-Io>; Tue, 22 Jun 2010 07:43:16 +0200 Received: from exchange6.fu-berlin.de ([160.45.9.133]) by relay2.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQwGS-0003NP-EH>; Tue, 22 Jun 2010 07:43:16 +0200 Received: from exchange6.fu-berlin.de ([160.45.9.133]) by exchange6.fu-berlin.de ([160.45.9.133]) with mapi; Tue, 22 Jun 2010 07:43:16 +0200 From: "Reinert, Knut" To: SeqAn Development Date: Tue, 22 Jun 2010 07:43:14 +0200 Thread-Topic: [Seqan-dev] loading SeedSets cargos into maps Thread-Index: AcsRzc86Thn4x8ADTDetkhpbVBTVoQ== Message-ID: <23A6A666-5D63-4E81-96A3-CBE4D8E515AF@fu-berlin.de> References: <4C0DBA9C.9040309@uq.edu.au> <4C1F152C.8030402@uq.edu.au> <4C20170A.4000205@uq.edu.au> In-Reply-To: <4C20170A.4000205@uq.edu.au> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/signed; boundary="Apple-Mail-10-377967974"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Originating-IP: 160.45.9.133 X-ZEDAT-Hint: A X-purgate: clean X-purgate-ID: 151147::1277185396-000051C5-3ED727C3/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Botsuana.ZEDAT.FU-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED Subject: Re: [Seqan-dev] loading SeedSets cargos into maps X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 05:43:18 -0000 --Apple-Mail-10-377967974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Fabian, thank you very much for your reports and the bug fixes. Here in Germany = we have the last 3 weeks of the Semester and hence we are a bit bogged down and slow with fixing bugs. All the best, Knut Reinert On Jun 22, 2010, at 3:51 AM, Fabian Buske wrote: > Hi, >=20 > I figured out a solution for the issue. Basically, the missing=20 > assignment operator (=3D) in several classes were causing the problem. = I'm=20 > in the process of updating the related bug report in the bugtracker=20 > (which seems awfully slow by the way). I will attach all files = modified=20 > by myself. I recommend a prompt merge with the current version of the=20= > library to avoid conflicts with subsequent file changes. >=20 > Thanks & cheers, > Fabian >=20 > Fabian Buske wrote: >> Hi, >>=20 >> After not attracting any attention on this one I worked myself = through=20 >> the MemoryManager, which seems to cause all the problems. >>=20 >> First, the part the compiler complains about doesn't make any sense = to=20 >> me at all. So I put the following lines in comments: >>=20 >> memoryManager_int.h: >>=20 >> //hmmmmmmmmmmm < this was not my comment; its not useful whatsoever >> size_t x =3D supremumValue(); >> while (tmpSource !=3D x){ >> tmpSource =3D source[tmpSource]; >> target[tmpTarget] =3D tmpSource; >> tmpTarget =3D target[tmpTarget]; >> } >>=20 >> I also had to change a couple of lines above to prevent a bad memory=20= >> access. Changed: >>=20 >> target.lastValue =3D &target[length(source)-1]; >>=20 >> to >> if (length(source) > 0) target.lastValue =3D = &target[length(source)-1]; >>=20 >> I also have the other bugfixes that I did submit to the bug-tracker=20= >> (bug + fix) but unfortunately nobody has actually made the changes in=20= >> the library so far. >>=20 >> *What I figured out:* >> The SeedSet is instantiated as a local variable and then added to the=20= >> map. That means everything is copied, at least it should, otherwise=20= >> its lost when the program leaves the scope of the SeedSet. However,=20= >> the memoryManager seems to recycle certain memory regions that = contain=20 >> seeds. At least I loose the seed data when I leave the scope. >>=20 >> TMap map; >> { >> TSeedSet seedset(100, 0); >> TSeed seed(1, 2, 4); >> if (!addSeed(seedset, seed, Single())) >> ::std::cerr << "adding seed went wrong" << ::std::endl; >> insert(map, 0, seedset); // insert the seedset at key=3D0 >> printMap(map,-2,2); // Seeds still in map >> } >> printMap(map,-2,2); // Seeds gone from map >>=20 >> Here, the second printMap() throws a memory access exception. The = data=20 >> for the seed are lost: >>=20 >> first printMap(map,-2,2): >> -2 missed >> -1 missed >> 0 found >> 1 1-4 2-5 >> 1 missed >>=20 >> second printMap(map,-2,2): >> -2 missed >> -1 missed >> 0 found >> Current language: auto; currently c++ >> Program received signal: =93EXC_BAD_ACCESS=94. >>=20 >> Any idea on how to fix this is very much appreciated since this bug=20= >> proves himself a stopper. >>=20 >> Thanks a lot! >>=20 >> Cheers, >> Fabian >>=20 >> Fabian Buske wrote: >>> Hi, >>>=20 >>> I tried to use a map (skiplist) loaded with an __int64 key and a=20 >>> seedSet cargo but get a compiler error. >>> Is there a size limit as to what load of a cargo or what type of=20 >>> cargo can be used? >>>=20 >>> Sample code: >>>=20 >>> typedef SeedSet< int, SimpleSeed, DefaultNoScore , void > TSeedSet; >>> typedef Pair< int, TSeedSet> TSkipValue; >>> typedef Map< TSkipValue , Skiplist< > > TDiagMap; >>> SeedSet< int, SimpleSeed, DefaultNoScore , void > seedset(100, 0); >>> TDiagMap diagMap; >>> insert(diagMap, 1, seedset); >>>=20 >>> throws: >>>=20 >>> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const=20 >>> seqan::Seed >' to = 'size_t'=20 >>> in assignment >>> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const=20 >>> seqan::Seed >' to = 'size_t'=20 >>> in assignment >>> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const=20 >>> seqan::Seed >' to = 'size_t'=20 >>> in assignment >>>=20 >>> I did put in a ticket for this as well. >>>=20 >>> On a minor note seed_base and the seedSet_base are missing the "=3D=20= >>> operator" implementation. >>>=20 >>> Seed & operator =3D (Seed const &orig) >>>=20 >>>=20 >>> Cheers, >>> Fabian >>>=20 >>=20 >>=20 >> --=20 >> Fabian Buske >> Institute for Molecular Bioscience >> The University of Queensland=20 >> Brisbane, Qld. 4072 Australia >> Phone: (61)-(7)-334-62608 >>=20 >=20 >=20 > --=20 > Fabian Buske > Institute for Molecular Bioscience > The University of Queensland=20 > Brisbane, Qld. 4072 Australia > Phone: (61)-(7)-334-62608 >=20 >=20 > _______________________________________________ > seqan-dev mailing list > seqan-dev@lists.fu-berlin.de > https://lists.fu-berlin.de/listinfo/seqan-dev --Apple-Mail-10-377967974 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF+jCCBfYw ggTeoAMCAQICBA4+Vb4wDQYJKoZIhvcNAQEFBQAwgbUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZC ZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEiMCAGA1UEChMZRnJlaWUgVW5pdmVyc2l0YWV0IEJlcmxp bjEOMAwGA1UECxMFWkVEQVQxMDAuBgNVBAMTJ0ZyZWllIFVuaXZlcnNpdGFldCBCZXJsaW4gLSBG VS1DQSAtIEcwMTEeMBwGCSqGSIb3DQEJARYPY2FARlUtQmVybGluLkRFMB4XDTA5MDUyODE4MzAw NloXDTEyMDUyNzE4MzAwNlowgZoxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCZXJsaW4xDzANBgNV BAcTBkJlcmxpbjEiMCAGA1UEChMZRnJlaWUgVW5pdmVyc2l0YWV0IEJlcmxpbjEuMCwGA1UECxMl RmFjaGJlcmVpY2ggTWF0aGVtYXRpayB1bmQgSW5mb3JtYXRpazEVMBMGA1UEAxMMS251dCBSZWlu ZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1KhJct0+8zA+Rpez11JSOVahqmh2 YJ8TWWVIvxERJPkUUgz+M4u4mEk3fr4oayj2KC5MoT8sHRbcIw4pEnN1NP3a9tWJZhXbInsR0eWM 5s6LXaLEHbczNg+V4xaFzAm6JR1sJ5h6LDWqmh2lmUoJE9l1ypydet5rf6Qnvbkys4Xwg4Dp4f89 uAZznbpo36FgDqS848FzIRW6wvzatFtVxYiQ/zpRggWLYNRIWx9jZi5A9LrFq79Cx6h7bWU13hpW u8QT2yE1cfRnTw2lvNXdKQDmNVHtVub7CHdG3voeJiiFvApgPkSbGDi1nXMtVePb/1xd5CFMMoqw IwH44W2KVwIDAQABo4ICJTCCAiEwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYDVR0lBCIwIAYI KwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBQf3YyAtgT64FlT3cbKq7WM Zsg64DAfBgNVHSMEGDAWgBQG4T30b/Qwt3o7V7AxBYl7DVhabDCBkQYDVR0RBIGJMIGGgRlrbnV0 LnJlaW5lcnRAZnUtYmVybGluLmRlgRdyZWluZXJ0QG1pLmZ1LWJlcmxpbi5kZYEYcmVpbmVydEBp bmYuZnUtYmVybGluLmRlgRtyZWluZXJ0QGNhbXB1cy5mdS1iZXJsaW4uZGWBGUtudXQuUmVpbmVy dEBmdS1iZXJsaW4uZGUwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2NkcDEucGNhLmRmbi5kZS9m dS1jYS9wdWIvY3JsL2NhY3JsLmNybDA0oDKgMIYuaHR0cDovL2NkcDIucGNhLmRmbi5kZS9mdS1j YS9wdWIvY3JsL2NhY3JsLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwPgYIKwYBBQUHMAKGMmh0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZnUtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MD4GCCsGAQUFBzAC hjJodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Z1LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQUFAAOCAQEAekvz2kbo9rxQsMh1ETLQMyFUoo4Dcm4FEXXvAl0k9jXCmq+6kcctkRFY 8Adm3GJ0QHvvTzd9X/fNUKw76Yr31QkczMfLz+9aJjNvro7EfKXsPGQI/ODiUuxR8Q8cOYYsmZqB R2PFZCHfWwN4IyNoPHeBySlguxjNSVXQ5+xMEzuEc/7iNW2MjaX5VjRah9zuP6iJpqgnSkJ6ttYl a+8vhNQ1e/Cx8k+FFF7w+7nF+dZLWhGuylJEjPpBdGjh16BtHWA6AsInAek8xzJyIloXa20jebAo Nx4RdQ6LjaqovFMQWanCXWzOUWpH1BvZ9NPXNDnCgkOqJCClqM3pZHLzxDGCA+0wggPpAgEBMIG+ MIG1MQswCQYDVQQGEwJERTEPMA0GA1UECBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xIjAgBgNV BAoTGUZyZWllIFVuaXZlcnNpdGFldCBCZXJsaW4xDjAMBgNVBAsTBVpFREFUMTAwLgYDVQQDEydG cmVpZSBVbml2ZXJzaXRhZXQgQmVybGluIC0gRlUtQ0EgLSBHMDExHjAcBgkqhkiG9w0BCQEWD2Nh QEZVLUJlcmxpbi5ERQIEDj5VvjAJBgUrDgMCGgUAoIICAzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA2MjIwNTQzMTVaMCMGCSqGSIb3DQEJBDEWBBRWdsIAR8hS 6LGZ2uHtMLLESZMGMDCBzwYJKwYBBAGCNxAEMYHBMIG+MIG1MQswCQYDVQQGEwJERTEPMA0GA1UE CBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xIjAgBgNVBAoTGUZyZWllIFVuaXZlcnNpdGFldCBC ZXJsaW4xDjAMBgNVBAsTBVpFREFUMTAwLgYDVQQDEydGcmVpZSBVbml2ZXJzaXRhZXQgQmVybGlu IC0gRlUtQ0EgLSBHMDExHjAcBgkqhkiG9w0BCQEWD2NhQEZVLUJlcmxpbi5ERQIEDj5VvjCB0QYL KoZIhvcNAQkQAgsxgcGggb4wgbUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCZXJsaW4xDzANBgNV BAcTBkJlcmxpbjEiMCAGA1UEChMZRnJlaWUgVW5pdmVyc2l0YWV0IEJlcmxpbjEOMAwGA1UECxMF WkVEQVQxMDAuBgNVBAMTJ0ZyZWllIFVuaXZlcnNpdGFldCBCZXJsaW4gLSBGVS1DQSAtIEcwMTEe MBwGCSqGSIb3DQEJARYPY2FARlUtQmVybGluLkRFAgQOPlW+MA0GCSqGSIb3DQEBAQUABIIBAHqz PI7nw2tnATpqKECOicKnZ7XmvcHx/ahEDofjhfDUWbyc3Jj3f8CiUedBGeK9K0dfm9Y7dsXxSKwB lCipGCXdJE3T590Ex83oVXU/3cREN2J02z02FfKpk4n+sfVsThjAcvdROnorhcHcJ9enQpy8KcRu NyrLIo73pm16YwCGWxeYlyMWPqr5yIc28AT/FOPy+qrRjg7zQEck2kk4slB40RABPJTfS6kxTCxw Y1BpA4EaZreMBSuCdxeG6U+t6PENzmzOMHK8xqd8Txkktb/SKYx4a8A8fNYE8PcXxI55QexCuBEY u2l7gZjGhx7SbskWz1qVr+HJkdx6DHF9k/gAAAAAAAA= --Apple-Mail-10-377967974-- From f.buske@uq.edu.au Tue Jun 22 08:02:09 2010 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by list1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQwYh-00047c-S7>; Tue, 22 Jun 2010 08:02:07 +0200 Received: from mailhub4.uq.edu.au ([130.102.149.131]) by relay1.zedat.fu-berlin.de (Exim 4.69) for seqan-dev@lists.fu-berlin.de with esmtp (envelope-from ) id <1OQwYh-0006JT-2X>; Tue, 22 Jun 2010 08:02:07 +0200 Received: from smtp4.uq.edu.au (smtp4.uq.edu.au [130.102.128.19]) by mailhub4.uq.edu.au (8.13.8/8.13.8) with ESMTP id o5M623T0008717 for ; Tue, 22 Jun 2010 16:02:04 +1000 Received: from tlb-sumo.imb.uq.edu.au (tlb-sumo.imb.uq.edu.au [130.102.118.111]) (authenticated bits=0) by smtp4.uq.edu.au (8.13.8/8.13.8) with ESMTP id o5M623xo017623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Jun 2010 16:02:03 +1000 Message-ID: <4C2051DB.1010703@uq.edu.au> Date: Tue, 22 Jun 2010 16:02:03 +1000 From: Fabian Buske User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: SeqAn Development References: <4C0DBA9C.9040309@uq.edu.au> <4C1F152C.8030402@uq.edu.au> <4C20170A.4000205@uq.edu.au> <23A6A666-5D63-4E81-96A3-CBE4D8E515AF@fu-berlin.de> In-Reply-To: <23A6A666-5D63-4E81-96A3-CBE4D8E515AF@fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-UQ-FilterTime: 1277186524 X-Scanned-By: MIMEDefang 2.58 on UQ Mailhub on 130.102.149.131 X-Originating-IP: 130.102.149.131 X-purgate: clean X-purgate-ID: 151147::1277186527-000051C5-E37E8EC3/0-0/0-0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6 X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.0.4 on Benin.ZEDAT.FU-Berlin.DE X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none Subject: Re: [Seqan-dev] loading SeedSets cargos into maps X-BeenThere: seqan-dev@lists.fu-berlin.de X-Mailman-Version: 2.1.11 Precedence: list Reply-To: SeqAn Development List-Id: SeqAn Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 06:02:09 -0000 Dear Knut, my apologies in case my comment came across the wrong way. I was not complaining about the bug fixing being slow but the actual process of submitting bugs/files to the bug tracker http://trac.mi.fu-berlin.de/seqan/, which takes a couple of minutes just for submitting a tiny comment. At least from the other side of the world where I am sitting. However, I observe no time lag whatsoever when checking out from SVN. Best regards, Fabian Reinert, Knut wrote: > Dear Fabian, > > thank you very much for your reports and the bug fixes. Here in Germany we have the last 3 weeks of the Semester > and hence we are a bit bogged down and slow with fixing bugs. > > All the best, > > Knut Reinert > > On Jun 22, 2010, at 3:51 AM, Fabian Buske wrote: > > >> Hi, >> >> I figured out a solution for the issue. Basically, the missing >> assignment operator (=) in several classes were causing the problem. I'm >> in the process of updating the related bug report in the bugtracker >> (which seems awfully slow by the way). I will attach all files modified >> by myself. I recommend a prompt merge with the current version of the >> library to avoid conflicts with subsequent file changes. >> >> Thanks & cheers, >> Fabian >> >> Fabian Buske wrote: >> >>> Hi, >>> >>> After not attracting any attention on this one I worked myself through >>> the MemoryManager, which seems to cause all the problems. >>> >>> First, the part the compiler complains about doesn't make any sense to >>> me at all. So I put the following lines in comments: >>> >>> memoryManager_int.h: >>> >>> //hmmmmmmmmmmm < this was not my comment; its not useful whatsoever >>> size_t x = supremumValue(); >>> while (tmpSource != x){ >>> tmpSource = source[tmpSource]; >>> target[tmpTarget] = tmpSource; >>> tmpTarget = target[tmpTarget]; >>> } >>> >>> I also had to change a couple of lines above to prevent a bad memory >>> access. Changed: >>> >>> target.lastValue = &target[length(source)-1]; >>> >>> to >>> if (length(source) > 0) target.lastValue = &target[length(source)-1]; >>> >>> I also have the other bugfixes that I did submit to the bug-tracker >>> (bug + fix) but unfortunately nobody has actually made the changes in >>> the library so far. >>> >>> *What I figured out:* >>> The SeedSet is instantiated as a local variable and then added to the >>> map. That means everything is copied, at least it should, otherwise >>> its lost when the program leaves the scope of the SeedSet. However, >>> the memoryManager seems to recycle certain memory regions that contain >>> seeds. At least I loose the seed data when I leave the scope. >>> >>> TMap map; >>> { >>> TSeedSet seedset(100, 0); >>> TSeed seed(1, 2, 4); >>> if (!addSeed(seedset, seed, Single())) >>> ::std::cerr << "adding seed went wrong" << ::std::endl; >>> insert(map, 0, seedset); // insert the seedset at key=0 >>> printMap(map,-2,2); // Seeds still in map >>> } >>> printMap(map,-2,2); // Seeds gone from map >>> >>> Here, the second printMap() throws a memory access exception. The data >>> for the seed are lost: >>> >>> first printMap(map,-2,2): >>> -2 missed >>> -1 missed >>> 0 found >>> 1 1-4 2-5 >>> 1 missed >>> >>> second printMap(map,-2,2): >>> -2 missed >>> -1 missed >>> 0 found >>> Current language: auto; currently c++ >>> Program received signal: “EXC_BAD_ACCESS”. >>> >>> Any idea on how to fix this is very much appreciated since this bug >>> proves himself a stopper. >>> >>> Thanks a lot! >>> >>> Cheers, >>> Fabian >>> >>> Fabian Buske wrote: >>> >>>> Hi, >>>> >>>> I tried to use a map (skiplist) loaded with an __int64 key and a >>>> seedSet cargo but get a compiler error. >>>> Is there a size limit as to what load of a cargo or what type of >>>> cargo can be used? >>>> >>>> Sample code: >>>> >>>> typedef SeedSet< int, SimpleSeed, DefaultNoScore , void > TSeedSet; >>>> typedef Pair< int, TSeedSet> TSkipValue; >>>> typedef Map< TSkipValue , Skiplist< > > TDiagMap; >>>> SeedSet< int, SimpleSeed, DefaultNoScore , void > seedset(100, 0); >>>> TDiagMap diagMap; >>>> insert(diagMap, 1, seedset); >>>> >>>> throws: >>>> >>>> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const >>>> seqan::Seed >' to 'size_t' >>>> in assignment >>>> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const >>>> seqan::Seed >' to 'size_t' >>>> in assignment >>>> seqan/seeds/memoryManager_int.h:185: error: cannot convert 'const >>>> seqan::Seed >' to 'size_t' >>>> in assignment >>>> >>>> I did put in a ticket for this as well. >>>> >>>> On a minor note seed_base and the seedSet_base are missing the "= >>>> operator" implementation. >>>> >>>> Seed & operator = (Seed const &orig) >>>> >>>> >>>> Cheers, >>>> Fabian >>>> >>>> >>> -- >>> Fabian Buske >>> Institute for Molecular Bioscience >>> The University of Queensland >>> Brisbane, Qld. 4072 Australia >>> Phone: (61)-(7)-334-62608 >>> >>> >> -- >> Fabian Buske >> Institute for Molecular Bioscience >> The University of Queensland >> Brisbane, Qld. 4072 Australia >> Phone: (61)-(7)-334-62608 >> >> >> _______________________________________________ >> seqan-dev mailing list >> seqan-dev@lists.fu-berlin.de >> https://lists.fu-berlin.de/listinfo/seqan-dev >> > > -- Fabian Buske Institute for Molecular Bioscience The University of Queensland Brisbane, Qld. 4072 Australia Phone: (61)-(7)-334-62608