Perl 6 - the future is here, just unevenly distributed

IRC log for #opentreeoflife, 2014-09-08

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
03:30 blackrim joined #opentreeoflife
03:30 blackrim left #opentreeoflife
11:16 josephwb1 joined #opentreeoflife
11:20 josephwb1 joined #opentreeoflife
11:20 josephwb1 you there jimallman?
11:26 towodo joined #opentreeoflife
11:29 josephwb1 joined #opentreeoflife
12:08 josephwb1 joined #opentreeoflife
12:25 towodo joined #opentreeoflife
12:52 josephwb1 joined #opentreeoflife
12:55 josephwb joined #opentreeoflife
12:56 josephwb1 joined #opentreeoflife
12:56 josephwb1 left #opentreeoflife
12:56 josephwb left #opentreeoflife
12:57 josephwb joined #opentreeoflife
13:28 josephwb you there jimallman?
14:01 jimallman josephwb: good morning
14:02 josephwb hi
14:02 josephwb i sent you an email about possible dropped commits
14:02 josephwb weird
14:02 jimallman that is odd. you’re sure you were on production?
14:03 josephwb 100% positive
14:03 jimallman i wonder if these changes were saved in the “local” phylesystem repo, but not yet pushed to github…
14:04 jimallman that could happen in theory, but any lag should be *very* brief now.
14:04 josephwb well, i was able to download it on Friday
14:04 josephwb but not on sunday
14:06 josephwb i was able to recover pretty quickly, but I thought I should let you know in case something else was dropepd
14:08 josephwb i am looking on the phylesystem-1 commits, and do not see my commits from Friday there
14:09 jimallman as i said, it sounds like these commits were “stuck” on the local phylesystem repo (on api.opentreeoflife.org) and never copied to GitHub.
14:10 josephwb ok
14:10 towodo so you think it’s fixed?  how to prevent in future?
14:10 jimallman we’ll definitely need to watch for this in the future. i need some coffee, then i’ll try to retrace our steps and see if the old api.opentreeoflife.org is still around for further investigation.
14:10 towodo yes, ot18 is still there
14:10 josephwb nothing was committed from 27 August - 6 September? seems weird
14:11 jimallman committed on github? or on ot18’s local repo?
14:11 josephwb I am looking on the phylesystem-1 commits
14:11 josephwb not the right place to look?
14:12 jimallman it’s possible something weird (conflict?) has been blocking pushes from the api server to github. we should definitely get notifications for this.
14:12 jimallman remember, we have two (three?) repos that hold phylesystem data, and we rely on automated push to get things safely to github.
14:12 josephwb but this is the weird thing: i uploaded a tree, and was able to download it later, but then it was gone. seems like a different problem?
14:13 jimallman if you were uploading and downloading through the curation app, it works directly with the “local” repo on the API server.
14:13 josephwb i definitely downloaded it, and built a synthesis tree using it
14:13 jimallman when things are working well, these changes will promptly show up on github too.
14:14 towodo the latest production system (ot20) was refreshed from github. if there were changes made to the previous one (ot18) that didn’t get pushed to github, they’ll have to be manually pushed out and then pulled (I guess)
14:14 josephwb i uploaded through the curation app
14:14 jimallman you downloaded it from *where*? direclty from github, or through the curation app or APIs?
14:14 josephwb but downloaded using gcmdr sdcripts
14:14 josephwb scripts
14:14 towodo the scripts use the api
14:14 josephwb yes
14:15 josephwb but then later i could not download it using the same scripts
14:15 jimallman in that case, they were pulling from the “local” phylesystem repo on the API server. so i’m guessing we’ll find some recent  work “stuck” in that repo.
14:16 jimallman if those later scripts were hitting the new API server, its repo would have been recently cloned from github.
14:16 jimallman it’s a good catch, definitely something we’ll need to watch going forward.
14:16 towodo latest commit to ot18 phylesystem-1 clone: Joseph “testy test”
14:17 josephwb that looks like a dev save
14:17 josephwb i only use messages like that on dev
14:17 towodo no, this is on ot18 = previous production
14:18 jimallman also, from “git status” on ot18: “Your branch is ahead of 'origin/master' by 330 commits.”
14:18 josephwb wow
14:18 josephwb ok, so, everything is there?
14:18 jimallman so yeah, this definitely needs attention.
14:18 josephwb i re-uploaded the tree in question
14:18 josephwb will this be a problem?
14:19 josephwb it has the same treeid as before
14:19 towodo well… yes, there will be a collision when we merge
14:19 jimallman just a merge conflict we’ll need to sort out.
14:19 towodo So we need another step in the release process: push api local commits out to github
14:20 jimallman so we might have been missing the commit hook for ot18, or there might be conflicts (or pending pulls from github) that have blocked the pushes. in any case, we should have some notification before the lag gets to > 300 commits.
14:21 towodo not sure how to go about fixing this - I mean the first step is to get ot18 phylesystem pushed out to github - who should do this?
14:21 towodo me? mark? you?
14:21 towodo this is an ASAP I think…
14:22 towodo (except of course you need to get your coffee)
14:22 jimallman i’m happy to do it, have done it before iirc. if there’s something blocking, i can holler here if i need help.
14:23 jimallman in theory, we could also attempt a lateral push from the repo on ot18 to the one on ot20, and push to github once any weirdness is reconciled. (this is likely for any studies that have new work on ot20.)
14:23 josephwb oy, that doesn't sound fun. hopefully it is not too painful.
14:23 jimallman in fact, we should probably suspend curation on ot20 until this is sorted out.
14:24 towodo yes probably so.
14:24 josephwb agreed
14:24 jimallman towodo: i’ll do this now. feel free to suggest the verbiage to use here, otherwise i’m going to take a swing at it.
14:25 towodo ‘repair a glitch from last friday’s upgrade’
14:26 towodo added a step to ‘notes re whole-system release’ checklist
14:27 jimallman should i add a note here that the glitch might be hiding their recent work? they can still view studies while curatio is suspended, and i’d like to avoid panic.
14:28 towodo sure
14:29 towodo the only commits on ot20 are the two of Joseph’s.  ahead of origin/master by 2 commits…
14:29 towodo so we could just discard the commits on ot20, for simplicity.  there should be no merge conflicts going to github
14:29 jimallman awesome. josephwb, you’re the canary in the coalmine!
14:29 towodo is that ok josephwb?
14:29 josephwb yes
14:30 josephwb i am using the nexson from that commit in the synthesis tree tho
14:30 towodo the important thing is just the study id, and it will stay the same, right?
14:31 josephwb right, except we use the git sha as an identifier
14:31 jimallman either way we go (old vs. new nexson), we can cleanly resolve the commit using one or the other
14:31 josephwb yes, this is not a stopper
14:31 towodo I can’t see how the sha could be consequential, but if jim can use the newer version I guess that’s better
14:31 josephwb i can make the tree, which is the important thing at this point
14:32 josephwb oh, the tree identifier in the graph is: studyid_treeid_gitsha
14:32 jimallman ok, curation is blocked on tree.opentreeoflife.org
14:32 towodo (did you know that sha1 is being phased out and is supposed to go away entirely within 20 years? it’s considered insecure)
14:33 josephwb nope
14:33 towodo sorry, 10 years, not 20
14:33 josephwb but we put the sha in per your request, i think
14:34 towodo no, I said a hash, I didn’t say which one.  I think Mark said sha1, because it’s used by github.  in this situation github trumps security
14:34 josephwb right
14:35 josephwb ok, this seems in hand. thanks jimallman and towodo for clearing this up
14:36 towodo and we’re not particularly concerned about security anyhow. and accidental collisions are astronomically improbably.
14:36 towodo s/bly/ble/
14:38 towodo I can’t figure out how to add a commit to a pull request…
14:40 towodo It says “Add more commits by pushing to the tweak-push.sh branch on OpenTreeOfLife/opentree.” which I did, and they don’t show up…
14:42 towodo oh.  they did get added, I just didn’t see the later commit buried in the pull request ‘conversation'
14:47 jimallman right. always worth remembering that github’s pull requests follow a live branch, so any new commits will be added to the PR. (i learned this the hard way.)
14:54 towodo I’m going to be mostly unavailable from 11-12 - teleconference.  (unless I get bored, then I’ll visit IRC)
15:04 josephwb towodo (I realize you may not be here, since it is past 11:00): is there a preferred/standard format for returned value names from services? e.g. "studySourceList" vs. "study_source_list" vs. something else?
15:04 josephwb want to be consistent
15:16 jimallman josephwb: i believe we’re moving toward a standard using lowercase and underscores. but please confirm with others.
15:25 josephwb ok, thanks
15:25 josephwb easy enough to change
15:30 jimallman josephwb: just to confirm, the study in question was ot_121, yes?
15:30 jimallman (the recently changed one, i mean)
15:31 josephwb yes
15:31 jimallman ok, resolving conflicts now (in old api repo)...
15:31 josephwb sweet
15:31 josephwb sorry for the re-upload; thought the first one didn't take
15:34 jimallman no problem, thanks for the heads-up
15:35 josephwb jimallman: when i push a new treemachine DB to ot10, does oti re-index automatically?
15:35 josephwb or do i need to do that?
15:37 jimallman you’ll want to trigger a fresh index… give me a minute and i’ll check my notes, there’s def a push command for that (“index”?)
15:37 josephwb ok, this will be a few hours from now, so no rush
15:57 jimallman josephwb: i’ve resolved conflicts on ot_121 and pushed recent stuff from old API server to github. i think this is good, but we’ll need to make sure we pull fresh changes to the new API server.. looking for the right tool now.
16:01 josephwb ok
16:04 jimallman i just went ahead and used ‘git pull’ from ot20:~/repo/phylesystem-1_par/phylesystem-1.
16:04 jimallman the curation app now shows your “testy test” commit (a curatosr’s comment) on Cryan, 2004
16:05 jimallman History tab:  http://tree.opentreeoflife.org/curator/study/view/pg_2581/?tab=history
16:05 jimallman Metadata with visible comment:  http://tree.opentreeoflife.org/curator/study/view/pg_2581/?tab=metadata
16:06 jimallman josephwb: please take a look at your study and see if everything looks OK:  http://tree.opentreeoflife.org/curator/study/view/ot_121
16:06 jimallman if this looks good, i’ll reenable curation
16:11 josephwb *looking*
16:11 josephwb looks ok
16:15 jimallman kewl. i’m still not sure what blocked the scheduled push, but it might have been this change done remotely? https://github.com/OpenTreeOfLife/phylesystem-1/commit/ddfd9fadeb4f6b1cf50562eda04a1d21a9b113c3
16:16 jimallman (i accidentally pushed from the new API server, so when i tried to push from old, your ot_121 conflict was the only obvious blocker)
16:17 jimallman ok, curation is back up on production
16:18 towodo excellent, thanks much
16:19 towodo that commit just changes the README.md, should have no effect except on people
16:26 jimallman right, but i wonder if it was enough to force a pull-then-push from the API repo..?
16:26 towodo oh. hmm.
16:27 towodo do we need to review this with Mark  or Emily?
16:27 jimallman yes, i think so. the logs show when a push attempt is happening, but not when/why they fail
16:28 jimallman i’ll create a ticket for this, just trying to decide the best “home” for it: phylesystem-api? peyotl?
16:56 jimallman i added it to phylsystem-api: https://github.com/OpenTreeOfLife/phylesystem-api/issues/106
17:04 mtholder joined #opentreeoflife
17:04 codiferou joined #opentreeoflife
17:06 josephwb i haven't got a hangout invite
17:07 jimallman i just sent one
17:08 codiferou did it work?
17:09 josephwb yes, thanks
17:14 josephwb just got my invite!
17:40 codiferou joseph
17:40 codiferou you still there?
17:41 codiferou sounds like we don't have a use case for the taxonomic traversal mrca in treemachine
17:53 josephwb joined #opentreeoflife
18:00 mtholder left #opentreeoflife
18:01 josephwb looks like i got my internet back
18:01 josephwb right?
18:02 josephwb maybe not
18:02 codiferou looks like it
18:02 towodo I think you did.
18:03 josephwb good
18:03 josephwb in the curator, is one able to map to "dubious" names?
18:04 towodo the term “dubious” is deprecated
18:04 josephwb i know
18:04 josephwb that was an umbrella term for "filtered" etc.
18:04 towodo taxomachine filters out the really bad ones, “not_otu”, but keeps incertae sedis and extinct.
18:04 josephwb = stuff that does not make it into treemachine
18:04 towodo treemachine also filters out incertae sedis and extinct.
18:05 towodo the curator consults taxomachine, so you can map incertae sedis and extinct taxa, even though treemachine pitches them
18:06 towodo I’ve been urging retention in treemachine of incertae sedis taxa that occur in source trees, but stephen either disagrees that this is sensible, or doesn’t have time to implement it
18:07 josephwb it is much more difficult
18:07 josephwb either have to have them all in, and turn them "on" if encountered
18:07 josephwb or add them on the fly
18:07 codiferou there has been a long-standing issue to be resolved, that the tnrs needs to return only "good" taxa for the curator
18:08 josephwb right
18:08 josephwb a curator will want "good" names
18:08 towodo I’ve never understood why implementing i.s. in treemachine is hard, but I guess it has to do with the way the code is written, factors invisible to me
18:08 towodo lots of incertae sedis names are perfectly “good” … these are things with descriptions, DNA, etc.
18:09 josephwb ok, so back to mrca for a moment
18:09 codiferou we need to retire the "dubious" category and implement a "mappable" one or something
18:09 josephwb as it stands, both flavours (synth-mrca and taxonomy-mrca) come from treemachine
18:09 codiferou should probably talk about that via hangout, i think there's some lurking complexity
18:09 josephwb in the curator, i mean
18:10 towodo cody, i thought you said taxomachine implemented taxonomy-mrca ?
18:10 codiferou yes
18:10 josephwb codiferou: for "dubious" or "mrca"?
18:10 codiferou new service
18:10 codiferou for dubious
18:11 codiferou apologies for interleaving
18:11 codiferou taxomachine now exposes a service called "taxonomy/lica" that is the equivalent of an mrca
18:12 codiferou that is new. was not available before recent api_v2 branch edits
18:15 towodo lurking complexity?  I thought it was starting to sound pretty clean.  you mean around nodes that aren’t in the synthetic tree?
18:16 josephwb the way that i see it, there are 3 flavours of mrca
18:16 josephwb 1) mrca in taxonomy
18:16 josephwb 2) mrca in synth tree
18:16 josephwb 3) closest named taxon to #2
18:17 codiferou ok
18:17 towodo 3) could be implemented as 2) followed by a node-info service call
18:17 josephwb all can be distinct
18:17 josephwb right, i think we are heading that way now
18:17 josephwb 1) is a curator tool
18:17 codiferou it's trivial to include #3 in the results for #2
18:18 towodo it’s one more round trip by the curator but I’m ok with that
18:18 josephwb 2) & 3) are different
18:18 josephwb but yes, easy to combine
18:19 josephwb currently, the curator does 1) & 3)
18:19 josephwb in treemachine
18:19 towodo my proposal is for the curator to do 1) in taxomachine and 2) in treemachine, followed by node-info to get the nearest taxon
18:19 codiferou i'm not sure what the advantage would be for not including 3 in the results of 2
18:19 josephwb with the "walk-to-tips" approach for 1) (if necessary)
18:20 josephwb no, i am not arguing that
18:20 codiferou the walk-to-tips approach should be for #2, correct?
18:20 towodo and I’m not sure 2) in the curator app is desirable; as I remember Jim implemented it as an experiment so we could see whether it was
18:20 codiferou others might want it
18:20 towodo yes.
18:21 josephwb no, in the curator we want 1 & 3
18:21 josephwb both have names; 2 might not
18:21 codiferou right
18:21 josephwb well, in the curator we just want 1, i think
18:21 codiferou let's just consider that 3 is a property of 2
18:21 josephwb as i said, the curator doesn't know the structure of the synth tree
18:21 josephwb curator = person
18:22 josephwb ok, just wanted to be clear about the different meanings of ""
18:22 josephwb mrca
18:22 josephwb treemachine will do 2 & 3
18:23 josephwb curator (app) will have to change call to taxonmachine for #1
18:23 codiferou right, to the /taxonomy/lica service
18:23 josephwb yes
18:24 josephwb i think part of the reason for having everything in treemachine was that is was a common DB; taxomachine and treemachine may diverge in terms of taxonomy version
18:24 josephwb treemachine will almost always lag
18:24 codiferou that seems like a reason to test against taxomachine
18:25 josephwb i agree, except in treemachine you were guaranteed to have "good" (that is, unfiltered) taxa
18:25 josephwb but if people are uploading dinosaur trees, treemachine can't do it
18:25 josephwb so, yes, i am for taxomachine doing things
18:26 towodo right now taxomachine is ahead
18:27 towodo (on production system)
18:27 josephwb (playing devil's advocate here): what if someone wants the taxonomy-mrca of node ids (not ott ids) from the synth tree?
18:28 towodo tough
18:28 josephwb we will just not offer this as a possibility
18:29 josephwb mrca takes in any combination of ott ids and node ids
18:29 codiferou why would someone want that?
18:31 josephwb you brought this up the other day
18:31 josephwb say, the mrca for 2 source trees
18:31 josephwb both roots could be unnamed
18:31 josephwb or, we say screw it to such request?
18:32 codiferou then get all the ott ids mapped to those tips and query the taxonomy
18:33 josephwb i wonder if the newly defined treemachine mrca should be draconian?
18:33 josephwb *only* accept nodes in the synth tree?
18:33 josephwb if this only deals with the synth tree, maybe this is what we should do?
18:34 josephwb no
18:34 josephwb nevemind
18:34 josephwb users may specify non-monophyletic taxa
18:34 codiferou yes, i think you're right about that
18:34 josephwb e.g. their favourite genus
18:34 codiferou or source trees whose roots are outside the draft tree
18:35 josephwb right about being Draconian?
18:35 josephwb becuase i convinced myself otherwise
18:35 codiferou no, right about not wanting to be draconian
18:35 josephwb how about this: queried node MUST be either 1) in the synth tree or 2) in the taxonomy
18:36 codiferou why?
18:36 codiferou then source tree nodes can't be queried
18:36 josephwb i thought that was what you were getting at
18:36 josephwb "source trees whose roots are outside the draft tree"
18:36 codiferou right, i think we should allow those
18:37 josephwb i am lost
18:37 codiferou i was agreeing with you
18:37 josephwb if they are not in the synthetic tree?
18:37 josephwb do you mean querying individual sources trees?
18:38 josephwb i was thinking that:
18:38 josephwb tree/mrca
18:38 josephwb *only* answers questions about the synth tree
18:39 josephwb source tree queries are interesting, but maybe a separate service?
18:39 codiferou modified conversation for clarity:
18:39 codiferou Joseph: "i wonder if the newly defined treemachine mrca should be draconian?  ... no. nevemind. users may specify non-monophyletic taxa. e.g. their favourite genus "
18:39 codiferou Cody: "yes, i think you're right [we should not be draconian]. [they may also want to query nodes] whose roots are outside the draft tree"
18:40 codiferou sorry about the accidental giant space
18:40 josephwb ok, i follow
18:40 josephwb i think
18:40 josephwb maybe not
18:40 josephwb how do you get a mrca for something outside the synth tree?
18:41 codiferou additional edit: "nodes" should be "source tree"
18:41 josephwb walk to the tips?
18:41 codiferou yes
18:41 josephwb walk the source tree relationships, or the taxonomy?
18:41 josephwb (might not have taxonomy relationships)
18:41 codiferou hm
18:42 josephwb i think we are on the same page now
18:42 josephwb hm
18:42 josephwb now, to turn it back at you, will people ask that sort of question?
18:42 codiferou i don't know
18:43 josephwb i kinda feel like no
18:43 codiferou yeah, i'm not coming up with an example of a use case
18:43 josephwb do you agree that querying individual source trees might be something someone wants to do?
18:44 codiferou what kind of querying?
18:44 josephwb i guess, getting the mrca of the source tree (not necessarily in synth)
18:45 josephwb i don't know if anyone would want to do things like this
18:45 codiferou the synth mrca of a source tree node not in synth?
18:45 josephwb but it seems it should be separate form the synth tree queries
18:45 josephwb no, osrry
18:45 josephwb the mrca of the source tree itself
18:46 josephwb it might be overruled in synthesis
18:47 codiferou can you do a g+ hangout?
18:47 josephwb give me a minute
18:48 codiferou ok
19:06 josephwb hey codiferou
19:07 codiferou yeah
19:07 josephwb for "hiding" the arguson format, just delete the parameter description?
19:08 codiferou the parameter is "format", right?
19:08 josephwb yes
19:08 codiferou i think we want to leave the description, but remove any mention of the "arguson" format
19:08 codiferou could just say 'currently the only supported format is "newick"'
19:08 codiferou or something
19:08 josephwb ok
19:14 PEM joined #opentreeoflife
19:20 mtholder joined #opentreeoflife
19:22 mtholder hey jimallman and towodo : (as you know) it has been a while since I delved into deployments, etc. Have the pem files changed?  I was trying to ssh into ot18 using my old opentree.pem and having no luck
19:23 jimallman there’s a more recent production.pem that we use to avoid deployment mishaps. do you need this?
19:23 mtholder yes
19:23 towodo ot18 is a production server so uses the production pem.
19:23 mtholder I just wanted to look at the logs to diagnose what happened with the git pushes failing...
19:24 towodo i’ve been using a secure channel, either PGP or putting the file in people’s directory on norbert.csail.mit.edu
19:24 towodo or we could change the authorized_keys for ot18, since it’s not in use for production any more
19:24 mtholder I can get in to norbert
19:25 towodo I’ll copy the key there, give me a minute
19:25 mtholder thanks
19:27 towodo ok, it’s in ~mholder/production.pem
19:29 mtholder got it. thanks.
20:13 josephwb jimallman: your emails are getting scary
20:13 jimallman ? sorry
20:14 josephwb did something happen a while back?
20:14 josephwb with the commits
20:14 josephwb maybe i misread things
20:15 jimallman i assume this is about a recent comment on this issue? https://github.com/OpenTreeOfLife/phylesystem-api/issues/106
20:15 josephwb yes
20:16 jimallman no scary news, just trying to figure out when (and why) things stopped sync’ing with GitHub
20:16 jimallman and how we can be more responsive if it happens again (since it was a surprise this time)
20:17 josephwb i ask because i have come across studies that have worked fine in the past, but recently fail (in treemachine), despite no recent commits
20:17 josephwb i don't understand it
20:17 josephwb but it aligns with my experience the other day of a tree being present, but then gone
20:18 josephwb on a "local" repo
20:18 codiferou towodo you there?
20:19 towodo yes
20:20 codiferou do we want to put the add the oti indexing service to the studies plugin to produce the url "studies/index_nexsons" (or something like that) or do we want to keep this in a separate plugin?
20:23 towodo I don’t much care… this is not something we will publicize… ideally it would be secured but security is orthogonal to naming in this system
20:23 towodo fewer pluging means fewer apache redirects, which is sort of good
20:23 towodo s/pluging/plugins/
20:25 codiferou it will not be publicized, but is someone supplies an HTTP GET to http://devapi.opentreeoflife.com/v2/studies it will show up in the neo4j-generated list of services
20:26 codiferou so, security would probably be important for public deployment, i.e. this week
20:29 codiferou semantically it seems nicer to keep it all in one plugin under "studies". how much do you care about security, towodo ?
20:30 towodo it’s had to go on the back burner unfortunately. I wrote the code and it worked, I don’t remember why I didn’t deploy it
20:31 towodo you can put it under ‘studies’
20:31 codiferou ok
20:32 codiferou should have mentioned, probably more relevant for security: the question applies to the "unindex_studies" service as well
20:32 codiferou next question is what to call them
20:33 codiferou index_studies and unindex_studies?
20:33 towodo no opinion
20:33 codiferou will go with that then
20:51 jimallman josephwb: i don’t know enough about your situation (failed snthesis) to even guess. i’d be surprised if the trees were corrupted, if anything they’d just be outdated. can you compare the expected vs. found commit SHAs, to see if they “reversed” from one synthesis to the next?
20:52 josephwb i will check
20:55 codiferou jimallman will you have a quick look at jonathan's comment here: https://github.com/OpenTreeOfLife/taxomachine/commit/1c5e1fa216a87302959efecc9b8b7f8fc4acc33b#commitcomment-7705421
20:56 codiferou i thought we had confirmed that none of the GetJsons stuff from taxomachine was used
20:56 josephwb all: for the induced_subtree method, what should i do if (some) nodes are not in synthesis: 1) report error, or 2) return subtree i can, with note of missing nodes?
20:56 josephwb i think error
20:56 josephwb maybe?
20:57 josephwb codiferou?
20:57 codiferou i think i would do #2
20:57 josephwb ok
20:58 josephwb don't think we want to do any fancy path walking
20:58 towodo I’m looking at it… I’m wrong about /node, ignore that (it’s a treemachine ref, not a taxomachine ref)
20:59 towodo I see, it seems to be conditionalized out
20:59 codiferou josephwb, i agree. i think for missing nodes, we can state explicitly in the docs that if a node is not in the synth tree, it will be noted but ignored
21:00 towodo if (this.useTreemachine) { … } else { … getConflictTaxJsonAltRel_url. … }
21:01 towodo (it sure would be nice if the tree browser worked against taxomachine… but that’s another story)
21:03 jimallman towodo: sorry, replied to the issue and didn’t realize you were also digging.
21:03 towodo no, that’s ok, I was being compulsive
21:04 towodo Cody proposes to purge it altogether, I think - he has made the method disappear from taxomachine
21:05 towodo if the method doesn’t exist it would make sense to me to purge it from the opentree repo…
21:05 codiferou we can revive those services under different names in the future. they are broken now anyway, would require some work to update for current db structure
21:07 jimallman i figured as much, and argus might be gone by the time we come this way again..
21:07 codiferou likely arguson as well
21:07 jimallman yep
21:10 josephwb codiferou: for the subtree methods, seems like we could have 2 errors: 1) bad ids (not in graph), 2) good ids, but not in synth tree
21:10 josephwb is it worth it to split these out?
21:11 codiferou i think so, they mean different things and users might want this info
21:11 josephwb ok
21:12 codiferou seems like they should just be two different lists in the results. in the case of no such errors, both lists would be empty
21:13 josephwb we also have node_id vs. ott_id
21:13 josephwb i currently have those split out
21:14 josephwb but i wonder if 4 lists is useful
21:16 codiferou yeah, it's getting awkward, but i think its ok. 4 is still a manageable number. i imagine that it will be more tedious for users to track it down if we don't specify than to ignore 4 lists if they don't care
21:17 josephwb i agree; combining ottids and nodeids into a single list is messy
21:17 josephwb (if anyone ever does that)
21:17 codiferou they could overlap, would be ugly
21:18 josephwb i have it set up to only report "bad" node lists if they are present; if not, no empty lists come through
21:18 josephwb but you think it should always have the same number of returned objects?
21:18 josephwb even if they are empty?
21:18 josephwb probably, right?
21:19 codiferou it's more consistent, and avoids the need to check if the object exists before attempting to do things like count elements
21:19 josephwb gotcha
21:19 codiferou but i don't have a strong opinion
21:19 josephwb happy to do whatever
21:19 codiferou i usually return empty lists
21:20 josephwb ok. we should be consistent
21:26 josephwb codiferou: there is also a preexisting "found_nodes". i don't know if this is useful. and it is all node ids, even if query was ott ids
21:26 josephwb what do you think?
21:26 codiferou probably not useful
21:26 josephwb *throwing it out*
21:26 josephwb thanks
21:27 towodo jimallman, I addressed your comment on https://github.com/OpenTreeOfLife/opentree/pull/423
21:30 towodo all pull requests reviewed… I need to get some fresh air
23:59 towodo joined #opentreeoflife

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary