xmlpipedb-developer — Mailing list for XMLPipeDB software development questions and discussions.

Re: [XMLPipeDB-developer] Fwd: GO termdb import results

[John D. N. D. <do...@lm...>]

Yes, thanks, I was planning on doing that.  I'd actually forgotten  
about the dev list, and was thinking last night that we should come up  
with a solution for recording these dev-related messages.  I only  
remembered this when you sent in the new release bug  :-/

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Oct 26, 2009, at 9:48 AM, Kam Dahlquist <kda...@lm...> wrote:

> I'm forwarding this to the list so it is archived.
> Kam
>
>> From: "John David N. Dionisio" <do...@lm...>
>> Subject: GO termdb import results
>> Date: Mon, 26 Oct 2009 00:05:45 -0700
>> To: Kam Dahlquist <kda...@lm...>
>> X-Mailer: Apple Mail (2.1076)
>> X-OriginalArrivalTime: 26 Oct 2009 07:05:46.0078 (UTC)
>> FILETIME=[BD66E7E0:01CA560A]
>>
>> Hi Kam,
>>
>> I downloaded and tried to import a GO termdb xml file that was
>> downloaded on Sunday, 10/25/2009.  It had one new tag of which our
>> code was previously unaware, called "data-version" --- for what it's
>> worth, the value therein was 1.1.856.  (i.e., it was <data-
>> version>1.1.856</data-version>)
>>
>> Fortunately, this attribute appeared only once in the entire file, so
>> I was able to delete it initially so I could test the import without
>> recoding (yet).  The file then imported successfully.
>>
>> I double-checked their latest schemas: XSD, DTD, and RelaxNG.  None  
>> of
>> these schemas had this tag defined.  In fact, it looks like none of
>> these schemas have been updated since we last sent them an e-mail
>> reporting this issue (I went all the way to their committed
>> SourceForge repository to make sure I got the latest official  
>> version).
>>
>> So, immediate fix is to do what I've previously done, which is to
>> manually add this tag to our own GO database DTD, and re-run xsd2db.
>> That can easily be done before next week.  However, it does show that
>> this issue still exists.
>>
>> John David N. Dionisio, PhD
>> Assistant Professor, Computer Science
>> Loyola Marymount University
>>
>
>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> xmlpipedb-developer mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer

Re: [XMLPipeDB-developer] New GenMAPP Builder version--bug

[Kam D. <kda...@lm...>]

Hi,

I downloaded the new version and tried to launch it using the .bat file and 
it throws an exception and quits so fast that I can't read the error 
message on the console.

Kam

At 01:06 AM 10/26/2009, John David N. Dionisio wrote:
>Greetings,
>
>I've released a new GenMAPP Builder version, 2.0b35, to
>SourceForge.net.  Andrés, if you get this in time, please download and
>update the GenMAPP Builder version on the VM image (which is probably
>gmbuilder-2.0b34) to this new version.  Thanks!
>
>Direct download link:
>
> 
>https://sourceforge.net/projects/xmlpipedb/files/GenMAPP%20Builder/GenMAPP%20Builder%202.0b35/gmbuilder-2.0b35.zip/download
>
>Thanks again!
>
>John David N. Dionisio, PhD
>Assistant Professor, Computer Science
>Loyola Marymount University

[XMLPipeDB-developer] Fwd: GO termdb import results

[Kam D. <kda...@lm...>]

I'm forwarding this to the list so it is archived.
Kam

