Weekly check in 2012.08.30

• <grant_h> Should we get the check-in started?
• <novalis_dt> Sure
• <novalis_dt> Sorry for the delay; I got a bit distracted
• <novalis_dt> I merged RAPTOR into master
• <novalis_dt> Also been working a bit on the nginx plugin for OTP dispatching
• <novalis_dt> And I decided to try out a GPGPU technique, but then it turned out that (a) the software was rather crappy and (b) it depended on a proprietary compiler
• <novalis_dt> Anyone else? mattwigway ? abyrd ?
• <mattwigway> I've been working mostly on OTP North America deployment management.
• <mattwigway> And I've also had several discussions with novalis_dt about speeding RAPTOR; I may try an approach I proposed this morning that turned out to be similar to something novalis_dt tried a while ago.
• <abyrd> I've been sick the last few days so moving a bit slow. Since novalis_dt merged raptor I am reviewing a merge of my stoptime update changes and it looks painless.
• <novalis_dt> abyrd, will that merge also offer the easy ability to get next/previous trips?
• <abyrd> I would like to do a full speed comparison of several branches on rackspace open stack servers in the next couple of days
• <mattwigway> is that just routing speed comparison, or also itinerary comparison?
• <abyrd> novalis_dt, it's not in that branch right now but should be working when I merge to master
• <novalis_dt> Speaking of itinerary comparison, grant_h, when will FrankP be back?
• <novalis_dt> Or or is he back now but not in this meeting?
• <abyrd> mattwigway, there is no automated itinerary comparison, but all the results will be in a database
• <grant_h> he's back
• <grant_h> I'll shoot him an email
• <abyrd> so that will allow setting up some queries for results comparison
• <novalis_dt> OK, I'll email him about setting up a RAPTOR instance for testing
• <mele> yeah he had some things he wanted to talk about in the chat today too
• <grant_h> I think specifically he was wondering when the fixes for issues 799 and 803 would be cherry picked into the stable branch as we'd like to resolve those issues on theTriMet instance asap
• <novalis_dt> At this point, we should stop cherry-picking and cut a new stable
• <novalis_dt> Any reason we can't do that now?
• <novalis_dt> Note that a new stable does not require one to use RAPTOR; it's still optional.
• <mattwigway> I don't think we've really tested the edge unwrapping too much.
• <mattwigway> See ticket #807
• <novalis_dt> Well, maybe I'll ask Frank to set up two test instances on master as it is now (one with RAPTOR and one without)?
• <novalis_dt> Don't know if he's willing to do that, but we can ask
• <mattwigway> I'm fairly confident it's fine, but there may be little things that are different.
• <mattwigway> Although the code should be more manageable now; board/alight are definitely symmetrical (since it's the same code paths)
• <abyrd> novalis_dt, we can just merge master back to stable, right? I can cut a release from there if we really want to tag it.
• <novalis_dt> We can do that
• <novalis_dt> Do we want to declare this under-tested thing stable?
• <abyrd> maybe not
• <abyrd> if frank wants to update right away why don't we just cherry-pick the fixes he's interested in into master
• <abyrd> then get rid of stable after thoroughly testing master
• <abyrd> we can do that now with novalis_dt mattwigway and my changes all in place
• <novalis_dt> IIRC, one of those fixes relies on a lot of Matt's refactoring
• <mattwigway> I think all the fixes he's interested in are already in master, abyrd
• <abyrd> yes, I think they are all in master but he's running stable
• <abyrd> if i understand correctly
• <mattwigway> Oh, so you meant "cherry pick the fixes into stable"
• <abyrd> yes, my mistake
• <mattwigway> np
• <mattwigway> yeah, the #803 fix relies on my changes a bit and would be a bit of a messy merge.
• <mele> maybe at least the other one then?
• <mele> or just the other one?
• FrankP (1815504e@gateway/web/freenode/ip.24.21.80.78) has joined #opentripplanner
  • <mele> we've got big service changes this weekend and trip planner traffic will be high
  • <mele> speak of the devil :)
  • <mattwigway> But I think the only real problems would be replacing state.getBackMode() with state.getBackEdgeNarrative().getMode() in PlanGenerator.java
  • <FrankP> I prefer satan
  • <mattwigway> #799 should be easy.
  • <novalis_dt> Ah, Frank, I was just about to write
  • <novalis_dt> I just merged RAPTOR to master
  • <novalis_dt> It would be great if you could set up an instance using it so that mele can let me know which routes are bad and I can improve the code
  • <FrankP> I can do that. Not in the stable version, but in head correct?
  • <novalis_dt> Right
  • <novalis_dt> Basically, all you need to do is replace your pathService in application-context.xml with
  • <novalis_dt> * <bean id="pathService" class="org.opentripplanner.routing.impl.raptor.Raptor"/> and add org.opentripplanner.graph_builder.impl.raptor.RaptorDataBuilder and (optionally) org.opentripplanner.graph_builder.impl.transit_local_streets.TransitLocalStreetComputer to your graph-builder.xml at the end of your list of builders
  • <FrankP> Okay, I'll get something done at the latest next week (like mele said, big service chane this week, and I'm trying to get a tilecache seeded, which has been giving me some problesm
  • <mattwigway> actually, abyrd novalis_dt, pulling 55f0399b6cf96a7d3966c17c4dfe4f440aa6eb41 into stable and replacing state.getBackMode() with state.getBackEdgeNarrative().getMode() should be sufficient for 803.
