Weekly check in 2012.08.30 - GeoSmartCity-CIP/gsc-opentripplanner GitHub Wiki
<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.
<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?