>From: "John David N. Dionisio" <do...@lm...>
>Subject: GO termdb import results
>Date: Mon, 26 Oct 2009 00:05:45 -0700
>To: Kam Dahlquist <kda...@lm...>
>X-Mailer: Apple Mail (2.1076)
>X-OriginalArrivalTime: 26 Oct 2009 07:05:46.0078 (UTC) 
>FILETIME=[BD66E7E0:01CA560A]
>
>Hi Kam,
>
>I downloaded and tried to import a GO termdb xml file that was
>downloaded on Sunday, 10/25/2009.  It had one new tag of which our
>code was previously unaware, called "data-version" --- for what it's
>worth, the value therein was 1.1.856.  (i.e., it was <data- 
>version>1.1.856</data-version>)
>
>Fortunately, this attribute appeared only once in the entire file, so
>I was able to delete it initially so I could test the import without
>recoding (yet).  The file then imported successfully.
>
>I double-checked their latest schemas: XSD, DTD, and RelaxNG.  None of
>these schemas had this tag defined.  In fact, it looks like none of
>these schemas have been updated since we last sent them an e-mail
>reporting this issue (I went all the way to their committed
>SourceForge repository to make sure I got the latest official version).
>
>So, immediate fix is to do what I've previously done, which is to
>manually add this tag to our own GO database DTD, and re-run xsd2db.
>That can easily be done before next week.  However, it does show that
>this issue still exists.
>
>John David N. Dionisio, PhD
>Assistant Professor, Computer Science
>Loyola Marymount University
>

Re: [XMLPipeDB-developer] New GenMAPP Builder version--bug

[John D. N. D. <do...@lm...>]

OK, I'll look into that...it's a touch surprising since that file  
hasn't been touched, but of course things like that have happened  
before.

As an initial workaround, you can try the .bat file from a previous  
release to see if that works, just to get going while I look into this.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Oct 26, 2009, at 9:47 AM, "Kam Dahlquist" <kda...@lm...> wrote:

> Hi,
>
> I downloaded the new version and tried to launch it using the .bat  
> file and it throws an exception and quits so fast that I can't read  
> the error message on the console.
>
> Kam

[XMLPipeDB-developer] Out-of-date OBO XML schema files

[John D. N. D. <do...@lm...>]

Here's the message that I sent to the GO folks regarding the DTD/XML  
schema issues that we've been having for the past year...

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


Begin forwarded message:

> I'd like to report an issue regarding the assorted schema files  
> (DTD, Relax NG, XSD) that are currently available for your OBO XML  
> format.  For reference, I'm using the files available here, as  
> linked from your main web site:
>
> 	http://geneontology.cvs.sourceforge.net/viewvc/geneontology/go-dev/xml/dtd/
>
> I'm one of the principals of the XMLPipeDB project (http://xmlpipedb.cs.lmu.edu 
> ), one of whose components is an automated OBO XML-to-relational  
> database loader that is based on an XML schema (either DTD or XSD).   
> This loader uses the schema file to automatically generate end-to- 
> end code for reading OBO XML into a relational database.
>
> Lately, we have observed that your daily term OBO XML downloads no  
> longer correspond to any of the schema files that I could find  
> online.  That is, the OBO XML files contain tags and properties that  
> are not present in any publicly available schema (whether DTD, Relax  
> NG, or XSD --- I'm aware that the DTD is marked as "deprecated," but  
> this becomes a non-issue when every schema file I could find appears  
> to be out of date).
>
> Because our software is automated, it relies on the completeness of  
> these schema files in order to work properly.  As a workaround, I  
> have been maintaining a manual, reverse-engineered version of your  
> DTD, adding any new tags or attributes that we have encountered so  
> far:
>
> 	http://xmlpipedb.svn.sourceforge.net/viewvc/xmlpipedb/trunk/godb/xsd/go_daily-obo-xml-manual.dtd?view=log
>
> This workaround has been sufficient as long as changes to the DTD  
> remain infrequent.  Lately, however, we have noticed further  
> additions (specifically, an apparently new created_by tag; our  
> manual file has not been updated yet to accommodate this change)  
> that have prompted us to seek your help --- after all, manual edits  
> of someone else's DTD or XSD file defeat the purpose of our  
> software.  Thus, I was wondering if it would be possible for you to  
> update either your OBO XML DTD or XSD file for completeness, such  
> that they match your posted daily term DB OBO XML files.  Or, if you  
> have been maintaining updated versions of these files outside of  
> your SourceForge repository and geneontology.org web site, please  
> let me know where to find them.