• atogle ([email protected]) has joined #opentripplanner
  • <novalis_dt> mattwigway, OK, can you do that?
  • <abyrd> mattwigway, so does that cover both bugfixes that frank needed?
  • <FrankP> Sounds good...I'll get it done novalis_dt.
  • <mattwigway> no, for 799 you'll need 90590618fa511ff8cee9983995b8823db3bd3aec
  • <mattwigway> I can pull them both and see what happens, but I'm in the middle of some deployment stuff now.
  • <abyrd> i mean, with the small modification you just mentioned we can cleanly cherry-pick both into stable
  • <novalis_dt> FrankP, awesome!
  • <mattwigway> abyrd, I think so.
  • <abyrd> cool
  • <mattwigway> if someone else wants to pull that's fine too if you want it done ASAP.
  • <novalis_dt> OK, I'll do it then
  • <mattwigway> let me know if anything isn't as I described.
  • <abyrd> mattwigway, it looks like you and I both have some dead branches lying around the repo
  • <mattwigway> Incidentally, with 805 I had trouble reproducing that exact plan (because of differing weights &c.); you'll see the OSM file I attached to the issue which is a test case.
  • <mattwigway> abyrd, yep.
  • <abyrd> should we clean these out or leave them in for historical reasons?
  • <mattwigway> I'm always afraid to use git branch -d for fear I'll break something...
  • <mattwigway> I think I have old branches going back to Jan - or that might be in my clone.
  • <mattwigway> *my fork
  • <abyrd> mine are generally merged back to master with no dangling commits on top, so I'll just remove them as clutter
  • <abyrd> I believe to actually make anything disappear from the shared repo, you have to use the bizarre colon syntax
  • <mattwigway> I'll let you - feel free to delete anything of mine with no dangling commits.
  • <abyrd> so you don't risk too much by deleting branches. you're just deleting names from your local repo and the commit blobs are still floating around
  • <mattwigway> right, but figuring out what is what could be a pain.
  • <mattwigway> My last few branches have not been merged to master, but rebased on master and then master has been fast-forwarded.
  • <mattwigway> Does that make things any different?
  • <abyrd> ok, you can even leave them around if you like. just thinking it looks like time for a bit of cleanup.
  • <abyrd> mattwigway, it means that those branches still exist separately. I'm kind of wary of touching them because it's not obvious if you've got extra commits in there.
  • <abyrd> but if you tell me they're 100% rebased onto master, I can clear them out
  • <mattwigway> I think they are but am not positive.
  • <mattwigway> I guess the thing to check is whether the last commit in git log on each branch is in master.
  • <novalis_dt> mattwigway, actually, maybe you better do the merge on #803 -- that commit seems to add calls to setBackMode() but doesn't actually add the method itself.
  • <abyrd> it would be nice if there was a way to rebase onto master and have that show up in the history
  • <novalis_dt> I'll push my merge of #799
  • <abyrd> though I guess that would involve rewriting history about where the branches diverged
  • <mattwigway> right, novalis_dt, setBackMode requires the whole edge unwrap.
  • <novalis_dt> So I can't just cherry-pick that patch
  • <mattwigway> but replacing setBackMode with getBackEdgeNarrative().getMode() should work.
  • <novalis_dt> wait, how does a getter replace a setter?
  • <mattwigway> *getBackMode
  • <mattwigway> should have said:
  • <mattwigway> but replacing getBackMode with getBackEdgeNarrative().getMode() should work.
  • <novalis_dt> So, remove setBackMode()
  • <mattwigway> setBackMode shouldn't be in that commit, is it?
  • <novalis_dt> It is.
  • <novalis_dt> Oh, hm
  • <novalis_dt> Actually, it looks like it was already there, it just gets changed
  • <novalis_dt> I think it will be more efficient for you to do this merge, since you wrote the original commits
  • <mattwigway> OK, I'll tackle it in a bit.
  • <novalis_dt> Thanks
  • <mattwigway> Oh, I see what I did.
  • <mattwigway> Should be an easy fix.
  • <novalis_dt> OK, I guess that's probably it for the meeting?
  • <mele> looks like it :)