Timestamps are in GMT/BST.
[2:25] * jbalogh (~jeff@c-71-202-47-205.hsd1.ca.comcast.net) Quit (Quit: jbalogh)
[8:48] * bwinton_away is now known as bwinton
[9:02] * cvan (~cvan@c-76-102-14-98.hsd1.ca.comcast.net) Quit (Quit: cvan)
[9:48] * hazure (~cjmuise@red-gw41.cs.toronto.edu) has joined #basie
[10:02] * cvan (~cvan@c-76-102-14-98.hsd1.ca.comcast.net) has joined #basie
[10:03] * mi_sa (~chatzilla@CPE0018f84598ad-CM001a666bf052.cpe.net.cable.rogers.com) has joined #basie
[10:15] * jharjono (~chatzilla@nat/ibm/x-tbtippqptesaogdt) has joined #basie
[10:19] * colin_m (~colin@whit179.ucres.utoronto.ca) has joined #basie
[10:30] * janr (~janr@btr189.neoplus.adsl.tpnet.pl) has joined #basie
[10:37] * jyeung (~chatzilla@CPE001d73111113-CM000a7366632e.cpe.net.cable.rogers.com) has joined #basie
[10:42] <colin_m> Hey, Jan, are you around?
[10:43] <janr> Yeah
[10:44] <_lance_> morning
[10:44] <colin_m> I'm just curious, in the get_history method in the HgPathNode class, why return a generator rather than a list?
[10:44] * Joel_C (~chatzilla@uc059-2.uc.utoronto.ca) has joined #basie
[10:45] <colin_m> I'm not really familiar with them, but I did some reading and I didn't really get the advantage.
[10:45] * ZeeshanQ (~zqureshi@m115-133.on.tac.net) has joined #basie
[10:45] <_lance_> afk while I get coffee started
[10:46] <janr> My reasoning was that if the history list is really large, we don't need to fetch the whole thing at once and populate a huge list.
[10:46] <colin_m> Okay, that makes sense.
[10:48] * jango (~jango@67.55.49.87) has joined #basie
[10:49] <janr> Now that I think about it some more, it will depend on how the backend is implemented. It may end up being more efficient to fetch a list and let the user decide how much of it they want.
[10:50] <jango> hey cvan, nostalgia?
[10:54] <Joel_C> grabbing info you don't need is a bad idea, though
[10:54] <Joel_C> it's part of the reason that apps like Blackboard perform so badly
[10:55] * DaveWeber (~chatzilla@nat/ibm/x-bwdlyfonrffavcjk) has joined #basie
[10:58] <jyeung> Hi Everyone, meeting starting soon. in 2 minutes
[10:58] <janr> Yeah, I agree... by end user I meant the user of the api. Let them decide if they want the whole thing or a specific chunk. Sorry if I wan't clear.
[10:59] * nduthoit1 (~nduthoit@74.198.8.70) has joined #basie
[11:00] <Joel_C> oh yeah that makes sense
[11:00] <jyeung> okay lets start
[11:01] <jyeung> I will be moderating today's meeting, is everyone here?
[11:01] <jyeung> @_lance_ ?
[11:02] <jyeung> @bwinton
[11:02] <jharjono> afk while getting coffee he said
[11:02] <_lance_> I'm here
[11:02] <jyeung> @colin_m
[11:02] <colin_m> Present
[11:02] <_lance_> my french press is sitting right next to me, still steeping
[11:02] <bwinton> Here!
[11:02] <_lance_> 1 more minute to go
[11:02] <jyeung> @cvan
[11:03] <bwinton> (Also, Go South Africa! Or maybe Go Mexico! I haven't decided yet.)
[11:03] <jyeung> @DaveWeber
[11:03] <DaveWeber> South Africa for sure
[11:03] <DaveWeber> I'm here
[11:03] <jyeung> @hazure
[11:03] <jyeung> @jango
[11:03] <jyeung> @janr
[11:03] <janr> Here.
[11:03] <jango> pr??sent
[11:03] <jyeung> @jharjono
[11:04] <jharjono> yep
[11:04] <jyeung> @Joel_C
[11:04] <Joel_C> yes
[11:04] <jyeung> @jyeung
[11:04] <jyeung> I am here
[11:04] <jyeung> @mi_sa
[11:04] <jharjono> that is so meta
[11:05] <jyeung> @nduthoit1
[11:05] <nduthoit1> pr??sent
[11:05] <jyeung> @ZeeshanQ
[11:05] <Joel_C> hahah that is so johan
[11:05] <ZeeshanQ> here
[11:05] <jyeung> okay everyone is here.
[11:06] <jyeung> We have complete the API and the http request for the diff view last week.
[11:06] <jyeung> Any comments/changes to the Api?
[11:07] <jyeung> or suggestions?
[11:07] * nduthoit1 (~nduthoit@74.198.8.70) Quit (Read error: Connection reset by peer)
[11:07] * jbalogh (~jeff@c-71-202-47-205.hsd1.ca.comcast.net) has joined #basie
[11:07] <colin_m> The approaches taken by the two teams seemed to be a bit divergent. If they're going to go the sub-classing route like the SVN team did, shouldn't they work together to prototype the base classes?
[11:08] <janr> I was going to say the same thing... colin_m beat me to it. ;)
[11:08] <colin_m> <-- ninja
[11:08] <jyeung> @jablogh welcome, we are talking about any sugguestions to the API.
[11:09] * jbalogh (~jeff@c-71-202-47-205.hsd1.ca.comcast.net) Quit (Client Quit)
[11:09] <jyeung> I think the idea is to have both the API to be as similar as possible
[11:09] <mi_sa> sorry yes i'm here
[11:12] <jyeung> So one of the task for the backend teams are to work together to make one API while the difference can be in their subclasses. Suggustions?
[11:13] <jyeung> Open discussion... moving on if none.
[11:13] <janr> One question...
[11:14] <jyeung> yes
[11:14] <janr> The get_rev method of the SvnRepo... what metadata does it return? The contents? The commit info?
[11:15] <_lance_> it returns a SvnRevision object, which contains the comment, date, revision number, and a list of paths
[11:15] <janr> Aha.
[11:15] <jyeung> any other questions?
[11:16] <janr> One more...
[11:16] <Joel_C> @_lance_ the file says it returns a string
[11:17] <_lance_> oh, my mistake.. was thinking of the wrong method
[11:17] <janr> I may have missed something, but how do you get the contents of a file at a specific revision?
[11:17] <Joel_C> @_lance_ your description sounds right
[11:18] <_lance_> looks like you can't. okay, we'll add a revno param to get_file
[11:18] <Joel_C> I think the return type should not be a string
[11:18] <_lance_> i think i mistakenly deleted it when i was clearing out all of the outputtype="html" params
[11:18] * cvan (~cvan@c-76-102-14-98.hsd1.ca.comcast.net) Quit (Quit: peace)
[11:19] <jyeung> okay we will continue this in the mailing list. Have a list to go through...
[11:20] <jyeung> Next topic: What's going to be build for next week?
[11:20] <jyeung> Open discussion.
[11:20] <mi_sa> wait before we move on, i'd like to point out that the directory view should also have a pull-down menu
[11:21] <mi_sa> to select which revision # to see just like the file view
[11:21] <mi_sa> which means change in api (get dir must also take in revision #)
[11:21] <jyeung> okay mi_sa
[11:22] <mi_sa> and when navigating from the directory, i think it should stay in the same revision #
[11:22] <Joel_C> agreed
[11:22] <mi_sa> rather than automatically going back to head (the file may not exist, afterall)
[11:22] <jyeung> so it should add a revno parameter
[11:22] * nduthoit (~nduthoit@74.198.8.70) has joined #basie
[11:23] <jyeung> Any sugguestion for next week?
[11:23] <mi_sa> yes, for most links going from the directory view (and also going back a path for file and dir view)
[11:23] <_lance_> on that note should we have revno params at is_binary is_image etc ?
[11:23] <janr> Another option is to have the file context objects that exist for a specific revision only...
[11:23] <janr> I think that the mercurial object does it that way.
[11:23] <janr> not object... module.
[11:24] <jyeung> okay anymore?
[11:24] <jyeung> We will get back to what's going to be built for next week.
[11:25] <jyeung> Open topic; How are people going to test their back ends?
[11:25] <jyeung> Do we write our unit tests for it? What do we need to set up?
[11:26] <_lance_> Mock object unit tests, yup
[11:27] <jyeung> And do we write the unit test before we start or after we are done with the api
[11:27] <_lance_> When the API is solid, but before code has been written ideally
[11:27] <jyeung> Sounds good. any other sugguestions?
[11:28] * jbalogh (~jeff@67.218.103.227) has joined #basie
[11:28] <jyeung> moving on....
[11:28] <jyeung> Can the front-end team start producing high-quality mockups and start doing some user testin?
[11:30] <jyeung> @mi_sa ?
[11:30] <jyeung> I take that as a yes ......
[11:30] <colin_m> How would the high-quality mockups differ from the current ones?
[11:31] <jyeung> A working prototype
[11:31] * nduthoit (~nduthoit@74.198.8.70) Quit (Read error: Connection reset by peer)
[11:31] <jango> do you maybe mean making django templates out of the mock ups?
[11:31] <jyeung> intead of opening a dialog that shows the http request and api
[11:32] <jyeung> ideally yes with django template. the current mock-ups are for us to build the API's
[11:33] <jyeung> the high-quality mock ups are for end users, so it could be setting up links so you can open up a file view when you click on a file from the directory view
[11:34] <colin_m> Okay, I guess I'll speak on behalf of the front-end team and say 'yes'.
[11:34] <jyeung> =)
[11:35] <colin_m> I'm wondering, should we be using Django's templating language, or would it be okay to use another?
[11:36] <jyeung> What are they advantage for using it? What about disadvantage
[11:36] <Joel_C> I think Django's templates should be able to get the job done
[11:36] <jango> @colin_m what do you mean?
[11:36] <jango> of course we are using django templates, it's a django app O_o
[11:36] <colin_m> (Anyone with an opinion, feel free to chime in. I kind of like Mako better than Django's template language, but I wonder if because this is a Pinax app, we should restrict ourselves to the most Django-esque options)
[11:36] <Joel_C> unless there are compelling reasons to switch, I would be in favour of sticking with the django templating
[11:36] <janr> I think we should stick with django's. If we want to eventually push this back to pinax, sticking with django would be a must.
[11:36] <jharjono> agreed
[11:36] <colin_m> Okay, sounds good.
[11:36] <Joel_C> yes we should stick with the Django way unless it really makes sense to do it otherwise
[11:37] <jyeung> Django it is.
[11:37] <jyeung> What has to be done to package everything up for Pinax?
[11:38] <jango> a pinax app needs to be setup in the repo. you should delegate someone to do that
[11:38] <jango> after that all changes must be submit through the review board
[11:39] <jyeung> @jango good, what else?
[11:39] <jango> that's pretty much it
[11:40] <jyeung> k, we're almost done. Last topic..
[11:40] <jyeung> Who is going to be the dictator for the week?
[11:41] <jyeung> @colin_m What about you?
[11:41] <colin_m> Eep. Sure.
[11:41] <jango> point of order
[11:41] <jango> who is setting up the repository for the pinax application?
[11:42] <jyeung> @colin_m will now take over. you are free to go. but you could stay for the playing of my national anthem...
[11:43] <colin_m> Oh, already?
[11:43] <colin_m> Okay, well does anyone feel familiar enough with Pinax that they'd feel comfortable volunteering to set it up in the repo?
[11:43] <jyeung> umm open discussion before that
[11:44] <janr> One comment...
[11:44] <janr> Unrelated...
[11:44] <jango> @colin_m everyone should've played with pinax/django long time ago. pick someone
[11:44] <Joel_C> the task is setting up a starter Pinax up and committing it, right?
[11:44] <_lance_> not everyone played with pinax. the spec said we could've used pinax or django. i just used django.
[11:45] <Joel_C> *Pinax app
[11:45] <colin_m> @Joel_C, correct.
[11:45] <jango> @Joel_C yes. rather posting it on the review board
[11:45] <janr> I'll be backpacking for the next two weeks, with no laptop. If anything, I'll be able to chime in on the email discussions every now and then but not much more than that.
[11:45] <jango> @janr did you let greg know?
[11:46] <colin_m> Okay, there don't seem to be any volunteers. Jango, would you mind doing it?
[11:46] <janr> I'll send him an email...
[11:46] <janr> He knew that I would be in and out all summer...
[11:46] <jango> @colin_m try again, i'd prefer someone else do it so that I can review it on the review board :P
[11:47] <colin_m> *spins wheel* Johan?
[11:47] <jharjono> ahaha sure
[11:47] <jango> this has to be done by Monday jharjono
[11:47] <jango> i will review right after you upload to the review board
[11:47] <jyeung> @jharjono I will help
[11:47] <jango> so that the front end team can start working too
[11:48] <jharjono> so a) set up the pinax starter and b) post it to review board?
[11:48] <jango> you will checkout a fresh basie repo
[11:48] <jango> you will create all necessery things for pinax app
[11:48] <jango> you will do svn add on them
[11:49] <jango> you will then do svn diff > pinax_patch.diff
[11:49] <jango> and upload that to the review board
[11:49] <jango> once it gets reviewed, you will do svn commit -m "yaaay!" :)
[11:49] <jharjono> alrighty
[11:50] <colin_m> Okay, with that done: open discussion before we adjourn?
[11:50] <mi_sa> oh
[11:50] <mi_sa> colin, you said you'd prefer the R.1 to go after the path
[11:50] <mi_sa> for diff only?
[11:51] <colin_m> Yeah, I was thinking the two revisions being diffed would go at the end.
[11:51] <mi_sa> the current format for most is /type/R#/path
[11:51] <colin_m> Even though they're revision numbers, it's a different situation from viewing a file or directory at a given revision.
[11:51] <mi_sa> sorry, /type/R#/dir/path
[11:52] <Joel_C> also, revs coming before lets us make a rev # optional
[11:52] <Joel_C> which could imply diff of latest and a specified rev #
[11:52] <Joel_C> just a thought
[11:52] <mi_sa> i was thinking of omitting head revision number in the url as well
[11:53] <mi_sa> kind of ugly
[11:53] <colin_m> That's true. I don't think the saving from that is significant though.
[11:53] <Joel_C> still, it would be more consistent to stick the path at the end
[11:54] <colin_m> My only objection would be that it seems (to me) counterintuitive.
[11:54] <Joel_C> it is a URL though, not an actual user interface
[11:55] <colin_m> Yeah, but having easily readable URLs is still a virtue.
[11:55] <colin_m> And being able to hack URLs can be nice.
[11:55] <jharjono> i have to go to a team lunch now, see you all next time!
[11:55] * jharjono (~chatzilla@nat/ibm/x-tbtippqptesaogdt) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
[11:56] <Joel_C> ultimately, if we put rev # at the end, it means it's a mandatory parameter
[11:56] <colin_m> (It's almost noon, so if you don't want to stay behind to haggle over URLs, you're free to go, unless there are other points to be discussed)
[11:57] <Joel_C> aside from that, I think our personal views on URLs just differ :)
[11:57] <colin_m> The only source browsers I could find that used Django-style URLs have revision as mandatory.
[11:57] <Joel_C> so maybe we need to look at the practical points and agree to disagree on the "philosophical" URL issues
[11:57] <colin_m> Though they do put it at the beginning.
[11:58] <colin_m> I actually have no problem with having the rev number at the beginning, but I don't know how I feel about cramming _all_ the parameters there.
[11:58] <colin_m> Especially if something like "comment search" is going to be done with Django-style URLs.
[11:58] * jango sings and dance & goes away because I don't care about URLs that much anymore
[11:58] <Joel_C> didn't Greg lay down the law
[11:58] * jango (~jango@67.55.49.87) Quit (Remote host closed the connection)
[11:59] <Joel_C> and say we were going to use a mixed Django-style and query string approach?
[11:59] <colin_m> Yep.
[11:59] <mi_sa> so the search string would come at the end with ?=
[11:59] <mi_sa> and rev # would stay at the begining
[11:59] <Joel_C> it depends
[11:59] <colin_m> I'm not arguing for query strings, I thought we were just talking about the positioning of the parameters relative to the path.
[11:59] <Joel_C> well
[11:59] <colin_m> While still using Djangoesque URLs.
[12:00] <Joel_C> I believe the Greg idea was to have things that don't affect *what* is being displayed in the query string
[12:00] <Joel_C> so... rev numbers would be in the Django-esque form
[12:00] <mi_sa> so assuming we're using query strings, would search terms be before or after the path?
[12:01] <Joel_C> query string would be for... order?
[12:01] <colin_m> I would think that the search string would be done Django-style as well. Doesn't it affect the conent?
[12:01] <Joel_C> yes
[12:01] <Joel_C> If I understand Greg
[12:01] <Joel_C> 's edict correctly
[12:01] <colin_m> Order, pagination, that's about all I can think of.
[12:01] <Joel_C> yeah
[12:02] <mi_sa> so /view-history/searchstring/dir/path
[12:02] <janr> Somehow I'd be more inclined to put search string in the querystring. :/
[12:02] <Joel_C> so, do we want a non-specified rev for the diff URL to be "latest"?
[12:02] <Joel_C> or should it be omitted?
[12:02] <Joel_C> I guess that determines if we *have* to put rev before path or not
[12:03] <colin_m> I feel like both revision numbers should be mandatory for the diff view.
[12:03] <Joel_C> what if you want to diff a specified rev and the latest?
[12:03] <Joel_C> or should you have to look that up with an API call
[12:03] <colin_m> rev1=12 rev2=tip?
[12:05] <colin_m> Incidentally, I like the idea of having revision number being mandatory for the file/directory view as well (and using something like 'tip' or 'master' as the default).
[12:05] <Joel_C> I would say that keeping the URLs in a more consistent form would be nice, since order does matter
[12:05] <mi_sa> so when comparing with latest: diff/HEAD-R.#/dir/path, OR diff/R.#/dir/path, OR diff/dir/path/HEAD-R.#
[12:05] * nduthoit (~nduthoit@74.198.28.32) has joined #basie
[12:05] <mi_sa> if we're putting search strings in front of the path, i agree with joel
[12:06] * nduthoit (~nduthoit@74.198.28.32) has left #basie
[12:06] <Joel_C> if that's how it's structured in the other URLs I think we should stick with that
[12:08] <colin_m> Isn't having parameters at the beginning a bit idiosyncratic?
[12:08] <colin_m> Like, do any other sites, Django or otherwise, do that?
[12:08] <Joel_C> isn't it how we've been doing it?
[12:08] <Joel_C> no
[12:09] <Joel_C> the example that you posted, Colin, forget the name, that used query strings for some things
[12:09] <Joel_C> it put parameters at the start
[12:09] <Joel_C> like ordering
[12:09] <colin_m> Cloud27?
[12:09] <Joel_C> (at the start, in the django clean-URL style)
[12:09] <Joel_C> yes
[12:09] <Joel_C> I believe that's the one I saw
[12:09] <colin_m> I'm looking at it now, and it looks like it doesn't.
[12:09] <Joel_C> try changing the ordering
[12:10] <Joel_C> not just searching on that search page you sent to us as a link
[12:10] <Joel_C> anyway I've got to head out to lunch with colleagues.
[12:10] * cvan (~cvan@63.245.220.240) has joined #basie
[12:10] <colin_m> Okay, bye
[12:10] <Joel_C> we can chat later or use the mailing list
[12:10] <Joel_C> if URLs still need a bit more discussion
[12:10] <Joel_C> bye
[12:10] <colin_m> Yup, clearly this horse isn't dead yet :)
[12:10] * Joel_C (~chatzilla@uc059-2.uc.utoronto.ca) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
[12:11] <mi_sa> ok i'm leaving too
[12:11] <mi_sa> bye~
[12:11] * mi_sa (~chatzilla@CPE0018f84598ad-CM001a666bf052.cpe.net.cable.rogers.com) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
[12:14] * jbalogh (~jeff@67.218.103.227) Quit (Quit: jbalogh)
[12:20] * jyeung (~chatzilla@CPE001d73111113-CM000a7366632e.cpe.net.cable.rogers.com) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401064631])
[12:31] * janr (~janr@btr189.neoplus.adsl.tpnet.pl) Quit (Remote host closed the connection)
[12:32] * jbalogh (~jeff@nat/mozilla/x-buiedtpdmsizotth) has joined #basie
[12:34] * ZeeshanQ (~zqureshi@m115-133.on.tac.net) Quit (Quit: Leaving.)
[13:19] * colin_m (~colin@whit179.ucres.utoronto.ca) Quit (Read error: Operation timed out)
[13:24] * DaveWeber (~chatzilla@nat/ibm/x-bwdlyfonrffavcjk) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20091221164558])
[14:38] * cvan (~cvan@63.245.220.240) Quit (Read error: Connection reset by peer)
[14:38] * cvan (~cvan@nat/mozilla/x-jnsuogdpgegsmyvy) has joined #basie
[14:39] * jbalogh (~jeff@nat/mozilla/x-buiedtpdmsizotth) Quit (Ping timeout: 264 seconds)
[14:44] * kasapo (~colinb@healthscapes.sage.wisc.edu) has joined #basie
[14:44] * kasapo (~colinb@healthscapes.sage.wisc.edu) Quit (Client Quit)
[14:45] * kasapo (~colinb@healthscapes.sage.wisc.edu) has joined #basie
[14:56] * hazure (~cjmuise@red-gw41.cs.toronto.edu) Quit (Remote host closed the connection)
[15:00] * hazure (~cjmuise@red-gw41.cs.toronto.edu) has joined #basie
[15:16] * hazure (~cjmuise@red-gw41.cs.toronto.edu) Quit (Quit: Leaving)
[15:35] * hazure (~cjmuise@red-gw41.cs.toronto.edu) has joined #basie
[16:22] * colin_m (~colin@whit179.ucres.utoronto.ca) has joined #basie
[16:23] * colin_m (~colin@whit179.ucres.utoronto.ca) Quit (Client Quit)
[16:47] * jbalogh (~jeff@nat/mozilla/x-yjzbjzutbzciskno) has joined #basie
[17:40] * hazure (~cjmuise@red-gw41.cs.toronto.edu) Quit (Quit: Leaving)
[20:04] * cvan (~cvan@nat/mozilla/x-jnsuogdpgegsmyvy) Quit (Quit: cvan)
[20:37] * jbalogh (~jeff@nat/mozilla/x-yjzbjzutbzciskno) Quit (Quit: jbalogh)
[20:39] * jbalogh (~jeff@nat/mozilla/x-tqcowtjzfrapqgjs) has joined #basie
[20:45] * jbalogh (~jeff@nat/mozilla/x-tqcowtjzfrapqgjs) Quit (Quit: jbalogh)
[20:59] * jbalogh (~jeff@216.239.45.19) has joined #basie
[21:00] * cvan (~cvan@c-76-102-14-98.hsd1.ca.comcast.net) has joined #basie
[21:01] * cvan_ (~cvan@c-76-102-14-98.hsd1.ca.comcast.net) has joined #basie
[21:01] * cvan (~cvan@c-76-102-14-98.hsd1.ca.comcast.net) Quit (Read error: Connection reset by peer)
[21:01] * cvan_ is now known as cvan
[21:21] * jbalogh (~jeff@216.239.45.19) Quit (Quit: jbalogh)
[21:25] * jbalogh (~jeff@67.218.103.46) has joined #basie
[22:29] * jbalogh (~jeff@67.218.103.46) Quit (Quit: jbalogh)
[22:45] * jbalogh (~jeff@c-71-202-47-205.hsd1.ca.comcast.net) has joined #basie
[23:03] * bwinton is now known as bwinton_away
These logs were automatically created by BasieBot on irc.freenode.net using the Java IRC LogBot.