Re: [opensource-dev] Review Request: open-2 (improved progress messages during dependency checks) and open-31 (more standardized short form option switches)
On 02/12/2011 10:13 PM, Oz Linden wrote: > (there is a failure displaying the diff for autobuild.configfile.py because > it is a one word change of the logging level for a log message added by one > of my other changes that has not yet been applied to the trunk) You should be able use the 'Parent Diff' feature to let RB know about your other changes that have "not yet been applied to the trunk", without having it mix them into the diff to review. Here's how I think the procedure will work in detail: 1. Identify a revision that is in the repo you chose when creating the review request^[1] <#footnote1> *and* present in your local repository. I will call that revision 'common_base' from here on. * If in doubt, pull from the chosen remote repository, so you'll have the tip in common and can use that as common_base. (I don't think common_base actually has to be a common ancestor of the remote's tip and the revision you want reviewed.) 2. Identify the revision that the change to be reviewed is based on. Let's call it 'begin'. 3. Save the diff from common_base to begin as parent.diff: hg diff -r common_base -r begin > parent.diff * Of course, substitute the revisions identified above for common_base and begin, respectively. 4. I'll assume you still have the diff you uploaded when creating the review. I not, get it from https://codereview.secondlife.com/r/150/diff/raw/ (or click the *Download Diff* button) * This diff should apply cleanly on the begin revision 5. On https://codereview.secondlife.com/r/150/, click *Update Diff* 6. In the *Diff* field, choose the diff you already uploaded when creating the review 7. In the *Parent Diff* field, choose the new parent.diff file 8. Click *Upload* ^[1] <#footnote1_back> In your case, the one referenced by '03_autobuild', so probably https://bitbucket.org/mani_linden/viewer-autobuild Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Forum for ATI, Apple and FBO problem
As I understand the issue, the problem is on the ATI side (possibly their implementation of OpenGL), and is not specific to Apple. On Feb 12, 2011, at 5:56 PM, Laurent Bechir wrote: > > Hello, > > Some time ago, I've opened a bug report on Apple website concerning the > problem of ATI cards with FBO which stops Mac users to use dynamic > shadows. I know they are not officials, but they work quite well with > Nvidia cards :). I've received an answer recently asking me for the full > System Profiler Report of my machine. I was wondering if accumulating > the experiences on that subject would help make the things move faster. > So I've set up a forum where mac users wanting to do it could tell their > experience with ATI card and join their full System Profiler Report with > their experience. I would then put the link to the forum in my bug > report. Do you think this could be a good idea ? > > Bug report : > > https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/24/wo/KGyze933oURhrNytyxPfAw/5.83.28.0.9 > > Forum : > > http://macati.madonie.org/ > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: open-2 (improved progress messages during dependency checks) and open-31 (more standardized short form option switches)
On 2011-02-13 6:21, Boroondas Gupte wrote: On 02/12/2011 10:13 PM, Oz Linden wrote: (there is a failure displaying the diff for autobuild.configfile.py because it is a one word change of the logging level for a log message added by one of my other changes that has not yet been applied to the trunk) You should be able use the 'Parent Diff' feature to let RB know about your other changes that have "not yet been applied to the trunk", without having it mix them into the diff to review. I think that you're correct, and suspect that your procedure is at least pretty close (I may clone it to the wiki, in fact), but I'd already spent enough of my weekend doing the fix - I didn't have the time available to experiment with a ReviewBoard feature I wasn't sure of yet. Nicky Perian said: Can this be placed as an hg changeset? I'll say Ship It in hopes a test method is forthcoming. This repo has all my pending changes (some of which have been approved and will be merged to the official repo on Monday morning): https://bitbucket.org/oz_linden/autobuild-review ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: open-2 (improved progress messages during dependency checks) and open-31 (more standardized short form option switches)
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/150/ --- (Updated Feb. 13, 2011, 5:21 a.m.) Review request for Viewer. Changes --- updated diff to include correct parent for better display fixed the use of the -V short form for --version in the source_environment subcommand (which defined it separately for some reason) Summary --- I combined open-31 into this because that change is so small and simple that it didn't seem worth a separate commit (besides, while testing the rest of this, I really wanted the short form of --verbose). open-31 changes the short form of --version to -V, so that the short form of the more commonly used --verbose can be the lower case -v, and adds -n as a short form for --dry-run (as it is used in many versions of make, and in other commands like scp and rsync). open-2 corrects the problem that (at least in the viewer build) there is a long delay during which there are no progress messages. The delay is the configure step while packages are checked, including possibly downloading, extracting, and installing them. Increasing the logging level with the --verbose or --debug switches did not increase the amount of logging during this phase. The fundamental problem proved to be that the package checks were done in recursively invoked instances of autobuild (I am guessing that the process hierarchy is autobuild->cmake->autobuild, but it could have just been autobuild calling itself directly; this fix should work regardless of the depth of the process tree). The verbosity control options were not passed through to the child processes, and since there could be some other process in between (as cmake above), it seemed more robust (and relies less on correct configuration) to pass the verbosity control to the children through the environment. The default verbosity is now read from the AUTOBUILD_LOGGING environment variable, whose contents can be --debug, --verbose, --quiet, or the one letter forms of any of those options (if the environment variable is not set, then the default value is to log warnings and worse, as before). Any of the options used on the command line override any value from the environment. Regardless of how the verbosity level is established, the environment variable AUTOBUILD_LOGGING is set for all child processes, so that if any of those (directly or indirectly) are another invocation of autobuild, then that recursive child will use the same verbosity level as the parent (unless, of course the recursive invocation uses an explicit option). It is true that this also allows the user to set a default verbosity in the shell environment, and that works, but it wasn't really the motivation for the change and I did not add anything to the documentation about it. With that change made, the options correctly controlled whether or not logging is visible during the package checking phase. However, the resulting messages had an inconsistent level of detail - some operations (such as uninstall) were very verbose, while others (some of which might take significant time) were logged only at high verbosity levels. This led to the addition of a few short log messages at the default 'warning' level (which really has the dual meaning "something that might be a problem" and "something that should be seen at the default logging level") in order to make sure that some message is printed before any potentially long operation (downloads, extracts, installs, and uninstalls). Some other very detailed messages were changed from info to debug levels, as the information they display is really only useful when debugging either a new autobuild configuration or autobuild itself. I think that the combination of these changes makes the default verbosity reasonably informative (no long silences) without being overwhelming. (there is a failure displaying the diff for autobuild.configfile.py because it is a one word change of the logging level for a log message added by one of my other changes that has not yet been applied to the trunk) This addresses bugs open-2 and open-31. Diffs (updated) - autobuild/autobuild_main.py 9ee2db08d677 autobuild/autobuild_tool_install.py 9ee2db08d677 autobuild/autobuild_tool_source_environment.py 9ee2db08d677 autobuild/common.py 9ee2db08d677 autobuild/configfile.py 9ee2db08d677 Diff: http://codereview.secondlife.com/r/150/diff Testing --- Manually verified using configuring and building in viewer-autobuild Thanks, Oz ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: open-2 (improved progress messages during dependency checks) and open-31 (more standardized short form option switches)
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/150/#review358 --- Ship it! This looks good to me. - Wolfpup On Feb. 13, 2011, 5:21 a.m., Oz Linden wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/150/ > --- > > (Updated Feb. 13, 2011, 5:21 a.m.) > > > Review request for Viewer. > > > Summary > --- > > I combined open-31 into this because that change is so small and simple that > it didn't seem worth a separate commit (besides, while testing the rest of > this, I really wanted the short form of --verbose). > > open-31 changes the short form of --version to -V, so that the short form of > the more commonly used --verbose can be the lower case -v, and adds -n as a > short form for --dry-run (as it is used in many versions of make, and in > other commands like scp and rsync). > > open-2 corrects the problem that (at least in the viewer build) there is a > long delay during which there are no progress messages. The delay is the > configure step while packages are checked, including possibly downloading, > extracting, and installing them. Increasing the logging level with the > --verbose or --debug switches did not increase the amount of logging during > this phase. > > The fundamental problem proved to be that the package checks were done in > recursively invoked instances of autobuild (I am guessing that the process > hierarchy is autobuild->cmake->autobuild, but it could have just been > autobuild calling itself directly; this fix should work regardless of the > depth of the process tree). The verbosity control options were not passed > through to the child processes, and since there could be some other process > in between (as cmake above), it seemed more robust (and relies less on > correct configuration) to pass the verbosity control to the children through > the environment. > > The default verbosity is now read from the AUTOBUILD_LOGGING environment > variable, whose contents can be --debug, --verbose, --quiet, or the one > letter forms of any of those options (if the environment variable is not set, > then the default value is to log warnings and worse, as before). Any of the > options used on the command line override any value from the environment. > Regardless of how the verbosity level is established, the environment > variable AUTOBUILD_LOGGING is set for all child processes, so that if any of > those (directly or indirectly) are another invocation of autobuild, then that > recursive child will use the same verbosity level as the parent (unless, of > course the recursive invocation uses an explicit option). It is true that > this also allows the user to set a default verbosity in the shell > environment, and that works, but it wasn't really the motivation for the > change and I did not add anything to the documentation about it. > > With that change made, the options correctly controlled whether or not > logging is visible during the package checking phase. However, the resulting > messages had an inconsistent level of detail - some operations (such as > uninstall) were very verbose, while others (some of which might take > significant time) were logged only at high verbosity levels. This led to the > addition of a few short log messages at the default 'warning' level (which > really has the dual meaning "something that might be a problem" and > "something that should be seen at the default logging level") in order to > make sure that some message is printed before any potentially long operation > (downloads, extracts, installs, and uninstalls). Some other very detailed > messages were changed from info to debug levels, as the information they > display is really only useful when debugging either a new autobuild > configuration or autobuild itself. > > I think that the combination of these changes makes the default verbosity > reasonably informative (no long silences) without being overwhelming. > > (there is a failure displaying the diff for autobuild.configfile.py because > it is a one word change of the logging level for a log message added by one > of my other changes that has not yet been applied to the trunk) > > > This addresses bugs open-2 and open-31. > > > Diffs > - > > autobuild/autobuild_main.py 9ee2db08d677 > autobuild/autobuild_tool_install.py 9ee2db08d677 > autobuild/autobuild_tool_source_environment.py 9ee2db08d677 > autobuild/common.py 9ee2db08d677 > autobuild/configfile.py 9ee2db08d677 > > Diff: http://codereview.secondlife.com/r/150/diff > > > Testing > --- > > Manually verified using configuring and building in viewer-autobuild > > >
Re: [opensource-dev] Slowdowns with Viewer 2.5.x for Linux (getting too many data?)
On Sat, Feb 12, 2011 at 14:46, leliel wrote: > If the viewer freezes for a few seconds ever time it loads a texture > then it's probably STORM-809. Thank you very much Leliel, I think it's STORM-809. Other Linux users confirmed this problem in Linux Client Users group chat. Another user created VWR-24835 that I think relates to the same problem. While I'm always on the last viewer available, I'm currently sticking with Viewer 2.4, as the impact on performances is huge. I think I had seen this in a development build I had tried, but I omitted to further investigate it...my fault. Opensource Obscure ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