[XMLPipeDB-developer] TallyEngine bugs

[Kam D. <kda...@lm...>]

Hi,

I'm starting this as a new thread (hopefully) so we can keep the threads 
separate by task.

There are issues with the TallyEngine for each species, maybe they are 
related, but I don't know; I'm linking to their testing report pages where 
you can look at the results screen shot and the OriginalRowCounts data 
directly.

Kam

New species:
Mycobacterium tuberculosis 
https://sourceforge.net/apps/mediawiki/xmlpipedb/index.php?title=Gene_Database_Testing_Report_M._tuberculosis_20090817 
and P. aerugenosa 
https://sourceforge.net/apps/mediawiki/xmlpipedb/index.php?title=Gene_Database_Testing_Report_P._aerugenosa_20090817
* OrderedLocusNames is not being tallied
* UniGene is not being tallied (UniGene doesn't exist for these two, but in 
other TallyEngine results for other species, it is actually listed with 
counts of zero.  We should be consistent about counting it.)

Old species:
E. coli K12 
https://sourceforge.net/apps/mediawiki/xmlpipedb/index.php?title=Gene_Database_Testing_Report_E._coli_K12_20090819
* There are discrepancies between the TallyEngine results and the gdb
** EchoBASE has 4022 records in gdb, not 4028
** EcoGene has 4190 records in gdb, not 4199
** Blattner has 4328 records in gdb, not 8352
* W3110 is not being counted (or is being conflated with Blattner)
* EchoBASE, EcoGene, and Blattner are appearing twice in results with 
second instance giving -1 result for XML Count.
* UniGene is not being tallied (UniGene doesn't exist for these two, but in 
other TallyEngine results for other species, it is actually listed with 
counts of zero.  We should be consistent about counting it.)

Arabidopsis 
https://sourceforge.net/apps/mediawiki/xmlpipedb/index.php?title=Gene_Database_Testing_Report_Arabidopsis_20090819
* Discrepancy between TallyEngine and OriginalRowCounts for the following 
systems:
** GeneId
** RefSeq
** TAIR
** UniGene
** In these cases, gdb has fewer records.
* TAIR and UniGene are repeated in TallyEngine results, showing a -1 for 
the XML Count for the second result.

Plasmodium 
https://sourceforge.net/apps/mediawiki/xmlpipedb/index.php?title=Gene_Database_Testing_Report_P._falciparum_20090819
* Discrepancies in TallyEngine Results versus OriginalRowCounts
** GeneId TallyEngine has 5264, but OriginalRowCounts is 5260
** OrderedLocusNames in gdb is 5336 and much less in TallyEngine, also XML 
Count and Database Count are off by 1.
* OrderedLocus and UniGene repeated twice in results with a -1 given for 
the XML Count the second time.

Vibrio 
https://sourceforge.net/apps/mediawiki/xmlpipedb/index.php?title=Gene_Database_Testing_Report_V._cholerae_20090820
* OrderedLocusNames counts are off by one between the XML and database 
(slash issue?); also, because of the underscore issue, remember that all of 
these IDs got duplicated in the gdb +/- the underscore.
* OrderedLocusNames and UniGene appear twice in results, second time with 
-1 in XML Count.

[XMLPipeDB-developer] gmb2b34

[Kam D. <kda...@lm...>]

Hi,

M. tuberculosis finished with extant tables.  It will likely need tweaking 
to its Species Profile for OrderedLocusNames, but I will leave that to the 
students.  I am now going back and re-testing our current species (E. coli 
K12, Arabidopsis, Vibrio, Plasmodium) to make sure that they are still 
functioning.  I will also proceed with finding a few more candidate species 
for the projects so those are ready to go for the class.

