Menu
▾
▴
treebase-devel — TreeBASE developer mailing list
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(41) |
May
(41) |
Jun
(50) |
Jul
(14) |
Aug
(21) |
Sep
(37) |
Oct
(8) |
Nov
(4) |
Dec
(135) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(145) |
Feb
(110) |
Mar
(216) |
Apr
(101) |
May
(42) |
Jun
(42) |
Jul
(23) |
Aug
(17) |
Sep
(33) |
Oct
(15) |
Nov
(18) |
Dec
(6) |
| 2011 |
Jan
(8) |
Feb
(10) |
Mar
(8) |
Apr
(41) |
May
(48) |
Jun
(62) |
Jul
(7) |
Aug
(9) |
Sep
(7) |
Oct
(11) |
Nov
(49) |
Dec
(1) |
| 2012 |
Jan
(17) |
Feb
(63) |
Mar
(4) |
Apr
(13) |
May
(17) |
Jun
(21) |
Jul
(10) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
(16) |
| 2013 |
Jan
(10) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Jon A. <jon...@ne...> - 2010-03-01 20:01:56
|
The following queues have been created: he...@tr... => tre...@ne... => Treebase-help queue at NESCen't RT instance (Vladimir watcher) bu...@tr... => tre...@ne... => Treebase-bugs queue at NESCent's RT instance (Vladimir watcher) Please include these links (treebase email address) in you webpages. thanks, Jon ------------------------------------------------------- Jon Auman Systems Administrator National Evolutionary Synthesis Center Duke University http:www.nescent.org jon...@ne... ------------------------------------------------------ |
|
From: Hilmar L. <hl...@ne...> - 2010-03-01 18:25:50
|
On Mar 1, 2010, at 1:10 PM, Vladimir Gapeyev wrote: > - Are we ok with running the migration against the instance on > treebase-prod? Yes. > > - Is it necessary to do any data cleaning prior to migration, e.g. > run the fixtaxonlabels.pl Bill mentioned this morning? That script might be worth running - if it doesn't take overly long it surely won't hurt and it's questionable whether it can also be applied w/o additional review after the migration. Other cleanup steps should not be needed as far as I know. Or to be more precise, they are needed, but can be equally well run after migration. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vla...@du...> - 2010-03-01 18:18:46
|
FI: We are going to stop and restore treebasedev DB instance in a few minutes. I'll let you know when it is done. [Sloppily, I ran the initialization script against it, which must have messed up many sequences.] --VG |
|
From: Vladimir G. <vga...@ne...> - 2010-03-01 18:11:13
|
I have now managed to time-run the migration script on the production server, using a data sample that is about 1/60 of the full data set to be migrated. This took 12min. Extrapolating, the migration run time will be about 12 hours. For reference, running the same sample on treebase-dev takes 21.5 min, almost twice as long, so the production migration would indeed be faster on the production server. There is a chance this could be sped up if Postgresql driver allows larger batch sizes for updates (currently, it is set to 30,000 because of a DB2 limitation). I'll look into that briefly. Other than that, are we ready to do the production run of the migration? Issues to consider: - Does http://treebase.peabody.yale.edu/treebase/migration/Dec-09/ indeed contain the dataset we want to migrate? - Are we ok with running the migration against the instance on treebase-prod? - Is it necessary to do any data cleaning prior to migration, e.g. run the fixtaxonlabels.pl Bill mentioned this morning? --Vladimir |
|
From: youjun g. <you...@ya...> - 2010-03-01 16:36:18
|
Bug 2953212 was done and war file was send to Jon. I wonder if Jon can run a build-deploy script so the re-build can directly fetch the source code from sourceforge, in that way we don't need to send war file. Youjun On Mon, Mar 1, 2010 at 11:18 AM, Rutger Vos <rut...@gm...> wrote: > I've submitted code that fixes issues 2954481 and 2960909. I guess > this is my request to see those changes deployed. > > On Mon, Mar 1, 2010 at 3:19 PM, Vladimir Gapeyev > <vla...@du...> wrote: > > > > On Mar 1, 2010, at 9:24 AM, youjun guo wrote: > > > > I am working on a bug and expect to finish today, I will build a jar > file > > include all new updates and send to Jon. > > > > Youjun > > > > > > On Mon, Mar 1, 2010 at 12:13 AM, William Piel <wil...@ya... > > wrote: > >> > >> Hi all, > >> This was closed last Wednesday, but I don't see any difference in > behavior > >> on treebasedb-dev or stage. Could someone trigger a build? > > > > We have just (as of 10:10am) re-built and re-deployed the application. > > The current re-deployment procedure is this: > > - When a non-developer (Bill, Hilmar, or Todd, ...) needs to see most > recent > > features deployed, he should drop a message to Vladimir. > > - Vladimir will rebuild the WAR and pass it to Jon. > > - Jon will deploy on treebase-dev. > > --VG > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Treebase-devel mailing list > > Tre...@li... > > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > > > > > > > -- > Dr. Rutger A. Vos > School of Biological Sciences > Philip Lyle Building, Level 4 > University of Reading > Reading > RG6 6BX > United Kingdom > Tel: +44 (0) 118 378 7535 > http://www.nexml.org > http://rutgervos.blogspot.com > |
|
From: Rutger V. <rut...@gm...> - 2010-03-01 16:18:34
|
I've submitted code that fixes issues 2954481 and 2960909. I guess this is my request to see those changes deployed. On Mon, Mar 1, 2010 at 3:19 PM, Vladimir Gapeyev <vla...@du...> wrote: > > On Mar 1, 2010, at 9:24 AM, youjun guo wrote: > > I am working on a bug and expect to finish today, I will build a jar file > include all new updates and send to Jon. > > Youjun > > > On Mon, Mar 1, 2010 at 12:13 AM, William Piel <wil...@ya...> wrote: >> >> Hi all, >> This was closed last Wednesday, but I don't see any difference in behavior >> on treebasedb-dev or stage. Could someone trigger a build? > > We have just (as of 10:10am) re-built and re-deployed the application. > The current re-deployment procedure is this: > - When a non-developer (Bill, Hilmar, or Todd, ...) needs to see most recent > features deployed, he should drop a message to Vladimir. > - Vladimir will rebuild the WAR and pass it to Jon. > - Jon will deploy on treebase-dev. > --VG > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Vladimir G. <vla...@du...> - 2010-03-01 15:20:09
|
On Mar 1, 2010, at 9:24 AM, youjun guo wrote: > I am working on a bug and expect to finish today, I will build a > jar file include all new updates and send to Jon. > > Youjun > > > On Mon, Mar 1, 2010 at 12:13 AM, William Piel > <wil...@ya...> wrote: > Hi all, > > This was closed last Wednesday, but I don't see any difference in > behavior on treebasedb-dev or stage. Could someone trigger a build? > We have just (as of 10:10am) re-built and re-deployed the application. The current re-deployment procedure is this: - When a non-developer (Bill, Hilmar, or Todd, ...) needs to see most recent features deployed, he should drop a message to Vladimir. - Vladimir will rebuild the WAR and pass it to Jon. - Jon will deploy on treebase-dev. --VG |
|
From: youjun g. <you...@ya...> - 2010-03-01 14:32:13
|
I am working on a bug and expect to finish today, I will build a jar file include all new updates and send to Jon. Youjun On Mon, Mar 1, 2010 at 12:13 AM, William Piel <wil...@ya...> wrote: > Hi all, > > This was closed last Wednesday, but I don't see any difference in behavior > on treebasedb-dev or stage. Could someone trigger a build? > > bp > > On Feb 24, 2010, at 9:58 AM, SourceForge.net wrote: > > Bugs item #2947955, was opened at 2010-02-08 12:16 > Message generated for change (Settings changed) made by youjun > You can respond by visiting: > > https://sourceforge.net/tracker/?func=detail&atid=1126676&aid=2947955&group_id=248804 > > Please note that this message will contain a full copy of the comment > thread, > including the initial issue submission, for this request, > not just the latest update. > Category: ui > Group: None > > Status: Closed > > Priority: 9 > Private: No > Submitted By: William Piel (sfrgpiel) > Assigned to: youjun guo (youjun) > Summary: Submission Summary Info > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > |
|
From: William P. <wil...@ya...> - 2010-03-01 05:13:09
|
Hi all, This was closed last Wednesday, but I don't see any difference in behavior on treebasedb-dev or stage. Could someone trigger a build? bp On Feb 24, 2010, at 9:58 AM, SourceForge.net wrote: > Bugs item #2947955, was opened at 2010-02-08 12:16 > Message generated for change (Settings changed) made by youjun > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=1126676&aid=2947955&group_id=248804 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: ui > Group: None >> Status: Closed > Priority: 9 > Private: No > Submitted By: William Piel (sfrgpiel) > Assigned to: youjun guo (youjun) > Summary: Submission Summary Info |
|
From: Vladimir G. <vga...@ne...> - 2010-02-24 20:36:19
|
We are getting close to having the two migration runs on actual data,
for the Dec 2009 and Feb 2010 deltas.
Sooner or later we will have to address data quality/cleanliness
issues, and my question at the moment is whether we'd like to do that
before or after the migration?
For reference, appended below are my notes on data cleaning matters
that surfaced at the mailing list on my watch.
The instances we currently have at treebase-stage and treebase-prod
have both been restored from an early-Dec-2009 backup of treebase-dev,
which makes them free from unit test gunk accumulated in treebase-dev
in Dec-Jan, but far from satisfactorily clean.
I doubt anyone used either treebase-stage or treebase-prod since they
were restored, so the cleaning&migration work can proceed on either of
them. I'd suggest treebase-prod, since it is on a faster machine.
Alternatively to this cleaning hassle, could we like consider the
hassle of migrating TB1 from scratch? Within a couple days, I should
be able to give an estimate of how much server running time that would
take. The remaining wildcard would then be the unknown issues in the
full TB1 data that could break the migration tools.
--Vladimir
* Remove junk, particularly that created by tests
* Known junk: Submission 22 and its related records
Youjun's email of 2010-01-28:
"In table phylotree, many trees do not have a study_id value,
but their phylotreenode related to study 22 via table taxonlabel.
Their phylotree_id are:
1129,1130,1131,1132, 2333,2334,2335,2336,2337,2338,
2339,2340,2341,2343,2556,2557,2686,2726,2727,2787,2788,2789,2790,
3446,3671,3766,3767,3901,3902,3903,3904,3905,3906,3907,3908,3909,3910,3911,3912
, 4062,4063, 5705,5706,5707,5708,5720,5721,5921,5941,5981,160000022341
I will delete those trees because their foreign key constrain
prevent me from cleaning up about 10,000 dummy taxonlabel records
related to submission 22
(study 22 and submission 22 happen to be the same)."
VG: these IDs are from end-of-Jan treebasedev; the current
treebasestage may have fewer.
* Replace "owner" nulls (in submission.user_id?) by the special
"migration" owner (see Bill's message of around 2010-02-02)
"Also because we have reverted to an older instance of the data,
the migrated records contain have NULL in the user_id of the
submission table. This causes null pointer errors for the unit tests.
To fix the problem, I did the following:
1. I created a user with username "migration" and email address "mig...@tr...
". This is the dummy "user" who will now "own" all migrated
submissions that lack an owner.
2. I got the user_id for the "migration" user, and it happened
to be 9955
3. I ran this statement: "UPDATE submission SET user_id = 9955
WHERE user_id IS NULL"
Now all migrated data belong to the user "migration". "
Also, see "null->'tb1'; http://www.treebase.org/~piel/taxlabels_fix.zip
; Study 22 (Jan 8)"
|
|
From: Hilmar L. <hl...@ne...> - 2010-02-24 20:28:15
|
The tomcat corresponding to http://treebase-prod.nescent.org/ appears to be down. Is that to be expected? (I would hope not.) -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2010-02-24 19:52:42
|
On Feb 24, 2010, at 2:45 PM, Vladimir Gapeyev wrote: > That still leaves open the question whether WAR internals are a good > location for the temporary downloads to lie around. Good question indeed, but if the downloads are truly temporary indeed then a transient location such as the WAR internals seem like a fine place to me. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vla...@du...> - 2010-02-24 19:45:39
|
I have since noted that file contents are stored in the DB, in a varchar field, so they are not lost. That still leaves open the question whether WAR internals are a good location for the temporary downloads to lie around. --VG On Feb 24, 2010, at 2:35 PM, Hilmar Lapp wrote: > Has this received any follow-up yet? > > -hilmar > > On Feb 7, 2010, at 4:41 PM, Vladimir Gapeyev wrote: > >> Currently, uploaded Nexus files are saved in $CATALINA_HOME/webapps/ >> treebase-web/NexusFileUpload/username/filemame.nex. That is, >> inside the exploded WAR. This means they are lost at each >> application re=-deployment. >> >> Is this the intended behavior? I suspect not, since the file names >> are stored in DB and there are links to these files from a Study >> page. >> (There is however, treebase-web/accessviolation.html message >> displayed when clicking these links, both in my instance and at >> 6666, even for files that are still on the server, so I have doubts.) >> >> --Vladimir >> >> ------------------------------------------------------------------------------ >> The Planet: dedicated and managed hosting, cloud storage, colocation >> Stay online with enterprise data centers and the best network in >> the business >> Choose flexible plans and management services without long-term >> contracts >> Personal 24x7 support from experience hosting pros just a phone >> call away. >> http://p.sf.net/sfu/theplanet-com_______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > |
|
From: Hilmar L. <hl...@ne...> - 2010-02-24 19:35:40
|
Has this received any follow-up yet? -hilmar On Feb 7, 2010, at 4:41 PM, Vladimir Gapeyev wrote: > Currently, uploaded Nexus files are saved in $CATALINA_HOME/webapps/ > treebase-web/NexusFileUpload/username/filemame.nex. That is, inside > the exploded WAR. This means they are lost at each application re=- > deployment. > > Is this the intended behavior? I suspect not, since the file names > are stored in DB and there are links to these files from a Study page. > (There is however, treebase-web/accessviolation.html message > displayed when clicking these links, both in my instance and at > 6666, even for files that are still on the server, so I have doubts.) > > --Vladimir > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: youjun g. <you...@ya...> - 2010-02-24 17:46:37
|
I will be happy with any solution as long as it can work easy, fast and will not break authentication rules at NESCent. Youjun On Wed, Feb 24, 2010 at 12:19 PM, Vladimir Gapeyev <vga...@ne...>wrote: > > On Feb 24, 2010, at 11:14 AM, Hilmar Lapp wrote: > > > How far are we from shutting that down? > > I think 6666 should stay running, as a reference: I am not confident > that treebase-dev:8080 has all installation glitches ironed out, so > when something odd comes up, it is useful to first check whether 6666 > exhibits that as well. Though, there is no need to keep 6666 up-to- > date all the time. > > > > I.e., can everyone deploy to treebase-dev and does it have the same > > working features as the port 6666 instance? > > Only Jon can redeploy to treebase-dev. > > Ideally, we'd want an automated re-build and re-deploy triggered by > commits to SVN, but since setting up a build environment on the server > was expected to take some up-front time, we decided that the following > was satisfactory: > > (1) Vladimir checks out new version and builds a WAR on his laptop > (2) Passes the WAR to Jon > (3) Jon deploys the WAR on the server > > I'd prefer to go through this dance when someone (a non-developer) > actually needs to see new changes on the server, rather than after > each SVN commit. > > For passing WARs in (2), Jon has set up an SVN, into which I commit > the WARs. Other developers should be able to commit there, too > (perhaps, after asking Jon for credentials). The repository is at svn > +ssh://you...@sv.../repos/treebase > > For a half-ideal solution, we could consider some upfront effort to > set up automatic re-deployments triggered by commits into this WAR > repository. > > --Vladimir > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > |
|
From: youjun g. <you...@gm...> - 2010-02-24 17:40:40
|
Hi, Hilmar, I always ask Rutger to do the deployment because we had ever talked about sharing Rutger's deploy script and accessing to the dev server as following: Vladimir : Do you know which Tomcat server is assigned for all the TreeBASE > developers?--Youjun > > http://treebase-dev.nescent.org:6666/treebase-web is the only common > TreeBase instance I am aware of. I presumed everyone had their own local > tomcats for development purposes -- that's what I have been trying to set up > for myself for the past two days... --Vladimir > > Now I kind of understand, once other developers finish a task and pass the > testing on their own environment, just submit the code to sourceforg, Rutger > will be the person who redeploy the new code.--Youjun > Except that that person can't remain Rutger. -hilmar > On Wed, Feb 24, 2010 at 10:19 AM, Hilmar Lapp <hl...@ne...> wrote: > Hi Youjun - I've wanted to ask that before - can you tell us why you can't > rebuild and deploy yourself? You should absolutely be able to, so let's fix > whatever is in the way of that. > > -hilmar > > On Feb 24, 2010, at 10:07 AM, youjun guo wrote: > > Hi, Rutger, > > Can you do a re-build and deploy on treebase? Just finished some work on > it. > > Thanks > > Youjun > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > |
|
From: Vladimir G. <vga...@ne...> - 2010-02-24 17:19:38
|
On Feb 24, 2010, at 11:14 AM, Hilmar Lapp wrote: > How far are we from shutting that down? I think 6666 should stay running, as a reference: I am not confident that treebase-dev:8080 has all installation glitches ironed out, so when something odd comes up, it is useful to first check whether 6666 exhibits that as well. Though, there is no need to keep 6666 up-to- date all the time. > I.e., can everyone deploy to treebase-dev and does it have the same > working features as the port 6666 instance? Only Jon can redeploy to treebase-dev. Ideally, we'd want an automated re-build and re-deploy triggered by commits to SVN, but since setting up a build environment on the server was expected to take some up-front time, we decided that the following was satisfactory: (1) Vladimir checks out new version and builds a WAR on his laptop (2) Passes the WAR to Jon (3) Jon deploys the WAR on the server I'd prefer to go through this dance when someone (a non-developer) actually needs to see new changes on the server, rather than after each SVN commit. For passing WARs in (2), Jon has set up an SVN, into which I commit the WARs. Other developers should be able to commit there, too (perhaps, after asking Jon for credentials). The repository is at svn +ssh://you...@sv.../repos/treebase For a half-ideal solution, we could consider some upfront effort to set up automatic re-deployments triggered by commits into this WAR repository. --Vladimir |
|
From: William P. <wil...@ya...> - 2010-02-24 17:04:11
|
On Feb 24, 2010, at 9:00 AM, Vladimir Gapeyev wrote: >> >> TB2's taxonlabel table does not have a tb1legacyid field, so we >> don't have a place to store the "T98303" legacy_taxon_label values. >> But that's okay -- the only person who might want to know what the >> new ids for TB1 legacy_taxon_labels is Rod Page, and I can email to >> him so conversion tables. So don't worry about trying to store the >> T98303 values. > > If you do want to preserve tb1legacyids in the TaxonLabels table, this > is the perfect time to do that -- just let me know. It won't cost > much now, but will be more troublesome later. In that case, let's go ahead with that -- add a varchar legacy field for all the T numbers. bp |
|
From: Rutger V. <rut...@gm...> - 2010-02-24 16:26:08
|
I've rebuilt and re-deployed, and while I'm happy to do this I agree with Hilmar that this is not ideal. Rutger On Wed, Feb 24, 2010 at 3:07 PM, youjun guo <you...@gm...> wrote: > Hi, Rutger, > > Can you do a re-build and deploy on treebase? Just finished some work on it. > > Thanks > > Youjun > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- Dr. Rutger A. Vos School of Biological Sciences Philip Lyle Building, Level 4 University of Reading Reading RG6 6BX United Kingdom Tel: +44 (0) 118 378 7535 http://www.nexml.org http://rutgervos.blogspot.com |
|
From: Hilmar L. <hl...@ne...> - 2010-02-24 16:14:21
|
How far are we from shutting that down? I.e., can everyone deploy to treebase-dev and does it have the same working features as the port 6666 instance? -hilmar On Feb 24, 2010, at 10:47 AM, Vladimir Gapeyev wrote: > Youjun talks about re-deployments to 6666. > -VG > > > On Feb 24, 2010, at 10:19 AM, Hilmar Lapp wrote: > >> Hi Youjun - I've wanted to ask that before - can you tell us why >> you can't rebuild and deploy yourself? You should absolutely be >> able to, so let's fix whatever is in the way of that. >> >> -hilmar >> >> On Feb 24, 2010, at 10:07 AM, youjun guo wrote: >> >>> Hi, Rutger, >>> >>> Can you do a re-build and deploy on treebase? Just finished some >>> work on it. >>> >>> Thanks >>> >>> Youjun >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev_______________________________________________ >>> Treebase-devel mailing list >>> Tre...@li... >>> https://lists.sourceforge.net/lists/listinfo/treebase-devel >> >> -- >> =========================================================== >> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >> =========================================================== >> >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev_______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vla...@du...> - 2010-02-24 15:47:22
|
Youjun talks about re-deployments to 6666. -VG On Feb 24, 2010, at 10:19 AM, Hilmar Lapp wrote: > Hi Youjun - I've wanted to ask that before - can you tell us why you > can't rebuild and deploy yourself? You should absolutely be able to, > so let's fix whatever is in the way of that. > > -hilmar > > On Feb 24, 2010, at 10:07 AM, youjun guo wrote: > >> Hi, Rutger, >> >> Can you do a re-build and deploy on treebase? Just finished some >> work on it. >> >> Thanks >> >> Youjun >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev_______________________________________________ >> Treebase-devel mailing list >> Tre...@li... >> https://lists.sourceforge.net/lists/listinfo/treebase-devel > > -- > =========================================================== > : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : > =========================================================== > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel |
|
From: Hilmar L. <hl...@ne...> - 2010-02-24 15:39:11
|
Hi Youjun - I've wanted to ask that before - can you tell us why you can't rebuild and deploy yourself? You should absolutely be able to, so let's fix whatever is in the way of that. -hilmar On Feb 24, 2010, at 10:07 AM, youjun guo wrote: > Hi, Rutger, > > Can you do a re-build and deploy on treebase? Just finished some > work on it. > > Thanks > > Youjun > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: youjun g. <you...@gm...> - 2010-02-24 15:08:05
|
Hi, Rutger, Can you do a re-build and deploy on treebase? Just finished some work on it. Thanks Youjun |
|
From: Vladimir G. <vla...@du...> - 2010-02-24 14:00:49
|
On Feb 23, 2010, at 10:43 PM, William Piel wrote: > On Feb 22, 2010, at 11:48 AM, Vladimir Gapeyev wrote: > >> I am setting up an SQL script to update TI info, following your >> suggestions in an earlier email (below). Besides what you >> mentioned there, would you want to update table fields >> taxonvaiant.tb1legacyid and taxon.tb1legacyid? > I guess I would prefer it if you would override the auto-increment > for the taxonvariant_id field and the taxon_id field so that they > would use my integers instead -- then ignore or drop the > "tb1legacyid" fields in the taxonvariant and taxon tables. But if > you'd rather not do that, then allow your fields to auto-increment > and instead use my integer ids in the tb1legacyid fields of the > taxonvariant and taxon tables. My script does use your IDs for the PKs in Taxon and TaxonVariant. It then resets the ID generators to start from the next 10,000 above the max of these IDs. I'll also put your IDs into the tb1legacyid fields -- this will remove any semantic weight from the PKs, in case anyone would like to renumber them in the future. > TB2's taxonlabel table does not have a tb1legacyid field, so we > don't have a place to store the "T98303" legacy_taxon_label values. > But that's okay -- the only person who might want to know what the > new ids for TB1 legacy_taxon_labels is Rod Page, and I can email to > him so conversion tables. So don't worry about trying to store the > T98303 values. If you do want to preserve tb1legacyids in the TaxonLabels table, this is the perfect time to do that -- just let me know. It won't cost much now, but will be more troublesome later. --Vladimir |
|
From: William P. <wil...@ya...> - 2010-02-24 03:43:58
|
On Feb 22, 2010, at 11:48 AM, Vladimir Gapeyev wrote: > I am setting up an SQL script to update TI info, following your suggestions in an earlier email (below). Besides what you mentioned there, would you want to update table fields taxonvaiant.tb1legacyid and taxon.tb1legacyid? In the case of the taxon_labels, there are actually two possible "legacy" ids. One is the TB1 legacy id (which, as you note, begins with a T), and the other is an integer that I use for the mapping between the tables -- this is, strictly speaking, not part of TB1 but part of an intermediate step in the process of mapping the taxon labels to the taxonomy. I guess I would prefer it if you would override the auto-increment for the taxonvariant_id field and the taxon_id field so that they would use my integers instead -- then ignore or drop the "tb1legacyid" fields in the taxonvariant and taxon tables. But if you'd rather not do that, then allow your fields to auto-increment and instead use my integer ids in the tb1legacyid fields of the taxonvariant and taxon tables. TB2's taxonlabel table does not have a tb1legacyid field, so we don't have a place to store the "T98303" legacy_taxon_label values. But that's okay -- the only person who might want to know what the new ids for TB1 legacy_taxon_labels is Rod Page, and I can email to him so conversion tables. So don't worry about trying to store the T98303 values. But please try to store the first columns in my taxon_variant and taxon files, either by suspending autoincrement and putting them in the equivalent fields in TB2, or by putting them in the integer-typed tb1legacyid fields. > Also, I'll set 1 in the 'version' field in all 3 tables, unless there is different advice. Sounds fine. thanks, bp |
9 messages has been excluded from this view by a project administrator.
