The problem is the -f flag. You just want to pass the filename. -f expects an html page that it can scan links from.
You'll also need to make sure you grab the latest Djblets. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.review-board.org VMware, Inc. - http://www.vmware.com On Tue, Mar 10, 2009 at 5:04 PM, mary <ciaom...@gmail.com> wrote: > > I'm trying to use instructions in documentation for grabbing a nightly > (yes I know my fix won't be ready till later :) but I cannot get it to > work. Any suggestions? > > Here is relavent debug output from easy_install: > $ sudo easy_install -v -n -f > http://www.review-board.org/downloads/nightlies/ > ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg<http://www.review-board.org/downloads/nightlies/%0AReviewBoard-1.0alpha5.dev_20090310-py2.4.egg> > > Searching for ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg > Reading http://www.review-board.org/downloads/nightlies/ > ... > Found link: > http://www.review-board.org/downloads/nightlies/ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg > Found link: > http://www.review-board.org/downloads/nightlies/ReviewBoard-1.0alpha5.dev_20090310-py2.5.egg > Found link: > http://www.review-board.org/downloads/nightlies/django_evolution-0.0.0.tar.gz > Reading > http://pypi.python.org/simple/ReviewBoard-1.0alpha5.dev_20090310-py2.4.egg/ > Reading > http://pypi.python.org/simple/ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg/ > Couldn't find index page for 'ReviewBoard-1.0alpha5.dev_20090310- > py2.4.egg' (maybe misspelled?) > Scanning index of all packages (this may take a while) > Reading http://pypi.python.org/simple/ > No local packages or download links found for > ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg > error: Could not find suitable distribution for Requirement.parse > ('ReviewBoard-1.0alpha5.dev-20090310-py2.4.egg') > > ******************** > > I've tried various names to get the nightlies but nothing works. If I > specify jsut "ReviewBoard" it only gets the latest released Alpha4: > > > > sudo easy_install -v -n -f > http://www.review-board.org/downloads/nightlies/ > ReviewBoard > Searching for ReviewBoard > Best match: ReviewBoard 1.0alpha4 > Processing ReviewBoard-1.0alpha4-py2.4.egg > ReviewBoard 1.0alpha4 is already the active version in easy- > install.pth > Installing rb-site script to /usr/bin > > Using /usr/lib/python2.4/site-packages/ReviewBoard-1.0alpha4-py2.4.egg > Processing dependencies for ReviewBoard > Finished processing dependencies for ReviewBoard > > **** > > I suspect I'm just doing something stupid, I'm not very familiar with > Python, easy install, etc. > > Thanks! > > > On Mar 10, 4:11 pm, mary <ciaom...@gmail.com> wrote: > > Great, thanks! I will test as soon as I can. > > > > It's probable we may still have some lesser perf issues remaining even > > with this fix because it's a common enough use case here for folks to > > create comments on many, many different lines of codes in the same > > review. This should I hope bring the load time down a lot though. > > > > On Mar 10, 2:46 pm, Christian Hammond <chip...@chipx86.com> wrote: > > > > > > > > > Thanks for the detailed information. I had originally thought this was > an > > > issue browser-side with too much content in the DOM, but it's load > times of > > > fragments. > > > > > I have a patch up for review (http://reviews.review-board.org/r/757/) > that > > > you can test. I'll be testing it a bit more and then committing it, so > it > > > should be in tonight's or tomorrow's nightly. This batches together the > > > loads, so if you only have a total of, say, 5 files with comments on > them, > > > it'll only do 5 HTTP GETs, instead of the 150+ or whatever it's > currently > > > doing. Should lighten the load considerably on the client side and > server > > > side. > > > > > Christian > > > > > -- > > > Christian Hammond - chip...@chipx86.com > > > Review Board -http://www.review-board.org > > > VMware, Inc. -http://www.vmware.com > > > > > On Mon, Mar 9, 2009 at 11:28 AM, mary <ciaom...@gmail.com> wrote: > > > > > > More info regarding question #3: > > > > > > The performance problem is reproducable by creating comments on > > > > multiple different line numbers of the diff. Each line diff comment > > > > results in a seperate HTTPS GET request when the page is loaded. > These > > > > are what the GET requests look like (in FireBug): > > > > > > Firebug's log limit has been reached. %S entries not shown. > > > > Preferences > > > > GET > > > > > https://reviewboard/r/3043/reviews/5911/fragment/diff-comment/9742/?1... > > > > > > 304 Not Modified > > > > 180ms jquery-1....1.min.js (line 19) > > > > GET > > > > > https://reviewboard/r/3043/reviews/5961/fragment/diff-comment/9789/?1... > > > > > > 304 Not Modified > > > > 48ms jquery-1....1.min.js (line 19) > > > > GET > > > > > https://reviewboard/r/3043/reviews/5964/fragment/diff-comment/9792/?1... > > > > > > I think I have probably provided enough information to show the > > > > problem now. > > > > > > On Mar 9, 11:00 am, mary <ciaom...@gmail.com> wrote: > > > > > Results for question #3: > > > > > > > I createed a reviewrequest with just one review with many comments > and > > > > > it does not have the same performance issues. Additionally, in > FireBug > > > > > the review is only showing one HTTPS GET request. In this test all > the > > > > > comments and the review itself was made by just one user (myself.) > > > > > > > I will try some additional tests to provide additional information > > > > > unless you have enough information, let me know. > > > > > > > Thanks! > > > > > > > On Mar 9, 10:11 am, mary <ciaom...@gmail.com> wrote: > > > > > > > > Results for question #2: > > > > > > I installed FireBug and setup the console to show logging. I then > > > > > > brought up one of the reviews that has been a problem for us and > > > > > > showed hundreds of HTTPS GET requests for diff comments, each > taking > > > > > > about ~200-300 milliseconds. It took ~6 minutes to fully load the > > > > > > page. > > > > > > > > I then set the $("review.body").hide() and refreshed the page, > and it > > > > > > still took almost 3 minutes to load. The same HTTPS GET requests > were > > > > > > being displayed, but this time they only took ~90milliseconds and > were > > > > > > showing "304 Not Modified". > > > > > > > > This is my first use of FireBug so please advise if you'd like > more or > > > > > > different information. > > > > > > > > On Mar 6, 4:49 pm, Christian Hammond <chip...@chipx86.com> > wrote: > > > > > > > > > Thanks for the quick response. I'll be interested in seeing the > > > > results. > > > > > > > > > I'm working on code now that should address these issues > (though some > > > > > > > further decisions will be made based on #2 and #3). > > > > > > > > > Essentially, we're looking at expanding/collapsing reviews > based on > > > > the > > > > > > > following logic: > > > > > > > > > For each review: > > > > > > > If the user has a pending reply to this review, expand it. > > > > > > > Else if the user has replied to the review, and there's no > > > > further > > > > > > > activity on the review, collapse it. > > > > > > > Else If the review is newer than the latest change > description, > > > > AND it's > > > > > > > the latest review from that user, expand it. > > > > > > > Else if there's activity on the review since the latest > change > > > > > > > description and since the last time the user viewed the page, > expand > > > > it. > > > > > > > Else, collapse it. > > > > > > > > > Users can of course manually expand a review. > > > > > > > > > This should keep the number of visible reviews quite low. > Hopefully > > > > it'll be > > > > > > > the set of reviews that the user actually wants to see. The > review > > > > contents > > > > > > > won't be loaded in unless the user does expand the review, so > the > > > > page > > > > > > > should load a lot faster. > > > > > > > > > This doesn't solve the issue of one single review with many > hundreds > > > > of > > > > > > > comments, but I'm hoping that's not a common case, and that > would > > > > have to be > > > > > > > solved differently. > > > > > > > > > The the above logic seems broken to someone, please let me > know! > > > > > > > > > Christian > > > > > > > > > -- > > > > > > > Christian Hammond - chip...@chipx86.com > > > > > > > Review Board -http://www.review-board.org > > > > > > > VMware, Inc. -http://www.vmware.com > > > > > > > > > On Fri, Mar 6, 2009 at 4:37 PM, mary <ciaom...@gmail.com> > wrote: > > > > > > > > > > answers inline below... > > > > > > > > > > On Mar 6, 3:52 pm, Christian Hammond <chip...@chipx86.com> > wrote: > > > > > > > > > A couple more questions. I'm playing around with a couple > > > > possible fixes, > > > > > > > > > but need to find out more where the bottleneck is. Clearly > it's > > > > > > > > > browser-side, but the question is whether it's the fact > that > > > > there's a > > > > > > > > lot > > > > > > > > > in the DOM or whether the rendering is the slow part. > > > > > > > > > > > 1) Is the page still slow once it fully loads? > > > > > > > > > > Yes, the comment boxes that are used to write comments are > slow > > > > even > > > > > > > > after the page is fully loaded. It doesn't make sense to me, > but > > > > this > > > > > > > > is the behavior being seen by most everyone. (This is only > the case > > > > > > > > for reviews with many comments.) > > > > > > > > > > In addition to this, some folks are also complaining that the > page > > > > > > > > cannot be used until the page is fully loaded - this has not > been > > > > my > > > > > > > > experience but I wanted to pass it along too. > > > > > > > > > > Also, we are seeing these issues on reviews that have 10-20 > > > > different > > > > > > > > file diffs. Now that I mention this I will try to repro with > just > > > > one > > > > > > > > file diff to see if that makes a difference or not. > > > > > > > > > > And finally, the CPU gets pegged when these pages are > loading. > > > > > > > > > > > 2) Can you install the Firebug extension for Firefox and, > in the > > > > console, > > > > > > > > > type the following: > > > > > > > > > > > $(".review .body").hide() > > > > > > > > > > I will get back to you on this question. > > > > > > > > > > > And see if the page is now faster to interact with? (All > the > > > > reviews will > > > > > > > > be > > > > > > > > > hidden until you reload, so this is clearly not a fix by > itself, > > > > but will > > > > > > > > > tell us whether the bottleneck is the DOM or the > rendering). > > > > > > > > > > > 3) Are these comments spread across many reviews? Or does a > > > > single review > > > > > > > > > usually have enough comments to cause problems by itself? > > > > > > > > > > Yes, the comments are spread across many reviews. > > > > > > > > I will try to reproduce using a single review to provide more > > > > insight > > > > > > > > and get back to you. > > > > > > > > > > > Christian > > > > > > > > > > > -- > > > > > > > > > Christian Hammond - chip...@chipx86.com > > > > > > > > > Review Board -http://www.review-board.org > > > > > > > > > VMware, Inc. -http://www.vmware.com > > > > > > > > > > > On Fri, Mar 6, 2009 at 3:10 PM, mary <ciaom...@gmail.com> > wrote: > > > > > > > > > > > > Thank-you for making this a priority! I'll keep an eye > out for > > > > the fix > > > > > > > > > > and grab immediately. > > > > > > > > > > > > Breaking up the reviews into smaller pieces is not a use > case > > > > that is > > > > > > > > > > going down well here, but it is known. thanks again! > > > > > > > > > > > > On Mar 6, 2:54 pm, Christian Hammond < > chip...@chipx86.com> > > > > wrote: > > > > > > > > > > > We'd have to decide what we're doing to fix this first. > > > > Depending on > > > > > > > > what > > > > > > > > > > > that is, it could take a few days to implement, or > longer. We > > > > can > > > > > > > > make it > > > > > > > > > > a > > > > > > > > > > > priority for beta 1 (the next release), and of course > you'd > > > > be able > > > > > > > > to > > > > > > > > > > just > > > > > > > > > > > upgrade to a nightly once it's in. > > > > > > > > > > > > > Short-term, I'd just advise splitting up the changes > more, if > > > > > > > > possible. > > > > > > > > > > > Having smaller things to review should mean fewer > comments. > > > > > > > > > > > > > Christian > > > > > > > > > > > > > -- > > > > > > > > > > > Christian Hammond - chip...@chipx86.com > > > > > > > > > > > Review Board -http://www.review-board.org > > > > > > > > > > > VMware, Inc. -http://www.vmware.com > > > > > > > > > > > > > On Fri, Mar 6, 2009 at 2:51 PM, mary < > ciaom...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > Yes, I mean comments not reviews. > > > > > > > > > > > > > > I'm seeing the same issues on Alpha4 on my test > server. It > > > > seems to > > > > > > > > me > > > > > > > > > > > > that the loading of the diff fragments across all the > > > > comments is > > > > > > > > > > > > causing our problems - loading such a review > sometimes > > > > crashes the > > > > > > > > > > > > browser (i've seen this on firefox mostly) and in IE > the > > > > page often > > > > > > > > > > > > shows a script error popup box part way through the > load. > > > > ... > > > > read more ยป- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