There were a few issues leftover from the our released species that I'd 
like to clean up.  I am also paying particular attention to the TallyEngine 
to make sure that is working for all species.  We can talk about that stuff 
when we meet tomorrow.

Best,
Kam

At 10:22 PM 8/17/2009, you wrote:
>Hi Kam,
>
>Awesome, that is very encouraging.  Hope M. tuberculosis goes well too.
>
>John David N. Dionisio, PhD
>Assistant Professor, Computer Science
>Loyola Marymount University
>
>
>On Aug 17, 2009, at 3:30 PM, Kam Dahlquist wrote:
>
> > Hi,
> >
> > The P. aerugenosa export finished with full GO tables and all
> > relationship
> > tables built.  I did a quick visual inspection of the tables in the
> > gdb and
> > they looked OK.
> >
> > I will submit a brief report on the SourceForge wiki, but I don't
> > want to
> > do too much testing because I want the students in the class to do it.
> >
> > I'm going to test an export with Mycobacterium tuberculosis now to
> > see how
> > it performs with a different species.
> >
> > Cheers,
> > Kam

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[John D. N. D. <do...@lm...>]

Hi Kam,

Awesome, that is very encouraging.  Hope M. tuberculosis goes well too.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 17, 2009, at 3:30 PM, Kam Dahlquist wrote:

> Hi,
>
> The P. aerugenosa export finished with full GO tables and all  
> relationship
> tables built.  I did a quick visual inspection of the tables in the  
> gdb and
> they looked OK.
>
> I will submit a brief report on the SourceForge wiki, but I don't  
> want to
> do too much testing because I want the students in the class to do it.
>
> I'm going to test an export with Mycobacterium tuberculosis now to  
> see how
> it performs with a different species.
>
> Cheers,
> Kam

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[Kam D. <kda...@lm...>]

Hi,

The P. aerugenosa export finished with full GO tables and all relationship 
tables built.  I did a quick visual inspection of the tables in the gdb and 
they looked OK.

I will submit a brief report on the SourceForge wiki, but I don't want to 
do too much testing because I want the students in the class to do it.

I'm going to test an export with Mycobacterium tuberculosis now to see how 
it performs with a different species.

Cheers,
Kam

At 12:13 AM 8/13/2009, John David N. Dionisio wrote:
>OK, so the "GOA format hypothesis" still holds some water...after some
>closer examination I found other parts in the code that hadn't been
>updated to accommodate the new format, so I adjusted accordingly.  I
>refactored a bit also, so that this GOA parsing can be tested
>separately, using a test file that includes GOA lines in multiple
>formats.  That test now returns GOA data from the truncated file that
>you sent, so here's hoping.
>
>I haven't touched the relationship code at all, so that issue is still
>pending, depending on the results of this next export.  Since you got
>relationship tables before, this last issue might be due to the
>incomplete adjustment of the GOA code to the new format.  If GO rows
>show up but not relationship rows, then this suggests a separate
>issue.  We'll see what shows up.
>
>The new release is 2.0b34, and should be available by the time you
>read this.  Rinse and repeat...  :)
>
>John David N. Dionisio, PhD
>Assistant Professor, Computer Science
>Loyola Marymount University

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[John D. N. D. <do...@lm...>]

OK, so the "GOA format hypothesis" still holds some water...after some  
closer examination I found other parts in the code that hadn't been  
updated to accommodate the new format, so I adjusted accordingly.  I  
refactored a bit also, so that this GOA parsing can be tested  
separately, using a test file that includes GOA lines in multiple  
formats.  That test now returns GOA data from the truncated file that  
you sent, so here's hoping.

I haven't touched the relationship code at all, so that issue is still  
pending, depending on the results of this next export.  Since you got  
relationship tables before, this last issue might be due to the  
incomplete adjustment of the GOA code to the new format.  If GO rows  
show up but not relationship rows, then this suggests a separate  
issue.  We'll see what shows up.

