Re: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply()
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review36 --- Ship it! Wow, nice catch. I was looking for this bug earlier and didn't dream that a function like processParcelInfo would attempt to erase an entity. - Kent On 2010-12-15 11:27:50, Kitty Barnett wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > --- > > (Updated 2010-12-15 11:27:50) > > > Review request for Viewer. > > > Summary > --- > > erase() on a multimap will only invalidate iterators that point to the > element being erased so pre-incrementing the loop iterator should prevent it > from getting invalidated when an observer calls removeObserver() as part of > its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > - > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > --- > > > Thanks, > > Kitty > > ___ 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: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations
> On Jan. 5, 2011, 11:34 a.m., Oz Linden wrote: > > Just one policy question with this... > > > > This implementation uses llwarns for various errors in the glob expression. > > > > Given that I expect that the glob expression will normally (always?) be > > hard coded (I hope no one will accept a pattern as input from the user and > > pass it on unverified), should these use llerrs so that the error cannot be > > missed (it crashes)? > > > > Other than that, this looks good now. > > Seth ProductEngine wrote: > Not sure about the policy on llerrs but as far as I remember we were > trying not to overuse it, using only for fatal errors. > If someone eventually will accept a pattern as the user input this might > cause unexpected crashes, so I thought warnings would be enough to trace the > error while hard coding the patterns, though if llerrs will work better in > this case warnings could be replaced. I'd prefer to see llerrs here; there's no use case I can imagine to allow someone to manually enter globs. - Kent --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review112 --- On Jan. 5, 2011, 8:33 a.m., Seth ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > --- > > (Updated Jan. 5, 2011, 8:33 a.m.) > > > Review request for Viewer. > > > Summary > --- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching > which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other > platforms and more test cases should be provided. For example changing > directory contents while iterating through it. > > > This addresses bug STORM-477. > http://jira.secondlife.com/browse/STORM-477 > > > Diffs > - > > indra/cmake/Boost.cmake 27dae7b01a81 > indra/llvfs/CMakeLists.txt 27dae7b01a81 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > --- > > > Thanks, > > Seth > > ___ 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: STORM-830 Volume slider isn't properly remembered if set to zero
> On Jan. 6, 2011, 5:37 p.m., Aleric Inglewood wrote: > > This is really not how you want to deal with this bug :/. It's a known > > fact that audio mixers are very bad with low volumes. Setting a volume to 0 > > (or something really small) can put a very high load on the CPU for the > > audio mixer, which causes severe problems. See > > https://jira.secondlife.com/browse/VWR-14914 > > > > So, on the contrary (as VWR-14914 fixed a horrible bug that made FPS drop > > drastically): when the volume is set to 0 (or even close to zero) the audio > > channel has to be muted and not mixed, ever. Assuming that VWR-14914 is in > > Viewer 2, and wasn't broken in the meantime, a volume of 0 would cause the > > channel to be muted, but setting it to 0.01 will not cause it to be > > muted, but result in a high CPU load. > > > > Aleric Inglewood wrote: > After discussion on IRC Jonathan explained to me what this is all about. > The patch is correct. > Nevertheless, I was confused about the fact that this value of 0.01 > is never going to be USED. > Perhaps a different value and comment can avoid that in the future when > other coders look at it. > mInternalGain is only ever compared with, and the whole point of this > patch is to make sure > that the first comparison fails (I now understand). A common value used > to make sure that > a first comparison fails is a value outside the valid range of that > variable. The valid > range being [0, 1], I'd suggest using -1 and adding a comment in the > lines of: > > // Make sure that the first call to setMasterGain will cause > setInternalGain to be called. > mInternalGain = -1.f; > Aleric is correct, and if the approach is technically possible it would be preferred to use an out-of-range value. It appears to me that his suggested fix will work, but I haven't tried it myself. Jonathan, can you try it, please? - Kent --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review128 --- On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > --- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > --- > > There is an edge case in setMasterGain during startup which prevents > setInternalGain from being called if the master volume setting and > mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > - > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > --- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > ___ 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: STORM-830 Volume slider isn't properly remembered if set to zero
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/72/#review139 --- Ship it! Looks good now. - Kent On Jan. 6, 2011, 2:37 p.m., Jonathan Yap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/72/ > --- > > (Updated Jan. 6, 2011, 2:37 p.m.) > > > Review request for Viewer. > > > Summary > --- > > There is an edge case in setMasterGain during startup which prevents > setInternalGain from being called if the master volume setting and > mInternalGain both equal 0. > > Setting mInternalGain to a very low but non-zero value fixes this issue. > > > This addresses bug STORM-830. > http://jira.secondlife.com/browse/STORM-830 > > > Diffs > - > > indra/llaudio/llaudioengine.cpp 6d44f0d85a80 > > Diff: http://codereview.secondlife.com/r/72/diff > > > Testing > --- > > In Preferences / Sound & Media tested: > Buttons > Ambient > Sound Effects > Stream Music > Media > Voice Chat > > > Thanks, > > Jonathan > > ___ 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: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review141 --- Ship it! I haven't built it, but I'm presuming that since you wrote test code that it passes the tests. I love this; and it's even documented. The code looks good, and I'm really happy to have it. Thank you. - Kent On Jan. 11, 2011, 8:27 a.m., Seth ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > --- > > (Updated Jan. 11, 2011, 8:27 a.m.) > > > Review request for Viewer. > > > Summary > --- > > - Re-implemented LLDir::getNextFileInDir() as an iterator object. > - Added a class implementing directory entries iteration with pattern > matching which is used in unit tests instead of LLDir::getNextFileInDir. > - Fixed LLDir unit test which failed for some complex wildcard combinations. > - Replaced all existing usages of LLDir::getNextFileInDir() with the new > directory iterator object. > - Removed platform specific LLDir::getNextFileInDir() implementation. > > > This addresses bug STORM-477. > http://jira.secondlife.com/browse/STORM-477 > > > Diffs > - > > indra/cmake/Boost.cmake bceb13778d1d > indra/integration_tests/llui_libtest/llui_libtest.cpp bceb13778d1d > indra/linux_updater/linux_updater.cpp bceb13778d1d > indra/llvfs/CMakeLists.txt bceb13778d1d > indra/llvfs/lldir.h bceb13778d1d > indra/llvfs/lldir.cpp bceb13778d1d > indra/llvfs/lldir_linux.h bceb13778d1d > indra/llvfs/lldir_linux.cpp bceb13778d1d > indra/llvfs/lldir_mac.h bceb13778d1d > indra/llvfs/lldir_mac.cpp bceb13778d1d > indra/llvfs/lldir_solaris.h bceb13778d1d > indra/llvfs/lldir_solaris.cpp bceb13778d1d > indra/llvfs/lldir_win32.h bceb13778d1d > indra/llvfs/lldir_win32.cpp bceb13778d1d > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp bceb13778d1d > indra/newview/llappviewer.cpp bceb13778d1d > indra/newview/llappviewerlinux.cpp bceb13778d1d > indra/newview/llfloateruipreview.cpp bceb13778d1d > indra/newview/lllogchat.cpp bceb13778d1d > indra/newview/llviewermedia.cpp bceb13778d1d > indra/newview/llwaterparammanager.cpp bceb13778d1d > indra/newview/llwlparammanager.cpp bceb13778d1d > indra/viewer_components/updater/tests/llupdaterservice_test.cpp > bceb13778d1d > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > --- > > > Thanks, > > Seth > > ___ 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: VWR-24100 Settings.xml: redundant entries and unnecessary tag
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review182 --- Ship it! These changes are all reasonable. Please go ahead. - Kent On Dec. 23, 2010, 12:12 p.m., Jonathan Yap wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > --- > > (Updated Dec. 23, 2010, 12:12 p.m.) > > > Review request for Viewer. > > > Summary > --- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is > repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the > wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > - > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > --- > > > Thanks, > > Jonathan > > ___ 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: STORM-243 Suppress version change message in the viewer
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/109/#review192 --- Ship it! We've had the discussion and the change looks solid. - Kent On Jan. 18, 2011, 9:02 a.m., Vadim ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/109/ > --- > > (Updated Jan. 18, 2011, 9:02 a.m.) > > > Review request for Viewer. > > > Summary > --- > > Removed the "You just entered a region using a different server version..." > pop-up notification. > > > This addresses bug STORM-243. > http://jira.secondlife.com/browse/STORM-243 > > > Diffs > - > > indra/newview/app_settings/settings.xml 422f636c3343 > indra/newview/llviewermessage.cpp 422f636c3343 > indra/newview/skins/default/xui/da/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/de/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/en/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/es/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/fr/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/it/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/ja/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/nl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pl/notifications.xml 422f636c3343 > indra/newview/skins/default/xui/pt/notifications.xml 422f636c3343 > > Diff: http://codereview.secondlife.com/r/109/diff > > > Testing > --- > > > Thanks, > > Vadim > > ___ 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: make PREHASH variables char const* const
> On Jan. 24, 2011, 6:42 a.m., Oz Linden wrote: > > If the file is generated, what is it doing checked into the source tree at > > all? This sounds to me like an invitation to future errors. > > > > Is there some reason why we should not just delete the checked in version > > and have it generated every time it's needed? These files were generated, but the generation is a manual process and needs to take place on both the server and the viewer to ensure compatibility because this is part of a protocol definition. This is an area where we could end up breaking compatibility if we're not very careful, so please make only the changes needed to make it compile and make no semantic changes. - Kent --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/100/#review246 --- On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/100/ > --- > > (Updated Jan. 22, 2011, 7:40 a.m.) > > > Review request for Viewer and Seth ProductEngine. > > > Summary > --- > > For the reason for this change, see > https://jira.secondlife.com/browse/VWR-24487 and > https://jira.secondlife.com/browse/VWR-24522 > > What I did: > In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant > pointers to constants by search/replace. Then I tried to compile and added > const qualifiers in dependent code as needed to stop the compiler complaining. > > Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files > have been generated from the message template. Because this generation might > not have been a one-off thing, I changed the generating code, too, so it > won't override this change here when the generation happens the next time. > However, that part of the code is not called by Viewer, although the relevant > function — dump_prehash_files() — ends up in the Viewer binary. That function > probably gets called by the simulator, when one runs the latter with > -prehash. (See > https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532 > ) > > > This addresses bug VWR-24487. > http://jira.secondlife.com/browse/VWR-24487 > > > Diffs > - > > doc/contributions.txt fc7e5dcf3059 > indra/llmessage/message.cpp fc7e5dcf3059 > indra/llmessage/message_prehash.h fc7e5dcf3059 > indra/llmessage/message_prehash.cpp fc7e5dcf3059 > indra/llprimitive/llprimitive.h fc7e5dcf3059 > indra/llprimitive/llprimitive.cpp fc7e5dcf3059 > indra/llprimitive/llvolumemessage.h fc7e5dcf3059 > indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 > indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 > indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 > > Diff: http://codereview.secondlife.com/r/100/diff > > > Testing > --- > > Compiled (standalone, 64bit Linux) with and without LL_TESTS. > Started the viewer, logged in, walked and flew around a bit. Everything seems > to work. > > > Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in > indra/llui/tests/llurlentry_stub.cpp and > indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually > are never dereferenced, even when not NULL, so that using NULL pointers > instead of place holder data won't change what code paths gets tested. Both > tests binaries executed without crashes and all the contained tests passed. > > Locally invoked start_messaging_system() with b_dump_prehash_file == true > instead of FALSE, to see what would be generated after my change to > dump_prehash_files(). > The message_prehash.(h|cpp) generated by that had the correct type qualifiers > and formatting, but some lines were removed or added compared to the modified > files from the source tree. That probably means that the files aren't fully > synchronized with the message template file in the source tree. Because the > "added" constants are spread all over the file, while the "removed" ones were > at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree > are actually more up-to-date than the message template file in the source > tree. > > > Thanks, > > 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] Review Request: Use consistent path for all *.py scripts
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/129/#review286 --- I would much prefer that we put the /usr/bin/env python form, since env can find whichever python is currently set up, including someone that has it in /usr/local/bin, or wherever they've chosen. Env is more likely to be found in /usr/bin than python is. So I'd like to see this change made the opposite way. - Kent On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/129/ > --- > > (Updated Jan. 28, 2011, 5:56 p.m.) > > > Review request for Viewer. > > > Summary > --- > > Simple consistency change, using "#!/usr/bin/python" in all python script. > > > This addresses bug STORM-937. > http://jira.secondlife.com/browse/STORM-937 > > > Diffs > - > > indra/copy_win_scripts/start-client.py b542f8134a2b > indra/develop.py b542f8134a2b > indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b > indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b > indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b > indra/newview/generate_breakpad_symbols.py b542f8134a2b > scripts/build_version.py b542f8134a2b > scripts/install.py b542f8134a2b > > Diff: http://codereview.secondlife.com/r/129/diff > > > Testing > --- > > Pulled into a test repo and build successfully on all platforms on TC so I > guess no bad surprise here. > > > Thanks, > > Merov > > ___ 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: STORM-465 Missing Strings from strings.xml
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/#review307 --- So I have a couple of issues with this patch: * I'm worried about the translation impact, how these strings are used and where. Should they be localized? Should they not be localized? I find it hard to believe that we ONLY need to translate Home and End. * The "1" key is duplicated. Are there others? * I think the single-letter keys should be placed in a more useful order so that we can easily find missing items. Keyboard order (especially since keyboards differ) is not good enough. * I'm worried about the naming convention; single-letter names (ahem, yes, I know who's talking here) can be rather ambiguous. It's probably the easiest fix -- anything else may require much more extensive changes -- but I'm worried about this. Is this fix robust under localization? I haven't had time to investigate these issues yet; does someone else have the knowledge to discuss? - Kent On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/108/ > --- > > (Updated Jan. 19, 2011, 8:30 a.m.) > > > Review request for Viewer. > > > Summary > --- > > Made all keys localizable. > > > This addresses bug STORM-465. > http://jira.secondlife.com/browse/STORM-465 > > > Diffs > - > > indra/newview/skins/default/xui/en/strings.xml 38465c40c060 > > Diff: http://codereview.secondlife.com/r/108/diff > > > Testing > --- > > Tested on Linux. No keys produce the warning for me. > > > Thanks, > > Vadim > > ___ 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: STORM-465 Missing Strings from strings.xml
> On Feb. 2, 2011, 8:56 a.m., Kent Quirk wrote: > > So I have a couple of issues with this patch: > > > > * I'm worried about the translation impact, how these strings are used and > > where. Should they be localized? Should they not be localized? I find it > > hard to believe that we ONLY need to translate Home and End. > > * The "1" key is duplicated. Are there others? > > * I think the single-letter keys should be placed in a more useful order so > > that we can easily find missing items. Keyboard order (especially since > > keyboards differ) is not good enough. > > * I'm worried about the naming convention; single-letter names (ahem, yes, > > I know who's talking here) can be rather ambiguous. It's probably the > > easiest fix -- anything else may require much more extensive changes -- but > > I'm worried about this. Is this fix robust under localization? > > > > I haven't had time to investigate these issues yet; does someone else have > > the knowledge to discuss? > > > > Vadim ProductEngine wrote: > 1) AFAIU, only those keys need translation that are currrently used in > menu shortcuts (see menu_*.xml). >We don't know in advance what keys we're gonna use in future > shortcuts, so it makes sense to make them all localizable. > 2) Thanks, the "1" is indeed duplicated. Looks like a copy&paste issue. > 3) Ok, the order doesn't matter to me. I can change it if you want. > 4) I borrowed the naming style from existing code (see llkeyboard.cpp). > Moreover, we tried adding "Key_" prefix to key names for the same reasons as > you say, but had to roll that change back because it had broken translation > of older shortcuts (see comments in STORM-362). I would like to see a revised changeset please, reflecting 2 and 3. I'm happy with your responses to 1 and 4. - Kent --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/#review307 --- On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/108/ > --- > > (Updated Jan. 19, 2011, 8:30 a.m.) > > > Review request for Viewer. > > > Summary > --- > > Made all keys localizable. > > > This addresses bug STORM-465. > http://jira.secondlife.com/browse/STORM-465 > > > Diffs > - > > indra/newview/skins/default/xui/en/strings.xml 38465c40c060 > > Diff: http://codereview.secondlife.com/r/108/diff > > > Testing > --- > > Tested on Linux. No keys produce the warning for me. > > > Thanks, > > Vadim > > ___ 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: STORM-465 Missing Strings from strings.xml
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/#review318 --- Ship it! I'm happy now. :) - Kent On Feb. 3, 2011, 8:20 a.m., Vadim ProductEngine wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/108/ > --- > > (Updated Feb. 3, 2011, 8:20 a.m.) > > > Review request for Viewer. > > > Summary > --- > > Made all keys localizable. > > > This addresses bug STORM-465. > http://jira.secondlife.com/browse/STORM-465 > > > Diffs > - > > indra/newview/llmaniprotate.cpp b542f8134a2b > indra/newview/skins/default/xui/da/strings.xml b542f8134a2b > indra/newview/skins/default/xui/de/strings.xml b542f8134a2b > indra/newview/skins/default/xui/en/strings.xml b542f8134a2b > indra/newview/skins/default/xui/es/strings.xml b542f8134a2b > indra/newview/skins/default/xui/fr/strings.xml b542f8134a2b > indra/newview/skins/default/xui/it/strings.xml b542f8134a2b > indra/newview/skins/default/xui/ja/strings.xml b542f8134a2b > indra/newview/skins/default/xui/nl/strings.xml b542f8134a2b > indra/newview/skins/default/xui/pl/strings.xml b542f8134a2b > indra/newview/skins/default/xui/pt/strings.xml b542f8134a2b > > Diff: http://codereview.secondlife.com/r/108/diff > > > Testing > --- > > Tested on Linux. No keys produce the warning for me. > > > Thanks, > > Vadim > > ___ 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] nametag opacity
This was the subject of some confusion and we're still working on it. Please bear with us. Q On Dec 3, 2010, at 6:36 AM, Boroondas Gupte wrote: > On 12/03/2010 12:28 PM, Boroondas Gupte wrote: >> >> Since the recent preferences overhaul (see STORM-31 and in particular >> STORM-573) > err, STORM-583, not STORM-573 > ___ > 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] pasting into quick search
That was a bug I fixed last week. STORM-716. It seems to be fixed in both beta and viewer-development. Are you sure you're using the latest build? On Dec 6, 2010, at 7:39 PM, Erin Mallory wrote: > Can someone see if they can repo this? > On todays builds, if i click into an empty quick search bar (the one by the > L$) and attempt to paste something using control-v, it doesn't let me paste. > Instead it opens a drop box of everything ive previously searched for. > however if i right click paste or if i enter something into the box first, I > can use control v. Anyone else experiencing this? > ___ > 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] [HELP] LLFeaturemanager.cpp question
I haven't delved into this code recently, but the featuretable is now downloaded from our servers each time (so we can adjust without having to re-release the software). It does lag by one iteration, though (we've already set up the video by the time it's downloaded, so it affects the NEXT run). The online version of the table is kept pretty current. Q On Dec 17, 2010, at 9:07 PM, Trilo Byte wrote: > In the indra/newview/llfeaturemanager.cpp file, it references a featuretable > text file. > > Is this still in use? As I peruse the featuretable_mac.txt file, it appears > that no > machine/gpu-specific information exists not only for the current lineup, but > for any > Mac made in 2 1/2 years. If it is still used, I can try to work on getting > the list updated > to include settings for recent gpu's. > > (the featuretable.txt file for PC's looks similarly outdated, but I'm not > familiar enough > with that platform to be of much help in updating that list). > > Also, I'm unclear on what the renderer listings (in lines 720-755 and other > places) > refers to. Are those external driver file names, or are there renderer files > someplace within the viewer codebase repository that I'm not seeing? > > > TriloByte Zanzibar > > > On Dec 16, 2010, at 5:48 PM, Aleric Inglewood wrote: > >> In indra/newview/llfeaturemanager.cpp LLFeatureManager::loadGPUClass >> reads the file GPU_TABLE_FILENAME >> and LLFeatureManager::parseGPUTable matches >> the string 'renderer' with it. >> You could start with printing 'renderer' >> and see if it's the same on windows >> and Mac and if not find out why not. >> If on Mac it makes sense nevertheless, >> you'd have to find out why gGLManager.getRawGLString() >> isn't returning the right thing. As a work around >> you could hardcode the correct string into your viewer. >> >> On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte wrote: >>> I'm having some difficulty with the Second Life Viewer and my shiny >>> new GPU (nVidia Quadro 4000). The Mac client doesn't recognize it, >>> and gives me an error when I launch the Viewer app. >>> >>> What's worse, dynamic shadows and deferred rendering are completely >>> broken (I get the same complete system crash that ATI users get). >>> >>> However, the Windows client does not appear to have a problem >>> recognizing the card. I get no error, and I have no problem with the >>> deferred renderer or with any of the shadow settings. >>> >>> I've checked against release Viewers, Snowstorm snapshots, and the >>> Mesh Project snapshots all with the same result. Mac clients can't ID >>> or support the card, Windows clients can. >>> >>> Is there someplace I can go looking around within the Windows >>> client (and support files) to try and find what's needed to detect my >>> GPU so I can rig up Mac support? >>> >>> I'd appreciate any help/ideas >>> >>> Cheers >>> >>> TriloByte Zanzibar >>> ___ >>> 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 ___ 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] Very Strange occurrence...
So the reason that semi-plausible strings are used for these things is that they're the only strings available when we use the test floater feature from the login screen. But we should probably try not to use real names. And yes, Jonathan, these should mostly never be visible. But sometimes things happen. Q On Jan 4, 2011, at 10:37 AM, Jonathan Welch wrote: > This is actually a small symptom of a larger problem. > > The text in those xml files is supposed to be replaced by some valid > string but that does not always happen. > > I've often hovered over some object which would show it was for sale > for L$30,000 when it was not valued at that amount--a failure to > substitute in the proper value. > > The real solution to this issue would be to fix the underlaying problem. > >> Ponzu, I'm understandably very interested in finding out which xml files ... >> Thanks! > ___ > 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] storm-34
You can't see the private favorites before login, so you shouldn't expect to see the "favorite landmarks" setting during login. You can only see it after login. This is because you don't have a private prefs available until after login. Q On Jan 7, 2011, at 8:35 PM, Erin Mallory wrote: > I've been testing the storm 34 viewer on windows 7 and on windows xp. Ive > noticed its not properly keeping the preferences between when youre logged in > and logged out and that the favorites therefor are not properly showing up > for me. this started occuring after i changed the account from my cummere to > erinyse then back. now no matter what i cant get it to show the favorites > for either account at log in even though both accounts have that box > checked > > before i jira this, can anyone else repo? > one.JPG>___ > 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
[opensource-dev] STORM-243 - simulator version notifications
Hi, folks. I've just commented on STORM-243, which requests that we have Yet Another Option to allow suppression of the toast that tells you the simulator version changed when you changed to a new region. I think we should delete it entirely. Does anyone care to still get that notification, now that there are usually 3 different simulator versions live on the grid at any time? I don't mean "I can think of an obscure scenario when someone might care." I mean does anyone really need a notification about this, or can we just delete it? ___ 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] STORM-243 - simulator version notifications
Can you please explain why you care? Is there a reason why you want a notification? On Jan 18, 2011, at 10:28 AM, Lance Corrimal wrote: > Am Dienstag, 18. Januar 2011, 16:22:45 schrieb Kent Quirk (Q Linden): >> Hi, folks. I've just commented on STORM-243, which requests that we have >> Yet Another Option to allow suppression of the toast that tells you the >> simulator version changed when you changed to a new region. >> >> I think we should delete it entirely. Does anyone care to still get that >> notification, now that there are usually 3 different simulator versions >> live on the grid at any time? I don't mean "I can think of an obscure >> scenario when someone might care." I mean does anyone really need a >> notification about this, or can we just delete it? > > > on the contrary, i'm trying to port a patch from henri beauchamps cool viewer > that makes that notification more detailed, as in it tells you the version of > the sim you entered and the version of the sim you left. > > > bye, > LC > > ___ > 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] STORM-243 - simulator version notifications
Everyone wants more options. Why should this be an option? Just because you're interested in knowing the version number, do you really need a notification of it? What does that give you that checking About Second Life doesn't give you? On Jan 18, 2011, at 10:40 AM, Opensource Obscure wrote: > I guess most people on this list are personally interested in that > notification. Still, I think we're a very non-representative sample > of the whole SL userbase - especially with regards to tech details. > > Off by default, with freedom to choose would be the best; > a Debug Setting would probably be good enough (since interested > people are "techie" enough to know how to get there); > should I choose between yes/no I would say "no" - remove them as > most SL users aren't interested in that information and/or don't know > what it means. > IMO > > Opensource Obscure > > On Tue, Jan 18, 2011 at 16:22, Kent Quirk (Q Linden) > wrote: >> Hi, folks. I've just commented on STORM-243, which requests that we have Yet >> Another Option to allow suppression of the toast that tells you the >> simulator version changed when you changed to a new region. >> >> I think we should delete it entirely. Does anyone care to still get that >> notification, now that there are usually 3 different simulator versions live >> on the grid at any time? I don't mean "I can think of an obscure scenario >> when someone might care." I mean does anyone really need a notification >> about this, or can we just delete it? >> >> ___ >> 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] STORM-243 - simulator version notifications
It's not gonna be a debug setting. The information's available to put it on a HUD if you care. We're pulling the feature and simplifying the viewer. On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > Make that +2 for a debug setting > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte wrote: >> +1 for making it a debug setting (to choose whether you see notifications). >> >> The server version info would still be available in Help -> About as well as >> World -> Place Profile -> Region/Estate >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >> >> could even bury the option in the debug console... most people that would >> need to turn it on would not likely keep flipping it I would think... >> >> >> Date: Tue, 18 Jan 2011 11:32:53 -0800 >> From: os...@lindenlab.com >> To: opensource-dev@lists.secondlife.com >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> It does have use for people testing server. I'd say make it optional, more >> informative, and disabled by default. >> >> __Oskar >> >> On Tue, Jan 18, 2011 at 11:22 AM, Erin >> Mallory wrote: >> >> to rephrase, yes I like them, thought i'd rather see them on the chat >> history and have more detailed. but i can live without them if the majority >> really want to see them gone altogether. for me it helps me during certain >> testing and stuff to know when ive changed server versions but that's really >> about it. >> >> >> From: angel_of_crim...@hotmail.com >> To: missannoto...@yahoo.com; q...@lindenlab.com; >> opensource-dev@lists.secondlife.com >> Date: Tue, 18 Jan 2011 12:04:09 -0500 >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> I would also like to see the toast moved. it can be useful and would be >> more useful if it had the actual version. but i would like to see it on the >> chat history instead. in fact... it would be nice to have an option to have >> ALL remaining system notifications be optionally shown in chat history >> instead of as toasts. for one thing it would log better i think, for >> another... well toasts bother a rather significant portion of sl. those >> with some forms of epilepsy, migraines, some forms of add... to name a >> few... >> >> Erin/aka Cummere >> >> >> Date: Tue, 18 Jan 2011 08:35:01 -0800 >> From: missannoto...@yahoo.com >> To: q...@lindenlab.com; opensource-dev@lists.secondlife.com >> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >> >> Doesn't it add some minor overhead to region crossings? I don't care about >> it. The message does not say what server version you just entered so it is >> mostly an annoyance. If I need version info I know where it is. >> >> What I would like to see is region rating and a single letter server version >> code on the map without having to mouse float. >> >> >> From: Kent Quirk (Q Linden) >> >> Hi, folks. I've just commented on STORM-243, which requests that we have Yet >> Another Option to allow suppression of the toast that tells you the >> simulator version changed when you changed to a new region. >> >> I think we should delete it entirely. Does anyone care to still get that >> notification, now that there are usually 3 different simulator versions live >> on the grid at any time? I don't mean "I can think of an obscure scenario >> when someone might care." I mean does anyone really need a notification >> about this, or can we just delete it? >> >> >> >> ___ 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 >> ___ >> 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] C++ Need help to resolve stdint.h typedef conflicts between Quicktime and VS2010
Looks like there are two versions of stdint.h accessible in your build -- one in GNUCompatibility, and one in VC. I'm not sure why you're finding different ones in different order, but you want to make sure that you're using the same library search path everywhere. If your library search path includes . or .. you may need to put them late in the path so that some local version doesn't override the system version. Q On Jan 30, 2011, at 8:38 AM, Nicky Perian wrote: > media_plugin_quicktime.cpp > C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility/stdint.h(49): > error C2371: 'int_fast16_t' : redefinition; different basic types > C:\Program Files (x86)\Microsoft Visual Studio > 10.0\VC\include\stdint.h(34) : see declaration of 'int_fast16_t' > > there are more errors like these but the same header just different int's > > I have tried #include and #undef and that doesn't help. > > Need help as my C++ knowledge sucks. > > But, I m trying to improve. > > Nicky > > > ___ > 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] Prduct/Business Lead for Snowstorm
On Feb 9, 2011, at 10:37 PM, Hitomi Tiponi wrote: > Is there any news on when Snowstorm will be getting a new Product/Business > Lead (it is still listed as Esbee on the wiki) or who is dealing with such > matters in the interim? > For the time being, it's me. We'll let you know when that changes. ___ 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
[opensource-dev] A fond farewell
In case you hadn't already heard, this is one of my last emails as Q Linden. Today's my last day. It's been fun working with you all. You may see me again as a contributor. We'll see how it goes. Thanks for all of your passion. Q ___ 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] Client-side scripting in Snowglobe
This makes me sad. I've been trying to have an open discussion about some of the design issues in my office hours, specifically to understand the constraints and requirements of the community. But every office hour seems to be followed up by flames on this list and in other forums interpreting what was said in the worst possible way. I'm afraid the tone and direction of this discussion are making it impossible for us to talk about this project productively. Q On Feb 18, 2010, at 7:42 AM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add client-side > scripting to SL viewers. This has been the topic of open discussion at > several Office Hours with Lindens in SL, but that openness has not extended > to many design details --- the Firefly design process is not open to the > community. The only technical details that are being disclosed about Firefly > appear to be: > > "Scripts" are actually Mono assemblies, so that only languages that compile > to Mono will be allowed. > The programs run in a sandbox, which means that most platform resources are > not accessible to them. > > Please note that I quite like C# as a language, but the following remarks are > about Mono use in the SL viewer, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > Only a tiny fraction of the world's applications, libraries and languages > work on Mono, so client-side scripting will be unable to benefit from the > huge mountain of resources available on the Internet. This is an extremely > severe limitation, and an unnecessary restriction in the context of > client-side viewer scripting. If I want to use a locally-installed package X > from within my client-side script, I should be able to. What runs > client-side should always be our individual choice, not someone else's. > Programmers want to write client-side scripts in the language that they know > best, because that always yields the fastest progress and highest quality > results. There was a good technical reason for forcing everyone to use LSL > server-side, but there is no technical reason to impose this requirement on > all client-side scripting. It is counter-productive to force CLR > compatibility on client-side script developers when there is a simple > alternative: define a socket-based viewer API for client-side scripts > instead, hence usable from any language. > Mono runs poorly on Linux, so from being rock-solid on Linux now, the > LL-derived viewers will become second-rate on this platform. > The viewer is already extremely bloated and a memory hog. Adding a Mono > dependency will compound that horribly. > There is only one effective supplier of Mono: Novell. That is a very bad > situation to encourage and to support in the viewer. > Some parties identify other reasons for avoiding Mono in general. Without > getting into that subject at all, > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > Sandboxes by design do not allow most platform resources to be accessed, as a > security measure. This is fine and important when scripts are being > downloaded from unknown places (like Javascript in web pages), but that same > protection also means that client-side scripts would be powerless to do > useful things for us in concert with local applications, files, devices, etc. > Sandboxing client-side scripts effectively hardwires in script weakness for > no reason discussed as a requirement. > Sandboxed applications cannot be linked with user-chosen native libraries > since allowing native code breaks sandbox protection. This means no > accelerators, no extensions, and no interop with other systems since sockets > are inaccessible from any strong sandbox. This also means no evolution or > progress outside of what the sandbox designers permit. > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a community viewer, embodying > community requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are > formulated in secret. The Snowglobe community has design requirements too. > Those deserve to be examined here openly, not limiting Snowglobe to a design > that stems from Linden requirements alone. > > > Morgaine. > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the pol
Re: [opensource-dev] oh give me a break
On Mar 14, 2010, at 2:41 PM, Marine Kelley wrote: > However it is true that LL has delivered a bad message recently, by > publishing the TPV and the closed-source SL 2.0 the SAME day. The TPV burdens > us developers while freeing LL's hands, and the viewer 2.0 is going to be > adopted by newcomers, so it will eventually get a broader audience than the > rest. It could very easily be seen as competition. It looks very close to > some "fire-and-motion" technique. They suppress open-source development by > laying unbelievably heavy requirements upon the devs, while moving forward > and releasing their own viewer which is not subject to said requirements. I > do hope I'm wrong and this is not the message that LL wanted to send to us. > But one can understand why so many teeth are gritting now. > What's frustrating about this for many of the Lindens is that we as an organization pushed hard -- and Merov in particular worked nights and weekends -- to get the Snowglobe source out on the same day that beta was released, rather than waiting for our usual export process to work itself out while we figure out how to make a new source control system (mercurial) work for export. We actually believed we were doing something the community would really appreciate -- getting the source out there the same day as beta. And yet somehow that became something bad. People keep repeating that "it's closed source". Despite the negative reaction, we're still working on the export process, as Soft indicated, so that we can publish without the snowglobe patches added. I'll also soon be posting our branching strategy we've been working out for some weeks now. Sorry if it's not fast enough for some, but we've kind of been focused on getting viewer 2 out. The TPV, as has been repeatedly stated, is about protecting our servers and establishing the framework within which we can protect user content. I simply don't see what the "heavy" requirements are. We ask viewer developers for little more than good citizenship. That doesn't seem particularly burdensome. So yes, I think you're wrong about our motivations and intent. If we wanted to kill our open source market we'd simply stop publishing it, rather than creating a TPV that allows us to promote it. And considering the amount of flak we've been getting, it would be easier. And yet, we're still here. Q ___ 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] Third party viewer policy: commencement date
I'm emphatically not a lawyer and I don't speak for our legal team. But: * Legalese is a specialized language. It's not strictly English, and it's not always amenable to "common sense" interpretation. Think of lawyers as people who write code in an underspecified language for a buggy compiler, and you begin to understand why legalese is the way it is. There's a lot of law that isn't stated, but is actually implied by the context of the existing settled law. What that means is that if you're not a lawyer, you probably shouldn't be attempting to interpret legal documents -- especially not for other people. Similarly, if you're not a programmer, attempting to interpret program source code is a risky business. Programmers are especially susceptible to trying to interpret legal documents using a normal dictionary because they're logical thinkers. That doesn't always work. If you have legal questions about the implication of documents, you should ask a lawyer, not a mailing list. * Similarly, any comment by one of Linden's lawyers in this forum or any other could possibly be treated as legally binding. That also goes for Linden employees, especially those with any seniority. So you're unlikely to get further remarks or "clarifications", except general statements that don't address specific questions. The policy was revised based on comments on this list and elsewhere. That's probably a pretty good indication that Linden Lab's lawyers now think it's clear enough to state its intent and to stand up in court if they need it to. Q On Mar 21, 2010, at 12:55 PM, Carlo Wood wrote: > On Sun, Mar 21, 2010 at 05:04:58PM +0100, Tayra Dagostino wrote: >> maybe we cannot sync this isn't a restriction against development >> based on GPL, is a restriction against ability to connect LL grid with >> a 3rd party viewer... > > No it's not. If that were the case it would say "User", not "Developer". > Also, I don't read "you will not be able to connect", I read "you will > be liable for any damages". Quite a different thing. ___ 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
[opensource-dev] Wiki posting: Open Source Repository Strategy
Hi, all. I've created a draft of our repository strategy for how we will be handling open development branches at LL, and posted an annotated diagram on the wiki. https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy Questions and constructive commentary are encouraged. Since it's policy we intend to follow, please edit only for clarity. If it needs substantive tweaking, please let us do it. Thanks, Q ___ 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] Wiki posting: Open Source Repository Strategy
On Mar 22, 2010, at 9:11 AM, Boroondas Gupte wrote: > Hi Q > > thanks for illustrating the planned process. > > On 03/22/2010 04:38 AM, Kent Quirk (Q Linden) wrote: >> >> Since it's policy we intend to follow, please edit only for clarity. If it >> needs substantive tweaking, please let us do it. >> > As not everyone who might find that wiki article will be reading this mailing > list, you might want to enable stable versioning on it. That will still allow > everyone to easily edit the "draft" version while you can review changes > before you "verify" them and they go live as the "stable page". The > Documentation Team uses that for the KB part of the wiki, so Torley etc. can > probably tell you how to do it. > Thanks, I'll look into that. >> Questions and constructive commentary are encouraged. >> > about K)-N): In cases where none of planned new features require secrecy, can > viewer-release be exported to a corresponding external branch, too? > about M): Also in cases where none of planned new features require secrecy, > can private beta be skipped in favor of an earlier public beta? I imagine that we'll have more external branches than are shown there. The idea is to publish as soon as we can reasonably do so, so I think that will have the effect you're looking for. > about O): What about the inverse, can the community opt not to merge certain > features from upstream (viewer-external) into Snowglobe? The merge to Snowglobe isn't automatic -- it probably requires intelligent merging. So if that includes leaving things out, so be it. The right way to do it will probably be to undo the changesets so that it doesn't become a fork that requires constant maintenance. ___ 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] Wiki posting: Open Source Repository Strategy
At this point, our internal branches still contain proprietary libraries and parts of our server code. We have to have an explicit export process to block that. We have a team working on "source code splitup" to finish the separation of our systems into libraries, and when that's finished I believe we'll be able to do it all with hg. On Mar 22, 2010, at 8:11 AM, Aleric Inglewood wrote: > *confused* I thought that we were going to use hg, so that > commits made internally can be easilly and frequently > pushed to a public repository. Is that "viewer-public"? > > Then why is there is there still a "viewer-external" > using SVN? That kinda defeats the purpose of hg? > > I thought, and think, that snowglobe development > should also be done with hg, so we can have all > the benefits of having local repositories and > experimental branches to developer and test patches. > > > On Mon, Mar 22, 2010 at 4:38 AM, Kent Quirk (Q Linden) > wrote: > Hi, all. I've created a draft of our repository strategy for how we will be > handling open development branches at LL, and posted an annotated diagram on > the wiki. > >https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy > > Questions and constructive commentary are encouraged. Since it's policy we > intend to follow, please edit only for clarity. If it needs substantive > tweaking, please let us do it. > > Thanks, > >Q > ___ > 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] Wiki posting: Open Source Repository Strategy
On Mar 22, 2010, at 12:58 AM, Latif Khalifa wrote: > On Mon, Mar 22, 2010 at 4:38 AM, Kent Quirk (Q Linden) > wrote: >> Hi, all. I've created a draft of our repository strategy for how we will be >> handling open development branches at LL, and posted an annotated diagram on >> the wiki. >> >>https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy >> >> Questions and constructive commentary are encouraged. Since it's policy we >> intend to follow, please edit only for clarity. If it needs substantive >> tweaking, please let us do it. > > Hello Q, > > It would help me better understand this process if I put some version > numbers on it (as of this moment). viewer-public branch is the > current 2.0 viewer, viewer-release (if it exists atm) would be 2.1 and > viewer-private features that are going to be added in 2.2 and beyond. > Please correct me if my understanding is correct. > Well, this process isn't all in place at this point. We'll finish setting it up once we've shipped Viewer 2 as the official release. But assuming we've gotten to that point, then viewer-public will contain some 2.1 work, and viewer-private will also contain some 2.1 work. When we're close to releasing 2.1, we'll merge to private and create the release branch. At that point, the private branch becomes 2.2 and 2.1 development is finished on release. > Also, I think that we would need more than a single viewer-external > branch in the public svn. There should probably be branching of > viewer-external to viewer_2_0 just before we export viewer-public to > viewer-external at the point M on the diagram. You're right -- this diagram is a bit limited. I'm certain we'll have multiple branches, and we should have a place where someone can go to get the definitive source for any given release. Thanks. Q ___ 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] Can you legally agree to incomprehensible conditions?
1) The first line of my comment is that I don't speak for Linden legal. 2) What I said was that if you want to understand legalese, you should talk to a lawyer. That's it. Q On Apr 1, 2010, at 4:54 AM, Gareth Nelson wrote: > An interesting point: > If a member of staff at LL is basically saying "none of you can > comprehend this policy", then that surely means none of us can > actually consent to agree to it. > > Q - you may have just provided some "fuel" for use in any future court case > > On Thu, Apr 1, 2010 at 8:42 AM, Morgaine > wrote: >> On 21st March, Q Linden explained to us that legalese is not a language >> amenable to "common sense" interpretation, and more specifically, that >> programmers like ourselves should not expect to understand this Linden TPV >> policy document using our normal logic and our normal dictionary. I'll >> repeat his words here for clarity: >> >> >> Kent Quirk (Q Linden) q at lindenlab.com >> Sun Mar 21 10:24:13 PDT 2010 >> >> I'm emphatically not a lawyer and I don't speak for our legal team. But: >> >> Legalese is a specialized language. It's not strictly English, and it's not >> always amenable to "common sense" interpretation. Think of lawyers as people >> who write code in an underspecified language for a buggy compiler, and you >> begin to understand why legalese is the way it is. There's a lot of law that >> isn't stated, but is actually implied by the context of the existing settled >> law. What that means is that if you're not a lawyer, you probably shouldn't >> be attempting to interpret legal documents -- especially not for other >> people. Similarly, if you're not a programmer, attempting to interpret >> program source code is a risky business. Programmers are especially >> susceptible to trying to interpret legal documents using a normal dictionary >> because they're logical thinkers. That doesn't always work. If you have >> legal questions about the implication of documents, you should ask a lawyer, >> not a mailing list. >> >> Similarly, any comment by one of Linden's lawyers in this forum or any other >> could possibly be treated as legally binding. That also goes for Linden >> employees, especially those with any seniority. So you're unlikely to get >> further remarks or "clarifications", except general statements that don't >> address specific questions. The policy was revised based on comments on this >> list and elsewhere. That's probably a pretty good indication that Linden >> Lab's lawyers now think it's clear enough to state its intent and to stand >> up in court if they need it to. >> >> Q >> >> >> I've been thinking about this extraordinary post and its relationship to our >> ongoing saga about the TPV, and I fail to see how any rational person could >> agree to something unknown, except under duress. Is it even legal to be >> required to agree to the incomprehensible? Does anyone know how the law >> works in this area? >> >> The GPL license was written by FSF lawyers specifically to be understood by >> programmers, so it's no surprise that the large majority of people here >> understand it. Given that Lindens claim that they are issuing a valid GPL >> license, perhaps one might accept that at face value, and assume that GPLv2 >> clauses 6, 7, 11 and 12 remain intact and valid. Therefore there are no >> "further restrictions" imposed on SL TPV developers (clause 6), and the "NO >> WARRANTY" clause (11-12) continues to protect developers from downstream >> liability, and no "conditions are imposed on you that contradict the >> conditions of this License" thus making the license valid (clause 7). >> >> Given the forgoing, the officially incomprehensible TPV document then no >> longer matters to SL TPV developers, because their rights and freedoms and >> lack of liability are determined entirely by the GPL. (It could be no other >> way anyway, since we are told that we cannot understand the TPV.) >> >> That leaves only the matter of users of TPVs behaving responsibly when they >> use TPV clients in SL, with which I'm sure every person on this list is >> happy to agree. (Note that developers become users when they connect to SL, >> and are bound by the same requirements as users.) When users do something >> bad with a TPV client, or indeed with a Linden client, then naturally they >> are personally responsibl
[opensource-dev] Call for stability patches
Hello, folks. LL developers are busily working on the 2.1 release, which you can read about in Esbee's blog post here: http://blogs.secondlife.com/community/technology/blog/2010/05/05/on-the-road-to-viewer-21 Some of the things we're working on, as are mentioned there, are stability and performance. You can see the work going on in the viewer-external repository: https://svn.secondlife.com/svn/linden/branches/2010/viewer-external which Merov has been syncing to our internal repository on a daily basis. I'd like to ask for your help at several levels regarding the stability and performance patches: * Looking in Merov's spreadsheet: https://spreadsheets.google.com/ccc?key=0AgvC7hm5YZqcdHVXb05iTE0wTFc0bWptTW4tOTZuS3c&hl=en and posting specific issues that we should be seriously considering. We'll be doing the same, but extra opinions would be welcome. * Looking in JIRA to see if there are any neglected patches that have been contributed that we should be importing. * Any new contributions you can offer. If stability and performance conflict, stability wins. And although I know there are plenty of desired features, this isn't about that right now -- what I'm hoping for is some extra eyes on issues causing crashes or stalls or slowdowns. Please note that in all cases, we can't take patches in to the official LL viewer where the contributor hasn't signed a contribution agreement. If you just want to point us at particular JIRA entries, feel free to do so in reply to this thread. If you have new code, please go through JIRA (and post a link here!). I'll be at my usual office hours tomorrow (Wednesday) at 8 AM Pacific in Longfellow if you want to come talk about it. Thanks, Q ___ 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] Call for stability patches
Thanks, Kitty. This is great research. I've forwarded it to some internal
people who are looking at it. I've asked them to comment here when we know more.
Q
On May 25, 2010, at 1:59 PM, Kitty wrote:
> I'm not sure if anyone at LL is currently working on (or aware of) this, but
> a few of the new inventory observers are really degrading the viewer's
> performance while an inventory fetch is in progress.
>
> I narrowed it down to: LLFilteredWearableListManager, LLCOFObserver and
> LLInventoryCategoriesObserver.
>
> As far as I can tell the first two are only used by the "Edit Outfit" panel
> and the latter is used to populate the "My Outfit" tab but they're running
> even when the tabs they belong to aren't active and take a long time to
> complete to the point where I've seen decoding and processing a single
> InventoryDescendants take as long as half a second (exceptional) with 1/10th
> of a second very common.
>
> The result is that the viewer either hangs for short bursts or (for me) the
> FPS drops from 50-60fps down <10fps or even less than 1fps while inventory
> is being fetched.
>
> More worrying is the fact that the stalls seem to result in incomplete
> fetches which in turn leads to perceived inventory loss (it comes short a
> few hundred to a few thousands depending).
>
> ---
>
> There's a more subtle performance issue with inventory observers as well:
> when LLInventoryModel::updateItem() gets called there's a special case for
> callings cards created by 2.0 which calls gCacheName->get(...) with a
> callback function.
>
> Since in most cases the calling cards will belong to people on the friends
> list the names are already available and the callback executes immediately
> and calls gInventory.notifyObservers() resulting in multiple invocations of
> all inventory observers per "InventoryDescendants" message.
>
> For things like the LLInventoryPanel observer it doesn't hurt since it has
> to process all the changed UUIDs anyway, but since the three listed
> inventory observers take a long time to execute it does cause a very
> noticable stall whenever a folder with a lot of calling cards is fetched.
>
> Changing gCacheName->get(...) to
>
> if (gCacheName->getFullName(id, avatar_name))
> {
> new_item->rename(avatar_name);
> mask |= LLInventoryObserver::LABEL;
> }
> else
> {
> // Fetch the currect name
> gCacheName->get(id, FALSE,
> boost::bind(&LLViewerInventoryItem::onCallingCardNameLookup, new_item.get(),
> _1, _2, _3));
> }
>
> seems the avoid the issue (the few calling cards which do need looking up
> don't seem to cause a noticeable stall for my collection of calling cards
> anyway).
>
> ---
>
> As a practical illustration (it's log on / fetch inventory / log off without
> doing anything else):
>
> Viewer-external (only difference is enabling message stats in
> llstartup.cpp):
> 2010-05-25T16:45:54Z INFO: display_stats: FPS: 3.90 <- actively fetching
> 2010-05-25T16:46:05Z INFO: display_stats: FPS: 1.80
> 2010-05-25T16:46:15Z INFO: display_stats: FPS: 1.10
> 2010-05-25T16:46:26Z INFO: display_stats: FPS: 0.80
> ...
> 2010-05-25T16:48:36Z INFO: display_stats: FPS: 50.30 <- halted fetching (=
> normal FPS)
> 2010-05-25T16:48:46Z INFO: display_stats: FPS: 51.90
> 2010-05-25T16:48:56Z INFO: display_stats: FPS: 51.00
>
> InventoryDescendents 7088 98.816109 0.102795 0.013941
>
> It reached 30,700-ish before fetching halted to nothing (and 2 minutes of
> <10fps with moments of <1fps).
>
> Patched problematic inventory observers:
> 2010-05-25T16:59:08Z INFO: display_stats: FPS: 21.60 <- actively fetching
> 2010-05-25T16:59:18Z INFO: display_stats: FPS: 20.10
> 2010-05-25T16:59:28Z INFO: display_stats: FPS: 22.90
> ...
>
> InventoryDescendents 10586 14.404209 0.067327 0.001361
>
> Fetched all of my inventory (just under 35k so 4,000 were missed above). FPS
> is down while fetching but that's probably inevitable, and it doesn't really
> cripple use of the viewer while it's happening.
>
> ---
>
> I'm not sure if patches are useful though since there different ways to
> solve it and most of the time was just finding what was causing the problem
> in the first place (ie having "My Outfits" as an inventory view didn't cause
> any observer problems in 2.0.1 and was a lot more useful and functional - no
> way to sort outfits in subfolders as the primary "con" right now).
>
> ---
>
> Lastly something that cropped up 2-3 viewer-external commits back: it
> currently takes about 3-5 seconds to open collapse/expand the sidebar for me
> (which is more or less the time it takes for an inventory floater to open)
> now which is a little bit annoying :p. It's also something that might not
> become apparent until someone has a sizeable inventory so I wanted to bring
> that up too.
>
> (Fast timers shows that it's "Find Widgets" which is responsible)
>
> Weirdest performance issue: having the "Library" root folder expan
Re: [opensource-dev] voice morphing missing from viewer-external?
Just getting the export process together. Sorry for the delay -- it should be there today. Q On Jun 11, 2010, at 4:17 AM, Lance Corrimal wrote: > Hi, > > after seeing the 2.1 announcement on the wiki I checked out & build the > latest > viewer-external, but voice morphing is not in there (yet)... > How come? > > bye, > LC > ___ > 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
[opensource-dev] code review request
Hi, all, getting back into it a little during recovery. Can I please get a review and perhaps pull for: http://jira.secondlife.com/browse/VWR-20945 Code is here: Fix is in https://bitbucket.org/kentquirk/vwr-20945 changeset 123b6d316c16 This issue is important to our release team. Thanks! Q___ 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] esbee hour transcripts?
https://wiki.secondlife.com/wiki/User:Esbee_Linden/Office_Hours/2010-09-08 On Sep 10, 2010, at 3:59 PM, Erin Mallory wrote: > Is there a link to the transcripts of esbee's last office hour? I kinda need > them to proceed with the next phase for some of the user stories I am working > on :) > ___ > 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] Landmarks on login?
Have you got a JIRA, or better yet, a pointer to the code in question? Sounds like it's worth investigating. Q On Sep 16, 2010, at 5:51 PM, Brandon Husbands wrote: > > viewer 2, Why ohh why on log in is it grabbing all landmarks then getting > region handles for them? > > -- > --- > This email is a private and confidential communication. Any use of email may > be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > --- > --- > ___ > 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] major problem with beta 2.2
Yup, that's a genuine bug: https://jira.secondlife.com/browse/VWR-23168 We'll try to get it fixed for Beta 2. Q On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote: > As a User I expect and NEED usernames to be displayed in group chat and used > properly in group and conference chat logs. > Instead I am seeing in both chat and in logs, usernames replaced with the > group or conference name!!! > > ___ > 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] major problem with beta 2.2
On Sep 24, 2010, at 2:36 PM, Erin Mallory wrote: > As a User I expect and NEED usernames to be displayed in group chat and used > properly in group and conference chat logs. > Instead I am seeing in both chat and in logs, usernames replaced with the > group or conference name!!! > I see this in the development tip (210412) but NOT in the beta (210127). Is anyone seeing it in the beta? ___ 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
[opensource-dev] Snowstorm changes
Hello, everyone. We've had a good first few weeks of the Snowstorm team. It took a little longer than we'd hoped, but we have launched the Viewer 2 Beta for version 2.2.0, and we're continuing to move forward (new beta very soon). Much of our success in this period can be attributed to the unstinting efforts of Tofu and Aimee, who have really done amazing work in the last few weeks. We at Linden Lab made a corporate decision back in the spring to close down our entire presence in the UK; all UK-based Lindens were affected, with varying timing. This means that Tofu and Aimee will be no longer be Lindens after Thursday. Both of them have worked on my team for a long time now, and I consider them both friends as well as colleagues. Please join me in thanking them and wishing them the best in the future. They will be missed. Cheers to both, Q ___ 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] 2.0 Absolute Dealbreaker - script count feature request
On Oct 1, 2010, at 12:50 PM, Gigs wrote: > On 09/29/2010 07:06 PM, Kelly Linden wrote: >> * In my mind the biggest issue is that mono scripts will appear 4x worse >> than LSL scripts. This is really the reason I am hesitant to push a >> function like this through before we have the ability for mono scripts >> to better reflect how much memory they may use. We need more development >> time for any solution on that front. Right now because a mono script >> could use 64k, that is the only number we have available to count. Maybe >> it would be nice to have an API to access number of scripts, number of >> LSL vs. Mono scripts, amount of memory used and script time used. >> However we rapidly get away from my desired philosophy of minimal >> interfaces. > > > Don't overcomplicate things. Just count mono scripts as 16k as well. > The average size of them is less than 16k, so it's still a conservative > number. > > We don't need perfection. The person with 255 scripts in each shoe will > still show up as using a lot. Splitting hairs over kilobyte perfect > accuracy is pointless. > I don't actually have an opinion about the right answer, but I will note that if this is going to be used for things like banning people, then we can't ever change it to be something accurate later. The pattern we see is: * We build something that has a numeric limit * Someone builds something that pushes right to the limit * We change something, and the thing that used to work no longer works * People scream that we broke content So if we create a call that returns approximate results now, it *always* has to return the same results. This is one reason we are reluctant to add new measurements; people come to depend on them even when they shouldn't. Q ___ 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] Unity 3D as possible base for future (maybe even official) SL Viewers
Agreed (a day late). Teravus' post is great -- very insightful, and it mimics our own thinking. The complexity of what we render, and the fact that it's not professionally created content, means that we get all sorts of edge cases that aren't a problem in traditional graphics engines. Many systems, including Unity, put constraints on the content they'll render to achieve speed or certain effects. We don't have the same sorts of limitations, and so our engine needs to be special. I know we've had people who've evaluated Unity as well as other engines, including Ogre, and it's by no means a simple problem to figure out how to get our content into those systems without choking them. It may be possible, and one of the things I'd like to do is abstract our renderer better so that we have the ability to try a few experiments without re-implementing all of the viewer. Anyway, I guess that graphics systems are kind of like Tolstoy's unhappy families: each one sucks in its own way. It so happens that ours is designed for our content (surprise!), and our content is weird, so other engines may not be as obviously well suited to displaying it as you might think. Q On Oct 4, 2010, at 8:32 AM, Teravus Ovares wrote: > When working on IdealistViewer, I noticed that, generally, third party > 'general purpose' renderers like Irrlicht and Ogre are not well suited for > rendering objects at the quantity that SecondLife prims require. Rendering > prims /can/ be done with them, however, not at the level that can be done > with the SecondLife viewer. > > With Irrlicht, for example, the memory load of a typical 5000 prim scene runs > up against the 2GB memory limit. > > With SecondLife prims, it's more about segmenting the render data so that > only the unique things are kept and everything else is a reference to > something that was calculated before. Out of the box, Irrlicht requires > per-instance knowledge about texture, mesh buffer, face and lighting settings > configurations. This and reference/const/value type semantics used in the > engine causes far more data duplications then are necessary. > > Prims are strange for rendering. The prim's mesh result is complex in terms > of vertex count however, in a given 5000 prim scene there's on average 130 > 'unique' prim mesh. Those 130 unique mesh are duplicated with various > textures, colors, orientations and associated data to make for the entire > prim count in the region. In theory, you can manage memory reasonably well > by using a 'mesh factory' pattern where by the mesh factory keeps track of > instance counts and generates a new mesh when required. In practice, > however, the associated data makes this very difficult. In Irrlicht, the > API is such that the texture configuration data is 'stuck in with' the mesh > data object.So, to get the variability that the secondlife prim scene > requires, you're also duplicating the mesh and making small changes to the > object's visual configuration data. > > Irrlicht, like Ogre, is better optimized for a smaller number of more complex > mesh objects then a very large number of highly 'instancable' objects with > very small differences. I'd comment on the opposite of the last > statement... but I don't really know about how the SecondLife viewer works > under the hood to do so (OpenSimulator Developer). > > I don't think that this issue is going to 'go away'. In fact, introducing > mesh in the viewer is going to make that memory, speed, and instancing > balance even more difficult to maintain.The gap between the viewer and > 3rd party 'general purpose' rendering tools will narrow in both directions.. > the viewer will get better at managing arbitrary mesh and 3rd party 'general > purpose' rendering tools will be able to render secondlife scenes better > because there will be less 'prim' to render as a result of there being > arbitrary mesh. > > In either case, the future is full of interesting technical challenges.I > think in unity, like with Irrlicht, smaller, more specialized scenes will > work OK with regards to prim rendering. And, I don't think 3rd party > renderers are going to be able to come close to the capability of the > SecondLife viewer when dealing with prim. They're just not designed for the > same type of data. The object models and API just are not really appropriate > for prim. I'm not saying that it isn't worth pursuing a render plugin > architecture. I am saying, however, that given that 3rd party 'general > purpose' renderers are never going to be able to meet the SecondLife viewer's > capability in rendering prim, it probably shouldn't be very high on the > priority of things to do. > > Regards > > Teravus > > > On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands wrote: > Ive used it, and fount it blehh. I think we are failing to communicate about > our conception of what is possible a
Re: [opensource-dev] Where oh where has my rendering gone?
Well, it's not quite like that. To pull this off, you'd have to take everywhere we set a color, and set it instead to its equivalent black and white value (there's a formula that's traditionally used, although there's no "correct" way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with modifying the LLColor4 constructor to do this, but it's probably going to have some surprising results when you assign a value and don't get the same value back. Next, you'd have to filter all of the textures so that all textures are first converted to B&W before being used. That's also a troublesome task, and is likely to be slow. On certain graphics cards, you could try to convert all the pixel shaders to do a B&W conversion for each pixel before rendering, but I don't know enough about our system to know if that would catch all the useful cases or not. I hope that helps, but I'm not particularly optimistic. :/ Q On Oct 5, 2010, at 5:36 PM, malachi wrote: > Oh where oh where could it be! > > Anyone can point me in the direction of the RGB rendering system in the > client? Am thinking about making a switch for b&w output to the client. > just have no idea where to start poking this beast. > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > ___ > 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] How is the XUI part of the interface designed?
There's no GUI editor. However, there is a nice little assistance tool. From the login screen ONLY, you can invoke the GUI Preview tool by hitting alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog that you can use to display any of our dialog boxes, in two languages at once if you want. If you configure it, you can also have it open the dialog file in your text editor, and the "show rectangles" checkbox makes it easy to see which parts of the dialog have which names. If you edit a dialog, you can show and hide it, and it will reload. So you should be able to experiment with a layout rather easily; it's not a live graphical editor, but it makes it pretty easy to edit. Just realize the dialogs are not "live", and so sometimes things won't look right, or may have overlapping fields because only one of them is visible at any given time. Q On Oct 6, 2010, at 8:15 PM, Richard Nelson wrote: > Unfortunately there is no GUI editor for UI layout. We currently > hand-edit XML. A GUI editor is something I've wanted to do for a while, > and the framework is mostly in place. But it is still a pretty large task > to undertake. > > R. > > On Wed, 06 Oct 2010 17:02:26 -0700, Robert Martin > wrote: > >> On Wed, Oct 6, 2010 at 7:50 PM, Rob Nelson >> wrote: >>> There's a GUI editor, but last I checked, only LL employees and a >>> select few >>> really know how to use it; The manual is still in some LL wiki >>> somewhere. >>> >>> Rob >> >> oh really could Some Linden please put both on the public wiki >> somewhere?? >> > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > ___ > 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] opensource-dev Digest, Vol 9, Issue 27
That sort of thing is more involved, I'm afraid; you have to change the control. I don't know offhand if the XUI commit binding mechanism can be made to work with only XUI change -- I kind of doubt it. If not, you'll have to change the c++ event handlers from 4 individual event handlers to one that does all 4 things on change of the combo_box. It's probably worth some spelunking through XUI to see if there's an example of binding the combo box; if not, I bet one of the devs around here would help you write the C++ changes to make it work. Q On Oct 6, 2010, at 11:04 PM, SuezanneC Baskerville wrote: > Thanks, Kent, I'm glad I asked. > > The keystroke, by the way, appears to be Control Shift T, not Control Alt T, > on my XP system running the Development Viewer. > > I'd like to replace the Focus, Move, Edit, Create, and Land buttons with a > list, I suppose a combo_box, to save horizontal space. How does one do that? > > > -- > > Message: 7 > Date: Wed, 6 Oct 2010 22:30:51 -0400 > From: "Kent Quirk (Q Linden)" > Subject: Re: [opensource-dev] How is the XUI part of the interface >designed? > > There's no GUI editor. However, there is a nice little assistance tool. From > the login screen ONLY, you can invoke the GUI Preview tool by hitting > alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog that you can > use to display any of our dialog boxes, in two languages at once if you want. > If you configure it, you can also have it open the dialog file in your text > editor, and the "show rectangles" checkbox makes it easy to see which parts > of the dialog have which names. > > If you edit a dialog, you can show and hide it, and it will reload. So you > should be able to experiment with a layout rather easily; it's not a live > graphical editor, but it makes it pretty easy to edit. Just realize the > dialogs are not "live", and so sometimes things won't look right, or may have > overlapping fields because only one of them is visible at any given time. > >Q > > ___ > 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] Jira Issue Resolution Issue
So we've modified the JIRA system again to allow residents to reopen issues in VWR and STORM. But with power comes responsibility -- we aren't going to tolerate edit wars, and we're not going to let JIRA be a place to vent your frustrations with us or with each other. Please keep it polite. Reopening because of a mistake or a misunderstanding is reasonable, especially when accompanied by a good explanation. But reopening because you don't like a decision is a waste of everyone's time, and will result in temporary or permanent loss of JIRA access. I should note that on the Snowstorm team we're trying to aggressively prune down JIRA to actionable issues. "FIX LAG" is not a useful JIRA to us, even if you don't think we've fixed it, because it's too broad and unactionable. A summary JIRA with 3 separate problems doesn't help us track it, especially when 2 of them have been fixed. So we may close these, and we'll try to explain why. If the reason is that we can't use the issue the way it's written, then please don't reopen it, write a new and better one. Thanks for your help on this. Q On Oct 8, 2010, at 5:57 PM, Erin Mallory wrote: > yes we used to have the ability to reopen. and the person in question has > closed allot. so have others. its like they dont READ the issue before > closing. to the point i've considered aring them for a form of griefing > > > > Date: Fri, 8 Oct 2010 14:00:24 -0700 > > From: br...@slearth.com > > To: opensource-dev@lists.secondlife.com > > Subject: [opensource-dev] Jira Issue Resolution Issue > > > > As a user I would like to be able to reopen Jira issues wrongly closed by > > ignorant people who can't read, creating havok. Like this one there: > > > > Stone Tremont added a comment - 08/Oct/10 2:17 AM > > This is not a bug because you do not pay prims, avatars are payed via whole > > objects. This should be a feature request. I have a way to set different > > prices for variations in vendors, you just need to make a more advanced, > > intuitive script like mine. > > > > https://jira.secondlife.com/browse/VWR-3048 > > > > Please reopen this issue! As per Gigs Taggart's comment, its used to work.. > > It you are going to allow any kiddo to close issues, the same should true > > for reopening them, or it doesn't make any sense at all. > > > > > > ___ > > 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 ___ 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] Project-MESH viewer
So our old version of full-screen antialiasing (FSAA) was causing crashes. We have made changes to the supporting infrastructure for stability; these changes meant that some machines that used to do FSAA no longer could. We had a bug under windows that was causing the new mechanism to break. We fixed that for windows -- but we have another issue on macs. There is code in the mesh viewer that supports FSAA on macs; it's a bit big to pull over easily to viewer-development. It was my fault that I didn't realize that our fix to 2.2 didn't address macs properly until quite late in the release process. We chose to ship without the feature on Macs for this release. Macs are a small subset of our user base, and this feature only affects a subset of those users, and we felt that we should not hold up release for this issue. It's also my fault that I didn't call it out for release noting. I'm sorry about that. We do intend to restore full functioning FSAA on all capable platforms soon, hopefully with 2.3. If this affected you, I apologize. Q On Oct 20, 2010, at 3:17 AM, Trilo Byte wrote: > Big fail there, Oz. None of the machines I've tested on have working > anti-aliasing (on the Mac client), either in the subsequent developer > snapshots or the official release you guys let get out the door. > > TriloByte > > On Oct 16, 2010, at 8:01 AM, Oz Linden (Scott Lawrence) wrote: > >> On 2010-10-15 18:00, Trilo Byte wrote: >>> But on the flipside, the Project MESH viewer has working shadows for nVidia >>> GPU's on Mac (never happened before on any known config), and >>> anti-aliasing's fixed. If we could get that bit out of the mesh viewer and >>> into the 2.2 pipeline, we'd really be in great shape IMO. >> >> The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about >> the other (since I don't know which change that was). >> >> ___ >> 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 ___ 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] Tools of the trade.
We've been having this discussion internally for some time. There's a lot of friction because a) we have to update lots of developers, and b) we have to rebuild all the libraries and distribute them internally. We've been working on a tool called autobuild which will automate this process; it's almost ready. It should make it lots easier for us as well as opensource developers to get a build up and running, and will centralize the tool decisions so that we can finally upgrade fairly easily. Q On Oct 20, 2010, at 12:21 AM, Brandon Husbands wrote: > I understand that Licensing costs money but I do have a question. It is > almost 2011 That's 6 years after Visual Studio was released. > I also know there are patches floating around for cmake and various other > things that make VS2k8 compile properly. So I ask this, when is LL going to > drop vs2k5 as the "Supported" MS compiler? With c++0x Standard actually being > implimented with some methods in vs2k8 and mostly in 2k10. Is it not time to > really update our default toolset? > > At least lets get the patches in to fix 2k8, and get it officially supported. > I despise 2k5, 28k is pretty solid now. 2k10 seems to be the vista of IDE's > maybe 2k11 will be the win 7 =) Mostly due to the project based settings > instead of global IDE includes which is a PITA even with Cmake. > > Id like to get LL's response on how long are we going to be stuck with 2k5 as > the "official" compiler/ide. > > > > -- > --- > This email is a private and confidential communication. Any use of email may > be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > --- > --- > ___ > 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] Viewer-development and viewer-beta
Briefly: viewer-development is the repository for daily work, the 'trunk'. Things checked in there go into the development viewer; the expectation is that those things are ready for release -- but it doesn't always work out that way. When we want to start the release process, we pull to viewer-beta. That goes through our integration QA process; every change in beta should be approved in advance, and also pulled over to viewer-development. Sometimes it goes the other way but we're trying to minimize that. We release betas approximately weekly. When we believe we have reached release stability, we pull beta to viewer-release and ship that as an "official" viewer. That will happen about monthly. The full explanation is here: http://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy Q On Oct 26, 2010, at 2:32 PM, Ponzu wrote: > Can someone briefly summarize how these two repositories are being used. It > looks sort of like they are being kept very much in lock-step, with merges, > pushes, and pulls. > > thanks, > ponzu > > ___ > 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] Files deleted by uninstaller don't appear in Recycle Bin
Au contraire. Some people get very upset when an installer leaves any files behind that were created by the program automatically, such as log files. It's simply not true that the uninstaller shouldn't remove anything in the profile -- I have worked at multiple companies where leaving behind any breadcrumbs (anything that wasn't created by File Save) after an uninstall was considered a major bug. Now I do think we can try do better; asking about deletion is on the Snowstorm backlog. Installers are always tricky and hard to test, and very often the uninstaller comes "for free" with writing the installer. It's also specialized, platform-specific code, sometimes in a strange language, so it's not easy to find devs who want to work on it. There's work going on right now that will probably affect this, and we'll make sure this is considered. Q On Oct 27, 2010, at 7:08 AM, Argent Stonecutter wrote: > The uninstaller shouldn't remove ANYTHING in the user's profile, period. It's > not being "unclear" by removing files in the user's profile when it removes > files in the Program Files directory, it's simply doing the wrong thing. This > has been an ongoing problem for years, I suspect there's a Jira about it. ___ 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] Files deleted by uninstaller don't appear in Recycle Bin
Ok, people are quoting me without also quoting the context of the statement I was responding to, which was a categorical "never", and also not quoting what else I said, which was: > Now I do think we can try do better; asking about deletion is on the > Snowstorm backlog. > > There's work going on right now that will probably affect this, and we'll > make sure this is considered. I do agree that we shouldn't delete logs without asking, and we'll get to it, probably this quarter. I'm sorry if people misunderstood my comment. Q ___ 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] Log file names (was: Request for feedback - Preferences Cleanup)
I think the filename needs to be based on the unique account name, with any periods (.) replaced by underscore (_). The display names can change weekly, and as you note it would be much more difficult to track based on display name. Q On Nov 8, 2010, at 11:45 AM, Oz Linden (Scott Lawrence) wrote: > On 2010-11-08 11:10, Sarah (Esbee) Kuehnle wrote: >> >> Thanks again for all your feedback. I've made some updates to the design >> deck (see attached). >> >> I'm going to create subtasks underneath STORM-31 for the new preferences and >> get these updates rolling with the team! :) >> >> Cheers, >> Esbee >> >> PS - Please feel free to keep feedback coming > > On the Privacy tab, you ask "Is this a timestamp in the log or in the > filename?"... I think that once we've integrated STORM-102 (a final test > build for that is running now), we'll actually have two checkboxes there. A > new test build for that is available now (fresh off the server) at [1]. > Add timestamp > Add datestamp to log file name > The first one controls whether or not lines in the log file have timestamps > on them, and the second appends a datestamp: > For person-to-person chat, the datestamp is -MM (year and month) > For local chat, the datestamp is -MM-DD (year month and day) > One issue on STORM-102 that probably needs discussing... the present > person-to-person chat log file name is > First Last[-datestamp].txt > where First and Last are the real account names. If a person has a Display > Name set, that name is not used when constructing the file name: instead the > real first and last names for the account are used for the log file name. > The Display name does appear (followed by the userid "first.last" in parens) > in the log text content. This seems potentially confusing to me, especially > if the only name I ever use for someone is the Display Name. It seems to me > that either: > the Display Name should be used (if I remember talking to "Joe Somebody", > that's the log file name I'd be most likely to look for), which would mean > that each DN value would produce a separate log even if I had conversations > with the same user with different DNs, > or the userid (first.last) should always be used for the log file name. > [1] > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-storm-102/rev/214097/index.html ___ 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] Directory named "$(CONFIGURATION)" (was: No rule to make target)
Just a note -- since the XCode tools are free, high quality, and supported, Linden Lab is unlikely to put any significant prioritization into making other toolsets work on the mac. If someone else wants to add such support without breaking what we have, then we won't gratuitously break it, but we're probably never going to test it. Q On Nov 9, 2010, at 2:16 PM, Brad Kittenbrink (Brad Linden) wrote: > > Speaking as the author of the offending changesets (sorry!). I'd strongly > recommend buiding using the xcode generator instead of makefiles on Mac. > This is not the only place we make this assumption in our cmake scripts. > > Anyways, for now our builds pretty much assume Mac == Xcode. In theory, > that'd be good to fix, but I don't really have time to look into it now. If > there are enough people interested in this we should get a story written for > adding support for the makefile generator on mac, and then I can fill in the > details there for how it should be done. ___ 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] Upcoming depth-of-field feature
Can we please not have the "fix bugs not features" and "add missing features now" debates? We have a lot of developers, and they work in different areas, and both features and bugs are considered on our backlog and prioritized according to available resources. If you disagree with the priority of a particular issue, that is appropriate, but let's avoid the absolutes, please, and recognize that not all resources are equivalent. ___ 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