The new release is 2.0b34, and should be available by the time you  
read this.  Rinse and repeat...  :)

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 12, 2009, at 2:57 PM, Dahlquist, Kam D. wrote:

> Hi,
>
> Sorry, here is the log.
>
> For this build, it's not just the GOA, there were no relationship  
> tables built between, for example, UniProt-RefSeq, either.
>
> I'm attaching the first thirty rows of the GOA file.
>
> Kam
>

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[Dahlquist, K. D. <kda...@lm...>]

Hi,
 
Sorry, here is the log. 
 
For this build, it's not just the GOA, there were no relationship tables built between, for example, UniProt-RefSeq, either.
 
I'm attaching the first thirty rows of the GOA file.
 
Kam

________________________________

From: John David N. Dionisio [mailto:do...@lm...]
Sent: Wed 8/12/2009 13:06
To: <xml...@li...>
Subject: Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop


Hi Kam,

Thanks for the update...would you send the gmbuilder.log over?  I really thought that it was the GOA format.  For good measure, maybe copy/paste a few lines from the actual GOA file you're using as well, in case the issue still lies there.  At least we know that the slow performance last time really was due to the logging.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 12, 2009, at 12:51 PM, "Dahlquist, Kam D." <kda...@lm...> wrote:



	Hi,
	 
	I ran the new build and it finished, but with no relationship tables at all and the GO tables were still unpopulated.  Specifically,
	 
	GeneOntology: empty
	GeneOntologyCount: 3 records
	GeneOntologyTree: 3 records (the roots, Biological Process, etc.)
	UniProt-GeneOntology: empty
	UniProt-GOCount: 4 records
	 
	Kam

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[John D. N. D. <do...@lm...>]

Hi Kam,

Thanks for the update...would you send the gmbuilder.log over?  I  
really thought that it was the GOA format.  For good measure, maybe  
copy/paste a few lines from the actual GOA file you're using as well,  
in case the issue still lies there.  At least we know that the slow  
performance last time really was due to the logging.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 12, 2009, at 12:51 PM, "Dahlquist, Kam D." <kda...@lm...>  
wrote:

> Hi,
>
> I ran the new build and it finished, but with no relationship tables  
> at all and the GO tables were still unpopulated.  Specifically,
>
> GeneOntology: empty
> GeneOntologyCount: 3 records
> GeneOntologyTree: 3 records (the roots, Biological Process, etc.)
> UniProt-GeneOntology: empty
> UniProt-GOCount: 4 records
>
> Kam
>

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[Dahlquist, K. D. <kda...@lm...>]

Hi,
 
I ran the new build and it finished, but with no relationship tables at all and the GO tables were still unpopulated.  Specifically,
 
GeneOntology: empty
GeneOntologyCount: 3 records
GeneOntologyTree: 3 records (the roots, Biological Process, etc.)
UniProt-GeneOntology: empty
UniProt-GOCount: 4 records
 
Kam

________________________________

From: John David N. Dionisio [mailto:do...@lm...]
Sent: Thu 8/6/2009 23:48
To: xml...@li...
Subject: Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop



I looked through all three log files, plus the code that generated the 
log statements, and it looks like this is actually a case where the 
act of logging (since it was much more verbose than before) ended up 
being a bottleneck on the export's progress. Things actually seemed to 
be going OK, albeit extremely slowly because every relationship that 
was generated wrote 4 lines to the log file (disk-related activities 
take 100-1000 times longer to finish, so it's not too farfetched to 
surmise that the generation of 4 lines per relationship would slow 
things down that much).

Thus, I've released a non-debug (i.e., less verbose) version of 
GenMAPP Builder to SourceForge.  Since the logging level is the only 
change, I've kept the version at 2.0b33, but without the "-debug" 
suffix now.

Give this one a shot, and keep me posted...the amount of information 
in gmbuilder.log should now be more in line with 2.0b32 and prior.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 6, 2009, at 11:45 AM, Dahlquist, Kam D. wrote:

> Hi,
>
> I let the gmb2b33-debugging export of P. auregenosa go overnight.  
> It was still stuck at the same place this morning, so I killed it.
>
> I'm attaching the last log file and a screenshot of the console 
> taken right before I killed it (assuming that the list can handle 
> attachments).  Each log is ~5 MB, so I'll have to attach the other 
> ones in separate e-mails.  I'll see how this one is handled first.
>
> Unfortunately, the Gene Ontology tables were still empty as before, 
> although that is not where it seems to have gotten stuck.  It seems 
> to have gotten stuck building the relationship tables.
>
> Kam


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
xmlpipedb-developer mailing list
xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[Kam D. <kda...@lm...>]

Hi,

I was out the last few days; I've just started an export of P aerugenosa 
now and I'll let you know what happens (probably tomorrow).

Kam

At 11:48 PM 8/6/2009, John David N. Dionisio wrote:
>I looked through all three log files, plus the code that generated the
>log statements, and it looks like this is actually a case where the
>act of logging (since it was much more verbose than before) ended up
>being a bottleneck on the export's progress. Things actually seemed to
>be going OK, albeit extremely slowly because every relationship that
>was generated wrote 4 lines to the log file (disk-related activities
>take 100-1000 times longer to finish, so it's not too farfetched to
>surmise that the generation of 4 lines per relationship would slow
>things down that much).
>
>Thus, I've released a non-debug (i.e., less verbose) version of
>GenMAPP Builder to SourceForge.  Since the logging level is the only
>change, I've kept the version at 2.0b33, but without the "-debug"
>suffix now.
>
>Give this one a shot, and keep me posted...the amount of information
>in gmbuilder.log should now be more in line with 2.0b32 and prior.
>
>John David N. Dionisio, PhD
>Assistant Professor, Computer Science
>Loyola Marymount University
>
>
>On Aug 6, 2009, at 11:45 AM, Dahlquist, Kam D. wrote:
>
> > Hi,
> >
> > I let the gmb2b33-debugging export of P. auregenosa go overnight.
> > It was still stuck at the same place this morning, so I killed it.
> >
> > I'm attaching the last log file and a screenshot of the console
> > taken right before I killed it (assuming that the list can handle
> > attachments).  Each log is ~5 MB, so I'll have to attach the other
> > ones in separate e-mails.  I'll see how this one is handled first.
> >
> > Unfortunately, the Gene Ontology tables were still empty as before,
> > although that is not where it seems to have gotten stuck.  It seems
> > to have gotten stuck building the relationship tables.
> >
> > Kam
>
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>trial. Simplify your report design, integration and deployment - and focus on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>_______________________________________________
>xmlpipedb-developer mailing list
>xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xmlpipedb-developer

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[John D. N. D. <do...@lm...>]

I looked through all three log files, plus the code that generated the  
log statements, and it looks like this is actually a case where the  
act of logging (since it was much more verbose than before) ended up  
being a bottleneck on the export's progress. Things actually seemed to  
be going OK, albeit extremely slowly because every relationship that  
was generated wrote 4 lines to the log file (disk-related activities  
take 100-1000 times longer to finish, so it's not too farfetched to  
surmise that the generation of 4 lines per relationship would slow  
things down that much).

Thus, I've released a non-debug (i.e., less verbose) version of  
GenMAPP Builder to SourceForge.  Since the logging level is the only  
change, I've kept the version at 2.0b33, but without the "-debug"  
suffix now.

Give this one a shot, and keep me posted...the amount of information  
in gmbuilder.log should now be more in line with 2.0b32 and prior.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 6, 2009, at 11:45 AM, Dahlquist, Kam D. wrote:

> Hi,
>
> I let the gmb2b33-debugging export of P. auregenosa go overnight.   
> It was still stuck at the same place this morning, so I killed it.
>
> I'm attaching the last log file and a screenshot of the console  
> taken right before I killed it (assuming that the list can handle  
> attachments).  Each log is ~5 MB, so I'll have to attach the other  
> ones in separate e-mails.  I'll see how this one is handled first.
>
> Unfortunately, the Gene Ontology tables were still empty as before,  
> although that is not where it seems to have gotten stuck.  It seems  
> to have gotten stuck building the relationship tables.
>
> Kam

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[John D. N. D. <do...@lm...>]

OK, I'll look into it; the timestamp is rather telling, since it  
doesn't change, meaning that all of those log statements came out  
within a millisecond of each other.

John David N. Dionisio, PhD
Assistant Professor, Computer Science
Loyola Marymount University


On Aug 6, 2009, at 11:45 AM, Dahlquist, Kam D. wrote:

> Hi,
>
> I let the gmb2b33-debugging export of P. auregenosa go overnight.   
> It was still stuck at the same place this morning, so I killed it.
>
> I'm attaching the last log file and a screenshot of the console  
> taken right before I killed it (assuming that the list can handle  
> attachments).  Each log is ~5 MB, so I'll have to attach the other  
> ones in separate e-mails.  I'll see how this one is handled first.
>
> Unfortunately, the Gene Ontology tables were still empty as before,  
> although that is not where it seems to have gotten stuck.  It seems  
> to have gotten stuck building the relationship tables.
>
> Kam
> <Logcapture2.jpg><gmbuilder.log><mime-attachment.txt><mime- 
> attachment.txt>

[XMLPipeDB-developer] FW: gmb2b33-debugging stuck in loop

[Dahlquist, K. D. <kda...@lm...>]

Last log file.
Kam

________________________________

From: Dahlquist, Kam D. [mailto:kda...@lm...]
Sent: Thu 8/6/2009 13:45
To: xml...@li...
Subject: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop



Hi,

I let the gmb2b33-debugging export of P. auregenosa go overnight.  It was still stuck at the same place this morning, so I killed it.

I'm attaching the last log file and a screenshot of the console taken right before I killed it (assuming that the list can handle attachments).  Each log is ~5 MB, so I'll have to attach the other ones in separate e-mails.  I'll see how this one is handled first.

Unfortunately, the Gene Ontology tables were still empty as before, although that is not where it seems to have gotten stuck.  It seems to have gotten stuck building the relationship tables.

Kam

Re: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[Dahlquist, K. D. <kda...@lm...>]

Here is another log, since I saw the other came through.
Kam

________________________________

From: Dahlquist, Kam D. [mailto:kda...@lm...]
Sent: Thu 8/6/2009 13:45
To: xml...@li...
Subject: [XMLPipeDB-developer] gmb2b33-debugging stuck in loop



Hi,

I let the gmb2b33-debugging export of P. auregenosa go overnight.  It was still stuck at the same place this morning, so I killed it.

I'm attaching the last log file and a screenshot of the console taken right before I killed it (assuming that the list can handle attachments).  Each log is ~5 MB, so I'll have to attach the other ones in separate e-mails.  I'll see how this one is handled first.

Unfortunately, the Gene Ontology tables were still empty as before, although that is not where it seems to have gotten stuck.  It seems to have gotten stuck building the relationship tables.

Kam

[XMLPipeDB-developer] gmb2b33-debugging stuck in loop

[Dahlquist, K. D. <kda...@lm...>]

Hi,
 
I let the gmb2b33-debugging export of P. auregenosa go overnight.  It was still stuck at the same place this morning, so I killed it.
 
I'm attaching the last log file and a screenshot of the console taken right before I killed it (assuming that the list can handle attachments).  Each log is ~5 MB, so I'll have to attach the other ones in separate e-mails.  I'll see how this one is handled first.
 
Unfortunately, the Gene Ontology tables were still empty as before, although that is not where it seems to have gotten stuck.  It seems to have gotten stuck building the relationship tables.
 
Kam

[XMLPipeDB-developer] second test message

[Kam D. <kda...@lm...>]

Seeing if this makes it through.