From johnniecarling at gmail.com Thu Sep 1 00:24:39 2011 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu, 1 Sep 2011 03:24:39 -0400 Subject: [opensource-dev] Current status of Mesh?? In-Reply-To: <4E5F2CF2.60306@gmail.com> References: <4E5F2CF2.60306@gmail.com> Message-ID: <201109010324.39850.johnniecarling@gmail.com> On Thursday, September 01, 2011 2:57:54 AM Tateru Nino wrote: > The fact that its UI layout is... unusual compared to most other > applications counts against it - which in itself is a lesson for us all. But Blender is much better now that they uhmmmm errrrrr... moved most of the stuff into the sidebar. ;) From slitovchuk at productengine.com Thu Sep 1 08:43:29 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 01 Sep 2011 15:43:29 -0000 Subject: [opensource-dev] Review Request: STORM-1576 Show button does not work in Inventory offer toast In-Reply-To: <20110831101857.1558.37636@domU-12-31-38-00-90-68.compute-1.internal> References: <20110831101857.1558.37636@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110901154329.1570.5992@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/455/#review1008 ----------------------------------------------------------- Ship it! - Seth On Aug. 31, 2011, 3:18 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/455/ > ----------------------------------------------------------- > > (Updated Aug. 31, 2011, 3:18 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Fixed the button index, which became invalid after removing the IOR_BUSY response in the recent fix of STORM-1543 (changeset 526d86e69101). > > > This addresses bug STORM-1576. > http://jira.secondlife.com/browse/STORM-1576 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/notifications.xml 3e6410286eef > > Diff: http://codereview.secondlife.com/r/455/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110901/8a3d33ac/attachment-0001.htm From slitovchuk at productengine.com Thu Sep 1 09:05:49 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 01 Sep 2011 16:05:49 -0000 Subject: [opensource-dev] Review Request: STORM-918 Changes in Group Role Titles or Assignments Not Reflected in Title Dropdown In-Reply-To: <20110831174358.1564.39517@domU-12-31-38-00-90-68.compute-1.internal> References: <20110831174358.1564.39517@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110901160549.1553.96562@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/461/#review1009 ----------------------------------------------------------- Ship it! Looks good to me. - Seth On Aug. 31, 2011, 10:43 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/461/ > ----------------------------------------------------------- > > (Updated Aug. 31, 2011, 10:43 a.m.) > > > Review request for Viewer and Paul ProductEngine. > > > Summary > ------- > > Changes: > - Removed a useless (empty) notifyObservers() method. > - Fixed dummy widget creation. > - Removed a redundant getChild() call. We do the same in postBuild(), which is called earlier. > - Fixing a potential bug: early return from LLGroupMgr::notifyObservers(). Just noticed it while analyzing code. > - Update role titles in the General tab whenever they change in the Roles tab. > > Only the last change is 100% relevant. Please see Bitbucket for more fine-grained change breakdown. > > > This addresses bug STORM-918. > http://jira.secondlife.com/browse/STORM-918 > > > Diffs > ----- > > indra/newview/llgroupmgr.cpp 3e6410286eef > indra/newview/llpanelgroup.h 3e6410286eef > indra/newview/llpanelgroupgeneral.h 3e6410286eef > indra/newview/llpanelgroupgeneral.cpp 3e6410286eef > indra/newview/llpanelgrouplandmoney.cpp 3e6410286eef > indra/newview/llpanelgrouproles.cpp 3e6410286eef > indra/newview/llpanelpeople.cpp 3e6410286eef > > Diff: http://codereview.secondlife.com/r/461/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110901/db87575a/attachment.htm From slitovchuk at productengine.com Thu Sep 1 09:41:49 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 01 Sep 2011 16:41:49 -0000 Subject: [opensource-dev] Review Request: STORM-1297 Clicking on Block in a dialog box from an object blocks by name In-Reply-To: <20110830172042.1566.4103@domU-12-31-38-00-90-68.compute-1.internal> References: <20110830172042.1566.4103@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110901164149.1553.40449@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/454/#review1010 ----------------------------------------------------------- Ship it! Looks good. - Seth On Aug. 30, 2011, 10:20 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/454/ > ----------------------------------------------------------- > > (Updated Aug. 30, 2011, 10:20 a.m.) > > > Review request for Viewer and Jonathan Yap. > > > Summary > ------- > > Block object inventory offer by the object's owner ID. > Also did minor changes for better code readability. > > (submitting a fix by Jonathan Yap that I have cleaned up) > > > This addresses bug STORM-1297. > http://jira.secondlife.com/browse/STORM-1297 > > > Diffs > ----- > > doc/contributions.txt 3e6410286eef > indra/newview/llviewermessage.cpp 3e6410286eef > indra/newview/skins/default/xui/en/notifications.xml 3e6410286eef > > Diff: http://codereview.secondlife.com/r/454/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110901/f9030da6/attachment.htm From sl.nicky.ml at googlemail.com Thu Sep 1 14:02:41 2011 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Thu, 1 Sep 2011 23:02:41 +0200 Subject: [opensource-dev] Mesh decomposition using hacd Message-ID: Good morning everyone, after getting GLOD in shape I continued playing with HACD and using it for mesh uploading. The current status looks promising so far. I had been able to upload a few meshes using it. For anyone interested the code for the lib can be found here: https://bitbucket.org/NickyD/convexdecompositionhacd I only used it under Linux so far. So when it comes to compiling Windows user are a bit on their own right now. For Linux you can use the following few steps after cloning and being in the convexdecompositionhacd directory. - mkdir build && cd build - cmake .. -DCMAKE_INSTALL_PREFIX=/tmp/install - make - make install Now you will end up with two libs in /tmp/install/lib (and llconvexdecomposition.h in /tmp/install/include). Copy those libs where the linker can find them. Now you want two other changesets applied to your viewer souces: 1) https://bitbucket.org/NickyD/viewer-development/changeset/cf82fc1a6683 This one will just pull the correct libs into your linker settings, 2) https://bitbucket.org/NickyD/viewer-development/changeset/1f9086200bbc That's a tricky one, because I am yet not sure if it is the correct way to solve things. The idea behind it is the viewer detecting if it is linked against HACD, if yes then it will always passed Meshes with triangles into it. HACD always wants to have triangles and vertices before it even considers computing anything. This little workaround seems to work well, but I am not sure if it is always safe to do it this way. Cheers, Nicky From wolfpup67 at earthlink.net Thu Sep 1 16:59:13 2011 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 1 Sep 2011 19:59:13 -0400 Subject: [opensource-dev] Mesh decomposition using hacd In-Reply-To: References: Message-ID: <000601cc6903$26678a80$73369f80$@net> From armin.weatherwax at googlemail.com Thu Sep 1 17:28:44 2011 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Fri, 2 Sep 2011 02:28:44 +0200 Subject: [opensource-dev] Mesh decomposition using hacd In-Reply-To: <000601cc6903$26678a80$73369f80$@net> References: <000601cc6903$26678a80$73369f80$@net> Message-ID: <201109020228.44720.Armin.Weatherwax@googlemail.com> I' ve been successfully uploading meshes on OSGrid with your library, Wolfpup, and I'm confident it will work in SL soon, too. Great work, thank you for that ! :) Armin From satomi.ahn at gmail.com Fri Sep 2 02:32:11 2011 From: satomi.ahn at gmail.com (Satomi Ahn) Date: Fri, 2 Sep 2011 11:32:11 +0200 Subject: [opensource-dev] Collaborative LSL scripting and TPV policy Message-ID: Good morning everybody! I have a question regarding TPVP and collaborative scripting in SecondLife. Several LSL projects I work on actually are a collaborative work of several scripters. Current environment in SL is far from optimal for that kind of project: - the embedded script editor is very limited (issue mitigated by the fact we can now set an external editor) - keeping track of your own script versions is pretty tedious with the functionality provided by SL inventory - keeping track of versions from other co-workers is even harder (very hard to be sure you have merged all the latest versions before you make a public release of the product) Version management in RL is usually addressed by using a VCS such as git or mercurial. But for SL, that would suppose copy/pasting scripts one by one from the viewer to local disk files before committing to the repository. Hence, both for version management and advanced editing, it would really help if all scripts from an object could just easily be exported to a local folder, then updated back from the local copy (2 buttons in the object edit floater: import and export). I know this is an old topic and that some viewers already have similar features, but I would like to make one that would exactly fit my use case and I?need to be sure this will not violate the Policy on Third Party Viewers. In particular, I want to be sure how TPVP ?2b must be interpreted: /You must not use or provide any functionality that Linden Lab?s viewers do not have for exporting content from Second Life unless the functionality verifies that the content to be exported was created by the Second Life user who is using the Third-Party Viewer./ Since the official viewer already allows: - copy/pasting any modifiable script - and opening them in an external editor, should I understand that modifiable script export is a functionality that Linden Lab's viewers already provides? Or do we really have to be the creator of the script? If the script creator restriction applies, this would be tedious but not the end of it: we would have to work on a copy of the project that was previously imported from the repository (and thus whose "creator" would be the user of the viewer), but this would preclude directly working on scripts a co-worker shared with you within SL. I assume many viewer developpers who also script must already have thought about these concerns. What is the best answer you came up with? (Note this is only about scripts. Although it would be nice if it was possible to generalize to other assets, upload costs would make it unpractical, even without considering terms of service!) Cheers, From oz at lindenlab.com Fri Sep 2 08:27:57 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 02 Sep 2011 11:27:57 -0400 Subject: [opensource-dev] STORM-280 (Chat logs should not be deleted by uninstalling) Testing help needed Message-ID: <4E60F5FD.8030905@lindenlab.com> I've posted a test viewer for STORM-280: https://jira.secondlife.com/browse/STORM-280 Chat logs should not be deleted by uninstalling/reinstalling I could use some help with testing on different versions of Windows (I don't believe that we have the problem except on Windows). There is a test plan in the issue. The build can be found from: https://wiki.secondlife.com/wiki/Downloading_test_builds#Developer_Builds From mysty.saunders at gmail.com Fri Sep 2 08:35:51 2011 From: mysty.saunders at gmail.com (Mysty Saunders) Date: Fri, 2 Sep 2011 11:35:51 -0400 Subject: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp Message-ID: Ubuntu 32 GCC 4.4 Any idea's y'all. Im pretty much clueless about programming but with dumb newbie luck I was able to compile if I changed verticesp->mV[3] = 0.f; to verticesp->mV[2] = 0.f; Compiled but particles looked bad (duh..) Any help would be great :) /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In member function ?virtual void LLVOPartGroup::getGeometry(S32, LLStrider&, LLStrider&, LLStrider&, LLStrider&, LLStrider&)?: /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: error: array subscript is above array bounds /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: error: array subscript is above array bounds -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110902/24b8922d/attachment.htm From stickman at gmail.com Fri Sep 2 09:32:10 2011 From: stickman at gmail.com (Stickman) Date: Fri, 2 Sep 2011 09:32:10 -0700 Subject: [opensource-dev] Collaborative LSL scripting and TPV policy In-Reply-To: References: Message-ID: > Current environment in SL is far from optimal for that kind of project: There are many things SL can do to improve project collaboration, not just with scripts. I can share the problems I've encountered trying to work on projects with others if the scope increases. > Version management in RL is usually addressed by using a VCS such as > git or mercurial. But for SL, that would suppose copy/pasting scripts > one by one from the viewer to local disk files before committing to > the repository. My solution to this is to use external source control and append the SVN revision number to the end of the script name. when it's copy/pasted into SL. Not optimal, but so far it gets the job done with the least confusion. > Hence, both for version management and advanced editing, it would > really help if all scripts from an object could just easily be > exported to a local folder, then updated back from the local copy (2 > buttons in the object edit floater: import and export). Yes please. > Since the official viewer already allows: > - copy/pasting any modifiable script > - and opening them in an external editor, > should I understand that modifiable script export is a functionality > that Linden Lab's viewers already provides? Or do we really have to be > the creator of the script? Policy question. Technically not an item for this list, but there is no place to ask questions like these. See also: https://jira.secondlife.com/browse/MISC-3263 Linden Lawyer should have office hours, more recently submitted to the community manager via email as per the usergroup guidelines, no response. These Jiras might also be interesting. https://jira.secondlife.com/browse/VWR-14023 (drag and drop uploading) And I could have sworn I'd created a Jira regarding a Second Life inventory version control system and even got some feedback from Nyx about it, but I can't find anything about it. Good luck! Stickman From oz at lindenlab.com Fri Sep 2 09:50:37 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 02 Sep 2011 12:50:37 -0400 Subject: [opensource-dev] Collaborative LSL scripting and TPV policy In-Reply-To: References: Message-ID: <4E61095D.1040705@lindenlab.com> On 2011-09-02 12:32, Stickman wrote: >> > Since the official viewer already allows: >> > - copy/pasting any modifiable script >> > - and opening them in an external editor, >> > should I understand that modifiable script export is a functionality >> > that Linden Lab's viewers already provides? Or do we really have to be >> > the creator of the script? > Policy question. Technically not an item for this list, but there is > no place to ask questions like these. There's nothing wrong with asking policy questions here, so long as they also relate to open source development. I'll see what I can do about getting an answer to that question (such things are rarely quick). From armin.weatherwax at googlemail.com Fri Sep 2 10:10:29 2011 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Fri, 2 Sep 2011 19:10:29 +0200 Subject: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp In-Reply-To: References: Message-ID: <201109021910.29599.Armin.Weatherwax@googlemail.com> I just came along that, too. It only happens with a release build, commit that introduced it is 4880a28422be (viewer-development). I worked around it by passing -Wno-array-bounds to the compiler (see here: https://bitbucket.org/ArminW/kokua-merge-3.0.0/changeset/f4a68595e9b6 ) for now. Hope that helps Armin > Ubuntu 32 GCC 4.4 > > Any idea's y'all. Im pretty much clueless about programming but with dumb > newbie luck I was able to compile if I changed > > verticesp->mV[3] = 0.f; > to > verticesp->mV[2] = 0.f; > > Compiled but particles looked bad (duh..) > > Any help would be great :) > > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In > member function ?virtual void LLVOPartGroup::getGeometry(S32, > LLStrider&, LLStrider&, LLStrider&, > LLStrider&, LLStrider&)?: > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: > error: array subscript is above array bounds From arrehn at gmail.com Fri Sep 2 10:32:51 2011 From: arrehn at gmail.com (Arrehn Oberlander) Date: Fri, 2 Sep 2011 13:32:51 -0400 Subject: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp In-Reply-To: References: Message-ID: The underlying code segment here needs a rewrite. This is one of the rare cases where GCC is actually complaining for a very valid reason. On Fri, Sep 2, 2011 at 11:35 AM, Mysty Saunders wrote: > Ubuntu 32 GCC 4.4 > > Any idea's y'all. Im pretty much clueless about programming but with dumb > newbie luck I was able to compile if I changed > > verticesp->mV[3] = 0.f; > to > verticesp->mV[2] = 0.f; > > Compiled but particles looked bad (duh..) > > Any help would be great :) > > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp: In > member function ?virtual void LLVOPartGroup::getGeometry(S32, > LLStrider&, LLStrider&, LLStrider&, > LLStrider&, LLStrider&)?: > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:332: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:334: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:336: > error: array subscript is above array bounds > /home/mysty/slq/viewer-development/indra/newview/llvopartgroup.cpp:338: > error: array subscript is above array bounds > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110902/e35490d7/attachment.htm From kadah.coba at gmail.com Fri Sep 2 11:15:30 2011 From: kadah.coba at gmail.com (Kadah) Date: Fri, 02 Sep 2011 11:15:30 -0700 Subject: [opensource-dev] Collaborative LSL scripting and TPV policy In-Reply-To: <4E61095D.1040705@lindenlab.com> References: <4E61095D.1040705@lindenlab.com> Message-ID: <4E611D42.4080204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/2/2011 9:50 AM, Oz Linden (Scott Lawrence) wrote: > On 2011-09-02 12:32, Stickman wrote: >>>> Since the official viewer already allows: >>>> - copy/pasting any modifiable script >>>> - and opening them in an external editor, >>>> should I understand that modifiable script export is a functionality >>>> that Linden Lab's viewers already provides? Or do we really have to be >>>> the creator of the script? >> Policy question. Technically not an item for this list, but there is >> no place to ask questions like these. > > There's nothing wrong with asking policy questions here, so long as they > also relate to open source development. > > > I'll see what I can do about getting an answer to that question (such > things are rarely quick). I would believe exporting script would fall under the same isOwner && isCreator && hasCopy && hasMod && hasTrans check for exporting any other asset. In-viewer revision control has been long time wish list item for me, for the exact same reasons, but my skill level for such things its to the level to do such myself yet. The whole copy-paste routine is extremely annoying after a while. An alternative solution would be at least a bulk upload of scripts, even single script upload would be a vast impoverishment really. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOYR1CAAoJEIdLfPRu7qE25YIH/RnEq3i7/jqN0u8Guq5GDY2X YGILrX5/euZ+C1dV62DSXGcbDLO+5iG//4+vojxfzdKE2M3Wdl6rjvHA8eelQcr4 GWSydyMNeroNSKrv4cplZw7JRkEmZaJy+hz7SDxZujStmJUjtAR7rsso8M70p+zY aSlv6E6cOEk9q7/z5M3DkMH5zyliX/0sQwZL8qUnTK5LTc90jyHnR2j8RgXPu6Pv 9hkSDak4rwbtuKe9K4aRwyzDYVG/Iq5WJ1niCInSJedqX56yHNNFcOOCeYtNtqBu fM7NxR/VD1qEBMre8KeZgN4etcnQUTRysqI7w6EK1YLdthoJ4eAJihX9OI2ZW7w= =X//E -----END PGP SIGNATURE----- From armin.weatherwax at googlemail.com Fri Sep 2 14:36:01 2011 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Fri, 2 Sep 2011 23:36:01 +0200 Subject: [opensource-dev] Build Error Linux 32 GCC 4.4 llvopartgroup.cpp In-Reply-To: References: Message-ID: <201109022336.01386.Armin.Weatherwax@googlemail.com> > The underlying code segment here needs a rewrite. This is one of the rare > cases where GCC is actually complaining for a very valid reason. /me agrees absolutely. Is there already a Jira around (I searched, but didn't find one, but that might be just bad luck)? Armin From sl.nicky.ml at googlemail.com Fri Sep 2 16:15:09 2011 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Sat, 3 Sep 2011 01:15:09 +0200 Subject: [opensource-dev] Mesh decomposition using hacd In-Reply-To: <000601cc6903$26678a80$73369f80$@net> References: <000601cc6903$26678a80$73369f80$@net> Message-ID: > I would love to test this out and see how functional it is. Please use the > above listed repositories to fork off of and make the needed changes and > keep in mind how this is having to be done and where it will hopefully end > up. > To make a long story short: I did not sign the SLV Contribution Agreement. So obviously making this compatible with a submission that cannot happen anyway is pretty low on my list of things to do. From serpentu at gmail.com Sun Sep 4 08:17:16 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Sun, 04 Sep 2011 15:17:16 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110712180752.7037.81319@domU-12-31-38-00-90-68.compute-1.internal> References: <20110712180752.7037.81319@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110904151716.10510.70255@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/ ----------------------------------------------------------- (Updated Sept. 4, 2011, 8:17 a.m.) Review request for Viewer. Summary (updated) ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs (updated) ----- doc/contributions.txt 8da01486a36a indra/newview/CMakeLists.txt 8da01486a36a indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 8da01486a36a indra/newview/lltexturectrl.cpp 8da01486a36a indra/newview/llviewertexturelist.h 8da01486a36a indra/newview/llwearable.h 8da01486a36a indra/newview/llwearable.cpp 8da01486a36a indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a Diff: http://codereview.secondlife.com/r/347/diff Testing (updated) ------- Texture/Sculptmap/Avatar Layer show. Texture/Sculptmap/Avatar Layer update. Multiple sculpties update. * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, this one is completely new, written mostly from scratch and uses different mechanisms Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110904/00edd5a7/attachment.htm From serpentu at gmail.com Sun Sep 4 08:22:58 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Sun, 04 Sep 2011 15:22:58 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110904151716.10510.70255@domU-12-31-38-00-90-68.compute-1.internal> References: <20110904151716.10510.70255@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/ ----------------------------------------------------------- (Updated Sept. 4, 2011, 8:22 a.m.) Review request for Viewer. Summary (updated) ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, this one is completely new, written mostly from scratch and uses different mechanisms ** This is strictly a review/alpha version, but i'd appreciate feedback on it before i finalize it. This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs ----- doc/contributions.txt 8da01486a36a indra/newview/CMakeLists.txt 8da01486a36a indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 8da01486a36a indra/newview/lltexturectrl.cpp 8da01486a36a indra/newview/llviewertexturelist.h 8da01486a36a indra/newview/llwearable.h 8da01486a36a indra/newview/llwearable.cpp 8da01486a36a indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a Diff: http://codereview.secondlife.com/r/347/diff Testing (updated) ------- Texture/Sculptmap/Avatar Layer show. Texture/Sculptmap/Avatar Layer update. Multiple sculpties update. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110904/6ca436ed/attachment.htm From jaeger_Reg at hotmail.com Sun Sep 4 11:21:59 2011 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Sun, 04 Sep 2011 18:21:59 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> References: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110904182159.10513.30694@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/#review1011 ----------------------------------------------------------- Looks good in my initial test. I have pushed this patch to Firestorm to get more feedback from the users. I modified the XML slightly to: 1) give more room between the radio button elements for future translations (other languages often need more room) 2) added tool tips to each selection to give more clarity 3) changed "Local" to "Computer" 4) moved the radio buttons down by 4 pixels to better align in the center of the bar (might be a FS only issue) You can see my commit at: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/32a826ff98e8 You can also pull our XML file to do a diff on from: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/file/32a826ff98e8/indra/newview/skins/default/xui/en/floater_texture_ctrl.xml You are welcome to pick up any or all of these changes - Tankmaster On Sept. 4, 2011, 8:22 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2011, 8:22 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, > this one is completely new, written mostly from scratch and uses different mechanisms > > ** This is strictly a review/alpha version, but i'd appreciate feedback on it before i finalize it. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 8da01486a36a > indra/newview/CMakeLists.txt 8da01486a36a > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 8da01486a36a > indra/newview/lltexturectrl.cpp 8da01486a36a > indra/newview/llviewertexturelist.h 8da01486a36a > indra/newview/llwearable.h 8da01486a36a > indra/newview/llwearable.cpp 8da01486a36a > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110904/06c9b033/attachment.htm From sllists at boroon.dasgupta.ch Sun Sep 4 12:26:50 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 04 Sep 2011 21:26:50 +0200 Subject: [opensource-dev] llGetGeometricCenter In-Reply-To: References: Message-ID: <4E63D0FA.8080208@boroon.dasgupta.ch> [Crossposting to scripters list, as this is a LSL topic. Tread started here .] On 08/31/2011 08:52 PM, Moriz Gupte wrote: > Hello there, > I have a question that I am putting here out of desperation because > nobody seem to know, even the very best experienced folks I could tap > into. > What exactly does llGetGeometricCenter do? SVC-6579 has allegedly equivalent LSL code as well as an explanation ("average of centers of all prims in linkset"). If that is accurate, it probably should be included in the wiki, as 'geometric center' could also mean the volume integral over all points within prims of the object or similar. > 'http://wiki.secondlife.com/wiki/LlGetGeometricCenter' > The entry on the wiki is depressing as this sentence does not mean > much to me > 'This is currently (as of 2 December 2010) different from "center" in > viewer's build tools and what llRezObject > considers as "center" of > linkset.' > > Usually an entry is meant to help out ... here we have a statement > saying what some is NOT. Well, this sentence isn't meant to be the specification, otherwise it wouldn't be in the 'Caveats' box. The specification part of the wiki entry is just "Returns the vector that is the geometric center of the object relative to the root prim." (Which, granted, isn't a much more useful explanation.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110904/33df8741/attachment.htm From oz at lindenlab.com Sun Sep 4 20:10:33 2011 From: oz at lindenlab.com (Oz Linden) Date: Mon, 05 Sep 2011 03:10:33 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> References: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110905031033.10512.61081@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/#review1012 ----------------------------------------------------------- indra/newview/lllocalbitmaps.cpp It's better to initialize member variables in the constructor initialization list: LLLocalBitmap::LLLocalBitmap(std::string filename) : mFilename(filename) , mShortName(gDirUtilp->getBaseFileName(filename, true)) , mValid(false) , mLastModified(NULL) , mLinkStatus(LS_ON) , mUpdateRetries(LL_LOCAL_UPDATE_RETRIES) { (that order should be the declaration order).... and make sure that all members are initialized. indra/newview/lllocalbitmaps.cpp I'd rather see a single return at the bottom. indra/newview/lllocalbitmaps.cpp I think that a debug level log entry here might someday come in handy, and the failure cases below should get info or warning level as appropriate indra/newview/lllocalbitmaps.cpp I'd much rather see a 'decoded' variable set here and in each of the other cases, with a single return at the bottom. indra/newview/lllocalbitmaps.cpp log an error here indra/newview/lllocalbitmaps.cpp log a warning here indra/newview/lllocalbitmaps.cpp ... then it really should be logged when it does indra/newview/lllocalbitmaps.cpp log indra/newview/lllocalbitmaps.cpp There's no reason to put block scope in a case statement unless you're going to declare something that needs to be local to that case. indra/newview/lllocalbitmaps.cpp replace the early returns with breaks, and return at the bottom. indra/newview/lllocalbitmaps.cpp I bet you can guess what I want here - Oz On Sept. 4, 2011, 8:22 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2011, 8:22 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, > this one is completely new, written mostly from scratch and uses different mechanisms > > ** This is strictly a review/alpha version, but i'd appreciate feedback on it before i finalize it. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 8da01486a36a > indra/newview/CMakeLists.txt 8da01486a36a > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 8da01486a36a > indra/newview/lltexturectrl.cpp 8da01486a36a > indra/newview/llviewertexturelist.h 8da01486a36a > indra/newview/llwearable.h 8da01486a36a > indra/newview/llwearable.cpp 8da01486a36a > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110905/02cdcc6f/attachment-0001.htm From jaeger_Reg at hotmail.com Sun Sep 4 20:16:46 2011 From: jaeger_Reg at hotmail.com (Tankmaster Finesmith) Date: Mon, 05 Sep 2011 03:16:46 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> References: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110905031646.10511.45990@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/#review1013 ----------------------------------------------------------- indra/newview/lllocalbitmaps.cpp mLastModified should be 0 in order to compile on 64bit Linux systems. Null will fail in this case. (found this out in my implementation of it on Firestorm) See http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/0431f7d7cb8c - Tankmaster On Sept. 4, 2011, 8:22 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2011, 8:22 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, > this one is completely new, written mostly from scratch and uses different mechanisms > > ** This is strictly a review/alpha version, but i'd appreciate feedback on it before i finalize it. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 8da01486a36a > indra/newview/CMakeLists.txt 8da01486a36a > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 8da01486a36a > indra/newview/lltexturectrl.cpp 8da01486a36a > indra/newview/llviewertexturelist.h 8da01486a36a > indra/newview/llwearable.h 8da01486a36a > indra/newview/llwearable.cpp 8da01486a36a > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110905/92c047b3/attachment.htm From dave at meadowlakearts.com Sun Sep 4 22:27:58 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Mon, 05 Sep 2011 00:27:58 -0500 Subject: [opensource-dev] ok wtf is this? Message-ID: <4E645DDE.2050201@meadowlakearts.com> With the latest build I keep getting an alert box for "memory pool low, some sl functions disabled to avoid crash" and sure enough I crash a couple minutes later.. but memory pool low? I've usually got over 2g of physical memory free when it hits, and the machine isnt even breaking a sweat. I dont see a ramp up in memory use that might indicate a leak, I look at the logs and I see the latest ERROR level entry is a "bad memory allocation" for a texture. Somebody who's more current with the code tell me where I should look to narrow this thing down enough to file a JIRA... From tateru.nino at gmail.com Sun Sep 4 22:53:32 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 05 Sep 2011 15:53:32 +1000 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E645DDE.2050201@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> Message-ID: <4E6463DC.8020901@gmail.com> On 5/09/2011 3:27 PM, Dave Booth wrote: > With the latest build I keep getting an alert box for "memory pool low, > some sl functions disabled to avoid crash" and sure enough I crash a > couple minutes later.. but memory pool low? I've usually got over 2g > of physical memory free when it hits, and the machine isnt even breaking > a sweat. I dont see a ramp up in memory use that might indicate a leak, > I look at the logs and I see the latest ERROR level entry is a "bad > memory allocation" for a texture. Somebody who's more current with the > code tell me where I should look to narrow this thing down enough to > file a JIRA... A "bad memory allocation" could be indicative of a corrupted heap - or of a badly fragmented heap causing an otherwise easy allocation to fail. ... after a few moments of additional reflection, it could be that the texture header data itself is corrupt, and the system thinks that it needs to make an absurdly large memory allocation. In order of likelyhood (most to least), I'd say: corrupted texture header data, corrupted heap, fragmented heap. From dave at meadowlakearts.com Sun Sep 4 23:47:33 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Mon, 05 Sep 2011 01:47:33 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E6463DC.8020901@gmail.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E6463DC.8020901@gmail.com> Message-ID: <4E647085.1060107@meadowlakearts.com> On 9/5/2011 12:53 AM, Tateru Nino wrote: > In order of likelyhood (most to least), I'd say: corrupted texture > header data, corrupted heap, fragmented heap. > After a few moments of reflection of my own, I agree with your assessment.. The question that springs to mind is why does it happen in an area where I know all the textures have been loaded successfully in previous builds without any of the three issues showing up? From tateru.nino at gmail.com Sun Sep 4 23:58:24 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 05 Sep 2011 16:58:24 +1000 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E647085.1060107@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E6463DC.8020901@gmail.com> <4E647085.1060107@meadowlakearts.com> Message-ID: <4E647310.9010306@gmail.com> On 5/09/2011 4:47 PM, Dave Booth wrote: > On 9/5/2011 12:53 AM, Tateru Nino wrote: > >> In order of likelyhood (most to least), I'd say: corrupted texture >> header data, corrupted heap, fragmented heap. >> > After a few moments of reflection of my own, I agree with your > assessment.. The question that springs to mind is why does it happen in > an area where I know all the textures have been loaded successfully in > previous builds without any of the three issues showing up? All bets are off with a heap-corruption bug. You might have clicked twice, in rapid succession, on a UI widget with a non-reentrant handler, or you might have viewed some _other_ content at some prior time during the session which caused an allocation overrun. Whatever causes the heap to mess up lays around like a time-bomb waiting for the allocator's pool manager to discover that things are "messed the hell up". Heap-corruption bugs are a pest, since there's usually little or no relation between where the app fails and where the bug _really_ is. It might even be easily reproducible - but that doesn't necessarily narrow it down any, alas. From sl.nicky.ml at googlemail.com Mon Sep 5 00:32:05 2011 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Mon, 5 Sep 2011 09:32:05 +0200 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E645DDE.2050201@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> Message-ID: Hello, > With the latest build I keep getting an alert box for "memory pool low, > some sl functions disabled to avoid crash" and sure enough I crash a > couple minutes later.. ? but memory pool low? ?I've usually got over 2g > of physical memory free when it hits, and the machine isnt even breaking > a sweat. I dont see a ramp up in memory use that might indicate a leak, > I look at the logs and I see the latest ERROR level entry is a "bad > memory allocation" for a texture. Somebody who's more current with the > code tell me where I should look to narrow this thing down enough to > file a JIRA... There is a memory pool that got enabled 4 days ago. Which could cause this problem aswell. The change is here: https://bitbucket.org/lindenlab/viewer-development/changeset/298722ecdb2e Maybe there is a bug in the Memory pool that is causing You could try disabling it in your settings and see if the error still persists. Cheers, Nicky From CronoCloud at mchsi.com Mon Sep 5 07:13:58 2011 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Mon, 5 Sep 2011 09:13:58 -0500 Subject: [opensource-dev] Anybody else see crashes similar to VWR-26729? In-Reply-To: <20110822130540.2bbcf36e.CronoCloud_mchsi.com@mchsi.com> References: <20110822130540.2bbcf36e.CronoCloud_mchsi.com@mchsi.com> Message-ID: <20110905091358.7c518843.CronoCloud_mchsi.com@mchsi.com> On Mon, 22 Aug 2011 13:05:40 -0500 "Ron Rogers Jr." wrote: > https://jira.secondlife.com/browse/VWR-26729 > > CronoCloud Decided to take some more diagnostic steps with 3.0.5 23990 and start with clean settings. (Hadn't done it yet, because changing the default settings are annoying.) That did the trick with preventing crash immediately after start. So I started changing my settings back...and it did crash...with enabling "Plugin Read Thread" which might explain the LLPlugin related error messages in the crash logs I saw. CronoCloud -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110905/2d8039aa/attachment.pgp From opensourceobscure at gmail.com Mon Sep 5 07:32:08 2011 From: opensourceobscure at gmail.com (opensourceobscure) Date: Mon, 5 Sep 2011 16:32:08 +0200 Subject: [opensource-dev] Anybody else see crashes similar to VWR-26729? In-Reply-To: <20110905091358.7c518843.CronoCloud_mchsi.com@mchsi.com> References: <20110822130540.2bbcf36e.CronoCloud_mchsi.com@mchsi.com> <20110905091358.7c518843.CronoCloud_mchsi.com@mchsi.com> Message-ID: On Mon, Sep 5, 2011 at 16:13, Ron Rogers Jr. wrote: > On Mon, 22 Aug 2011 13:05:40 -0500 > "Ron Rogers Jr." wrote: > >> https://jira.secondlife.com/browse/VWR-26729 >> >> CronoCloud > > Decided to take some more diagnostic steps with 3.0.5 23990 and start > with clean settings. ?(Hadn't done it yet, because changing the > default settings are annoying.) That did the trick with preventing > crash immediately after start. So I started changing my settings > back...and it did crash...with enabling "Plugin Read Thread" ?which by the way, I have no idea what "Plugin Read Thread" does and when/why/who should enable it. I found this answer and I wonder if it is correct: http://community.secondlife.com/t5/Technical/What-does-quot-Use-Plugin-Read-Thread-quot-on-the-Advanced-Menu/qaq-p/858437 any comment? thanks in advance.. -- Opensource Obscure https://twitter.com/oobscure https://my.secondlife.com/opensource.obscure Join this group to discuss Second Life Viewer: https://j.mp/slv2group From dave at meadowlakearts.com Mon Sep 5 08:57:05 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Mon, 05 Sep 2011 10:57:05 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: References: <4E645DDE.2050201@meadowlakearts.com> Message-ID: <4E64F151.1040606@meadowlakearts.com> On 9/5/2011 2:32 AM, Nicky D. wrote: > There is a memory pool that got enabled 4 days ago. Which could cause > this problem aswell. > > The change is here: > https://bitbucket.org/lindenlab/viewer-development/changeset/298722ecdb2e > oh yeah, that's an "aha!" moment for sure.. Thanks, Nicky. Checking the "changes since last good" on the download page there it is on build 239990, the most recent, which correlates exactly with when I started to see this failure mode. If switching it off means I dont crash at all tonight then I'll leave a little gift on JIRA for the kindly folks at the lab to discover after their long weekend :) Dave. From tateru.nino at gmail.com Mon Sep 5 09:14:28 2011 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 06 Sep 2011 02:14:28 +1000 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E64F151.1040606@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> Message-ID: <4E64F564.8050407@gmail.com> On 6/09/2011 1:57 AM, Dave Booth wrote: > On 9/5/2011 2:32 AM, Nicky D. wrote: > >> There is a memory pool that got enabled 4 days ago. Which could cause >> this problem aswell. >> >> The change is here: >> https://bitbucket.org/lindenlab/viewer-development/changeset/298722ecdb2e >> > oh yeah, that's an "aha!" moment for sure.. Thanks, Nicky. > > Checking the "changes since last good" on the download page there it is > on build 239990, the most recent, which correlates exactly with when I > started to see this failure mode. If switching it off means I dont crash > at all tonight then I'll leave a little gift on JIRA for the kindly > folks at the lab to discover after their long weekend :) > Indeedy. An excellent catch. If it _is_ the memory pool, though, it is hard to figure out why unit-testing didn't catch the underlying fault. From dave at meadowlakearts.com Mon Sep 5 09:32:01 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Mon, 05 Sep 2011 11:32:01 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E64F564.8050407@gmail.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com> Message-ID: <4E64F981.5000701@meadowlakearts.com> On 9/5/2011 11:14 AM, Tateru Nino wrote: > > Indeedy. An excellent catch. If it _is_ the memory pool, though, it is > hard to figure out why unit-testing didn't catch the underlying fault. At a guess, and this is total speculation because I havent done any side by side test runs with the setting on and off yet followed by spelunking through the logs, I suspect that the easiest way to escape notice in the unit tests is if it's a flaw elsewhere that was masked by not using the memory pool - unit tests could easily not catch that, things like that usually show up in integration testing and UAT and well, that's what folks like me are for isn't it - pulling a new build every day and spending time inworld with it to see what breaks :) From jhwelch at gmail.com Mon Sep 5 10:22:07 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 5 Sep 2011 13:22:07 -0400 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E64F981.5000701@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com> <4E64F981.5000701@meadowlakearts.com> Message-ID: A good way to follow what is happening in viewer-development is to subscribe to the commit mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/viewer-development-commits On Mon, Sep 5, 2011 at 12:32 PM, Dave Booth wrote: > On 9/5/2011 11:14 AM, Tateru Nino wrote: >> >> Indeedy. An excellent catch. If it _is_ the memory pool, though, it is >> hard to figure out why unit-testing didn't catch the underlying fault. > > At a guess, and this is total speculation because I havent done any side > by side test runs with the setting on and off yet followed by spelunking > through the logs, I suspect that the easiest way to escape notice in the > unit tests is if it's a flaw elsewhere that was masked by not using the > memory pool - unit tests could easily not catch that, things like that > usually show up in integration testing and UAT and well, that's what > folks like me are for isn't it - pulling a new build every day and > spending time inworld with it to see what breaks :) > _______________________________________________ > 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 > From jhwelch at gmail.com Mon Sep 5 11:20:17 2011 From: jhwelch at gmail.com (Jonathan Welch) Date: Mon, 5 Sep 2011 14:20:17 -0400 Subject: [opensource-dev] Feedback wanted for VWR-26858 (User-defined build icons) Message-ID: Partly to solve a lack of new icon space needed by Storm-49 and partly to improve in-world building I have created VWR-26858 (https://jira.secondlife.com/browse/VWR-26858) and would appreciate your comments on this proposed new feature I would like to work on. Oz and Esbee might appreciate a few "this is a good idea" comments to convince them that yes, it is a good idea, and I would appreciate any comments of technical changes you can think of. -Jonathan From sllists at boroon.dasgupta.ch Mon Sep 5 12:07:21 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 05 Sep 2011 21:07:21 +0200 Subject: [opensource-dev] Feedback wanted for VWR-26858 (User-defined build icons) In-Reply-To: References: Message-ID: <4E651DE9.3040806@boroon.dasgupta.ch> On 09/05/2011 08:20 PM, Jonathan Welch wrote: > Partly to solve a lack of new icon space needed by Storm-49 and partly > to improve in-world building I have created VWR-26858 > (https://jira.secondlife.com/browse/VWR-26858) and would appreciate > your comments on this proposed new feature I would like to work on. > > Oz and Esbee might appreciate a few "this is a good idea" comments to > convince them that yes, it is a good idea, and I would appreciate any > comments of technical changes you can think of. It would probably be good to ask the target audience (i.e. SL builders) about this feature request. I don know where to best reach them, but I think there's one or several forums on the SL community platform dedicated to inworld content creation. Cheers, Boroondas From sllists at boroon.dasgupta.ch Mon Sep 5 12:35:51 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 05 Sep 2011 19:35:51 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110905031646.10511.45990@domU-12-31-38-00-90-68.compute-1.internal> References: <20110905031646.10511.45990@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110905193551.10512.93898@domU-12-31-38-00-90-68.compute-1.internal> > On Sept. 4, 2011, 8:16 p.m., Tankmaster Finesmith wrote: > > indra/newview/lllocalbitmaps.cpp, line 83 > > > > > > mLastModified should be 0 in order to compile on 64bit Linux systems. Null will fail in this case. (found this out in my implementation of it on Firestorm) See http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/0431f7d7cb8c Hu. What would 0 or NULL mean here, anyway? This isn't a pointer, is it? - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/#review1013 ----------------------------------------------------------- On Sept. 4, 2011, 8:22 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2011, 8:22 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, > this one is completely new, written mostly from scratch and uses different mechanisms > > ** This is strictly a review/alpha version, but i'd appreciate feedback on it before i finalize it. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 8da01486a36a > indra/newview/CMakeLists.txt 8da01486a36a > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 8da01486a36a > indra/newview/lltexturectrl.cpp 8da01486a36a > indra/newview/llviewertexturelist.h 8da01486a36a > indra/newview/llwearable.h 8da01486a36a > indra/newview/llwearable.cpp 8da01486a36a > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110905/1505728d/attachment.htm From sllists at boroon.dasgupta.ch Mon Sep 5 12:39:48 2011 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 05 Sep 2011 19:39:48 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110905031646.10511.45990@domU-12-31-38-00-90-68.compute-1.internal> References: <20110905031646.10511.45990@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110905193948.11181.46212@domU-12-31-38-00-90-68.compute-1.internal> > On Sept. 4, 2011, 8:16 p.m., Tankmaster Finesmith wrote: > > indra/newview/lllocalbitmaps.cpp, line 83 > > > > > > mLastModified should be 0 in order to compile on 64bit Linux systems. Null will fail in this case. (found this out in my implementation of it on Firestorm) See http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/0431f7d7cb8c > > Boroondas Gupte wrote: > Hu. What would 0 or NULL mean here, anyway? This isn't a pointer, is it? Never mind, I missed that the LLSD class has an overridden operator=(Integer v). - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/#review1013 ----------------------------------------------------------- On Sept. 4, 2011, 8:22 a.m., Vaalith Jinn wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/347/ > ----------------------------------------------------------- > > (Updated Sept. 4, 2011, 8:22 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) > have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. > > This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). > > * Only tested this myself, as opposed to the previous implementation which has been live for, uh, a year, > this one is completely new, written mostly from scratch and uses different mechanisms > > ** This is strictly a review/alpha version, but i'd appreciate feedback on it before i finalize it. > > > This addresses bug STORM-64. > http://jira.secondlife.com/browse/STORM-64 > > > Diffs > ----- > > doc/contributions.txt 8da01486a36a > indra/newview/CMakeLists.txt 8da01486a36a > indra/newview/lllocalbitmaps.h PRE-CREATION > indra/newview/lllocalbitmaps.cpp PRE-CREATION > indra/newview/lltexturectrl.h 8da01486a36a > indra/newview/lltexturectrl.cpp 8da01486a36a > indra/newview/llviewertexturelist.h 8da01486a36a > indra/newview/llwearable.h 8da01486a36a > indra/newview/llwearable.cpp 8da01486a36a > indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a > > Diff: http://codereview.secondlife.com/r/347/diff > > > Testing > ------- > > Texture/Sculptmap/Avatar Layer show. > Texture/Sculptmap/Avatar Layer update. > Multiple sculpties update. > > > Thanks, > > Vaalith > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110905/093cbd64/attachment.htm From nickyperian at yahoo.com Mon Sep 5 19:33:46 2011 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 06 Sep 2011 02:33:46 -0000 Subject: [opensource-dev] Review Request: OPEN-69 Make autobuild function with msbuild and keep devenv Message-ID: <20110906023346.10512.29038@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/462/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Background: At Linden Lab (LL) windows libraries are built using a Visual Studio (VS) 2010 full version that is overlaid with Incredible Build (IB). Within IB there are two methods to build libraries. The first is to use devenv.exe through an IB hook and use IB's distributed building capability. The second is to bypass the IB hook and build on a local machine's devenv.exe. This provides an excellent solution for LL. However, it leaves Open Source (OS) developers using VS2010 Express Edition lacking the ability to seamlessly build LL's 3p-xxxx libraries. An earlier suggested approach was to use msbuild.exe to build all libraries since it is available in both full and express editions of VS2010. This approach works, but requires that both the autobuild system and each 3p-xxxx library be changed. This approach was not acceptable to LL. This change: Detect the presence of which VS2010 product is installed on the machine giving preference to VS2010 Express (VCExpress) and fallback to VS2010 Pro or better (VisualStudio). This is provided by the added python script vsproduct.py. This script is imported into common.py and called with the result written to a new environment variable, AUTOBUILD_VSPROD, thus ensuring its visibility to sub-process calls within autobuild. When the bash function build_sln( ) is called from the 3p-xxx build_cmd.sh; AUTOBUILD_VSPROD is compared to VCExpress and if true parses the config variable and splits into config and plat for the subsequent call of msbuild.exe. Else, the original call to devenv.exe is used. This addresses bug https://jira.secondlife.com/browse/OPEN-69. http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/OPEN-69 Diffs ----- OPEN-69-README.txt PRE-CREATION autobuild/autobuild_tool_source_environment.py ac90b03614ea autobuild/common.py ac90b03614ea autobuild/vsproduct.py PRE-CREATION Diff: http://codereview.secondlife.com/r/462/diff Testing ------- Testing: Good: 3p-llconvexdecompostionstub 3p-freeglut 3p-quicktime 3p-fmod Need work: 3p-ogvorbis* 3p-glui* *These libraries use a top level solution file *.sln and do not build ompletely using msbuild.exe. 3P-glui has dependency to 3p-freeglut and ikely would fail using devenv.exe also. These libraries and others need tested by OS developers against devenv.exe to ensure a known good starting point. Future: Test each 3p-xxxx library and on failure decide to change 3p-xxxx's build-cmd.sh to work on devenv and msbuild or detect the library within autobuild's build_sln() and make it work with msbuild at that point. Commented out code in this changed build_sln() shows a capture method example. Thanks, Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110906/2217d6f8/attachment-0001.htm From kf6kjg at gmail.com Mon Sep 5 20:05:13 2011 From: kf6kjg at gmail.com (Ricky) Date: Mon, 5 Sep 2011 20:05:13 -0700 Subject: [opensource-dev] Mesh and Scripting Message-ID: Just pinging to see if anyone knows the current status of such? Grepping around in JIRA I found these entries: https://jira.secondlife.com/browse/CTS-298 - Feature: Support mesh change through script commands https://jira.secondlife.com/browse/CTS-654 - Allow scripts to set a mesh by UUID However, both are closed as "Won't Finish" and I'm suspecting that the status really means "This isn't the mesh team's job." If so, then the JIRA entries should be moved to the correct team, not just shut off. I've noticed that llGet[Link]PrimitiveParams returns as a sculpt (prim type 7) on Server 11.08.22.239223, with a UUID, presumably of the mesh, and a sculpt type of 5. From some reading of rather dated office hours, (https://wiki.secondlife.com/wiki/User:Nyx_Linden/Office_Hours_Transcript_2010-09-29) I've determined that scripting support is waiting on arbitrary skeletons and scripted animation controls - which is to say a long way in the future. Or have I missed something? (Quite likely, as I get most of my SL news from this list...) I've a few suggestions for script+mesh myself, where should they go? SVC? Thanks, Ricky Cron Stardust From angel_of_crimson at hotmail.com Mon Sep 5 20:13:14 2011 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 5 Sep 2011 23:13:14 -0400 Subject: [opensource-dev] ok wtf is this? In-Reply-To: References: <4E645DDE.2050201@meadowlakearts.com>, , <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com>, <4E64F981.5000701@meadowlakearts.com>, Message-ID: maybe their machines have more memory? maybe they didnt have the proper test? I dunno but i see it too... > Date: Mon, 5 Sep 2011 13:22:07 -0400 > From: jhwelch at gmail.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] ok wtf is this? > > A good way to follow what is happening in viewer-development is to > subscribe to the commit mailing list: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/viewer-development-commits > > On Mon, Sep 5, 2011 at 12:32 PM, Dave Booth wrote: > > On 9/5/2011 11:14 AM, Tateru Nino wrote: > >> > >> Indeedy. An excellent catch. If it _is_ the memory pool, though, it is > >> hard to figure out why unit-testing didn't catch the underlying fault. > > > > At a guess, and this is total speculation because I havent done any side > > by side test runs with the setting on and off yet followed by spelunking > > through the logs, I suspect that the easiest way to escape notice in the > > unit tests is if it's a flaw elsewhere that was masked by not using the > > memory pool - unit tests could easily not catch that, things like that > > usually show up in integration testing and UAT and well, that's what > > folks like me are for isn't it - pulling a new build every day and > > spending time inworld with it to see what breaks :) > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110905/e4019f47/attachment.htm From kuraiko at gmx.net Mon Sep 5 20:22:00 2011 From: kuraiko at gmx.net (Kuraiko Yoshikawa) Date: Tue, 06 Sep 2011 05:22:00 +0200 Subject: [opensource-dev] Mesh and Scripting In-Reply-To: References: Message-ID: <4E6591D8.7040201@gmx.net> As I understanded it there won't be support for UUID flipping and meshes are not addressable by UUIDs https://wiki.secondlife.com/wiki/Why_UUID_Flipping_is_Bad Am 06.09.2011 05:05, schrieb Ricky: > Just pinging to see if anyone knows the current status of such? > > Grepping around in JIRA I found these entries: > https://jira.secondlife.com/browse/CTS-298 - Feature: Support mesh > change through script commands > https://jira.secondlife.com/browse/CTS-654 - Allow scripts to set a > mesh by UUID > However, both are closed as "Won't Finish" and I'm suspecting that the > status really means "This isn't the mesh team's job." If so, then the > JIRA entries should be moved to the correct team, not just shut off. > > I've noticed that llGet[Link]PrimitiveParams returns as a sculpt (prim > type 7) on Server 11.08.22.239223, with a UUID, presumably of the > mesh, and a sculpt type of 5. From some reading of rather dated > office hours, (https://wiki.secondlife.com/wiki/User:Nyx_Linden/Office_Hours_Transcript_2010-09-29) > I've determined that scripting support is waiting on arbitrary > skeletons and scripted animation controls - which is to say a long way > in the future. Or have I missed something? (Quite likely, as I get > most of my SL news from this list...) > > I've a few suggestions for script+mesh myself, where should they go? SVC? > > Thanks, > Ricky > Cron Stardust > _______________________________________________ > 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 > From kf6kjg at gmail.com Mon Sep 5 20:32:07 2011 From: kf6kjg at gmail.com (Ricky) Date: Mon, 5 Sep 2011 20:32:07 -0700 Subject: [opensource-dev] Mesh and Scripting In-Reply-To: <4E6591D8.7040201@gmx.net> References: <4E6591D8.7040201@gmx.net> Message-ID: I'm afraid that I allowed myself to create a writeup that made it easy to conflate several independent things: 1) Scripting and meshes in general. 2) Mesh UUID flipping - VERY bad for animations, as you noted and thanks for the link, but has valid uses. 3) Where to put scripting requests - which I just found myself while looking for something else: SCR "Scripting" Thanks for the link to the wiki page. Ricky Cron Stardust On Mon, Sep 5, 2011 at 8:22 PM, Kuraiko Yoshikawa wrote: > As I understanded it there won't be support for UUID flipping and meshes > are not addressable by UUIDs > https://wiki.secondlife.com/wiki/Why_UUID_Flipping_is_Bad > > Am 06.09.2011 05:05, schrieb Ricky: >> Just pinging to see if anyone knows the current status of such? >> >> Grepping around in JIRA I found these entries: >> ? https://jira.secondlife.com/browse/CTS-298 - Feature: Support mesh >> change through script commands >> ? https://jira.secondlife.com/browse/CTS-654 - Allow scripts to set a >> mesh by UUID >> However, both are closed as "Won't Finish" and I'm suspecting that the >> status really means "This isn't the mesh team's job." ?If so, then the >> JIRA entries should be moved to the correct team, not just shut off. >> >> I've noticed that llGet[Link]PrimitiveParams returns as a sculpt (prim >> type 7) on Server 11.08.22.239223, with a UUID, presumably of the >> mesh, and a sculpt type of 5. ?From some reading of rather dated >> office hours, (https://wiki.secondlife.com/wiki/User:Nyx_Linden/Office_Hours_Transcript_2010-09-29) >> I've determined that scripting support is waiting on arbitrary >> skeletons and scripted animation controls - which is to say a long way >> in the future. ?Or have I missed something? (Quite likely, as I get >> most of my SL news from this list...) >> >> I've a few suggestions for script+mesh myself, where should they go? SVC? >> >> Thanks, >> Ricky >> Cron Stardust >> _______________________________________________ >> 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 > From dave at meadowlakearts.com Mon Sep 5 20:51:22 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Mon, 05 Sep 2011 22:51:22 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: References: <4E645DDE.2050201@meadowlakearts.com>, , <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com>, <4E64F981.5000701@meadowlakearts.com>, Message-ID: <4E6598BA.3080408@meadowlakearts.com> On 9/5/2011 10:13 PM, Erin Mallory wrote: > maybe their machines have more memory? maybe they didnt have the proper > test? I dunno but i see it too... Even if the size of the memory pool allocated was impacted by the total available RAM on the machine, which I'm not sure it is, I can see them having more memory on their test machines than I do on my laptop, which has only 6G but I've twice that on my gaming rig and I saw the issue on both. Too soon to be absolutely certain yet, but so far I've been inworld for hours on my laptop tonight with the private memory pool switched off in the debug settings and havent had a problem, so at least there are indications of a workaround. I'm thinking Bao still has a little debugging to do. Once I get a chance to run a test or three on the gaming rig I'll file the JIRA with my results. From dave at meadowlakearts.com Mon Sep 5 22:23:25 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 06 Sep 2011 00:23:25 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E6598BA.3080408@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com>, , <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com>, <4E64F981.5000701@meadowlakearts.com>, <4E6598BA.3080408@meadowlakearts.com> Message-ID: <4E65AE4D.2000504@meadowlakearts.com> Having experienced several hours without the issue recurring on both my systems since turning off the use of the private memory pool, have filed https://jira.secondlife.com/browse/VWR-26864 Have fun finding out what crawled out from under the rock you flipped over, Bao.. Sooner you than me in tracking this one down ;) From sl.nicky.ml at googlemail.com Tue Sep 6 00:25:39 2011 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Tue, 6 Sep 2011 09:25:39 +0200 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E6598BA.3080408@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com> <4E64F981.5000701@meadowlakearts.com> <4E6598BA.3080408@meadowlakearts.com> Message-ID: > > Even if the size of the memory pool allocated was impacted by the total > available RAM on the machine, which I'm not sure it is, I can see them > having more memory on their test machines than I do on my laptop, which > has only 6G but I've twice that on my gaming rig and I saw the issue on > both. As strange as this might sound, 6/12 GB might be too much. There are a lot of casts down to U32. There might be a hidden overflow there, turning some counter into a very small number. From serpentu at gmail.com Tue Sep 6 07:17:52 2011 From: serpentu at gmail.com (Vaalith Jinn) Date: Tue, 06 Sep 2011 14:17:52 -0000 Subject: [opensource-dev] Review Request: STORM-64: Local Bitmaps 2.0 implementation. In-Reply-To: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> References: <20110904152258.10507.3995@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110906141752.10508.52432@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/347/ ----------------------------------------------------------- (Updated Sept. 6, 2011, 7:17 a.m.) Review request for Viewer. Summary (updated) ------- Local Bitmaps is a mechanism to locally load images into the viewer, track them and optionally (per each image) have it check if the image has been overwritten locally and if so - update it in the viewer and inworld. This change affects the texture picker - adding radio checks that let the user choose between the "Inventory" (regular inventory) and "Local" tabs (list of locally added files). *** DO NOT USE THIS YET *** do not implement/use this yet until certain issues are resolved. This addresses bug STORM-64. http://jira.secondlife.com/browse/STORM-64 Diffs ----- doc/contributions.txt 8da01486a36a indra/newview/CMakeLists.txt 8da01486a36a indra/newview/lllocalbitmaps.h PRE-CREATION indra/newview/lllocalbitmaps.cpp PRE-CREATION indra/newview/lltexturectrl.h 8da01486a36a indra/newview/lltexturectrl.cpp 8da01486a36a indra/newview/llviewertexturelist.h 8da01486a36a indra/newview/llwearable.h 8da01486a36a indra/newview/llwearable.cpp 8da01486a36a indra/newview/skins/default/xui/en/floater_texture_ctrl.xml 8da01486a36a Diff: http://codereview.secondlife.com/r/347/diff Testing ------- Texture/Sculptmap/Avatar Layer show. Texture/Sculptmap/Avatar Layer update. Multiple sculpties update. Thanks, Vaalith -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110906/38733f85/attachment-0001.htm From robertltux at gmail.com Tue Sep 6 11:05:55 2011 From: robertltux at gmail.com (Robert Martin) Date: Tue, 6 Sep 2011 14:05:55 -0400 Subject: [opensource-dev] ok wtf is this? In-Reply-To: References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com> <4E64F981.5000701@meadowlakearts.com> <4E6598BA.3080408@meadowlakearts.com> Message-ID: On Tue, Sep 6, 2011 at 3:25 AM, Nicky D. wrote: > As strange as this might sound, 6/12 GB might be too much. > > There are a lot of casts down to U32. There might be a hidden overflow there, > turning some counter into a very small number. > _______________________________________________ it may then be something in the pool causing a C5* type error where the code does not handle that large of a total memory and wraps around the memory space. * a C5 Galaxy is a very large cargo plane and if you are not careful things can get very messy. Even some airports that handle Jumbo Jets can't handle a C5. Empty weight: 380,000 lb (172,370 kg) Loaded weight: 769,000 lb (348,800 kg) anybody wanna bet that some counter in the code should be the next size bigger?? -- Robert L Martin From robertltux at gmail.com Tue Sep 6 15:23:13 2011 From: robertltux at gmail.com (Robert Martin) Date: Tue, 6 Sep 2011 18:23:13 -0400 Subject: [opensource-dev] Standard Reference Mesh Avatars anybody?? Message-ID: given that the Mesh docs seem to be a dogs breakfast does anybody have interest in creating a set of "reference" Avatars (with Clothing maybe??)? Im thinking that it would help say the Make Human project if they had something to look at to see where they would need to end up (if they wanted to support SL). heck a nice library of "standard" objects would work also. -- Robert L Martin From lee.ponzu at gmail.com Tue Sep 6 15:26:00 2011 From: lee.ponzu at gmail.com (Lee ponzu) Date: Tue, 6 Sep 2011 15:26:00 -0700 Subject: [opensource-dev] Feedback wanted for VWR-26858 (User-defined build icons) In-Reply-To: <4E651DE9.3040806@boroon.dasgupta.ch> References: <4E651DE9.3040806@boroon.dasgupta.ch> Message-ID: Over the past couple of years, AL builders have posted many long (winded) blog and forum posts comparing about the building tools, some containing various good ideas. I suggest Googling for them. On Sep 5, 2011 12:07 PM, "Boroondas Gupte" wrote: > On 09/05/2011 08:20 PM, Jonathan Welch wrote: >> Partly to solve a lack of new icon space needed by Storm-49 and partly >> to improve in-world building I have created VWR-26858 >> (https://jira.secondlife.com/browse/VWR-26858) and would appreciate >> your comments on this proposed new feature I would like to work on. >> >> Oz and Esbee might appreciate a few "this is a good idea" comments to >> convince them that yes, it is a good idea, and I would appreciate any >> comments of technical changes you can think of. > It would probably be good to ask the target audience (i.e. SL builders) > about this feature request. I don know where to best reach them, but I > think there's one or several forums on the SL community platform > dedicated to inworld content creation. > > Cheers, > Boroondas > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110906/91156571/attachment.htm From ardylay at gmail.com Tue Sep 6 17:07:26 2011 From: ardylay at gmail.com (Ardy Lay) Date: Tue, 06 Sep 2011 19:07:26 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com> <4E64F981.5000701@meadowlakearts.com> <4E6598BA.3080408@meadowlakearts.com> Message-ID: <4E66B5BE.8090900@gmail.com> If you are talking about the pool I think you are talking about then it has a fixed size, 256MB. Requests greater than 4MB in size are NOT allocated from this pool but are allocated from heap. I increased the size of the managed private pool to 512MB during a dance party 'cause it was driving me crazy. From dave at meadowlakearts.com Tue Sep 6 17:23:01 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 06 Sep 2011 19:23:01 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: References: <4E645DDE.2050201@meadowlakearts.com> <4E64F151.1040606@meadowlakearts.com> <4E64F564.8050407@gmail.com> <4E64F981.5000701@meadowlakearts.com> <4E6598BA.3080408@meadowlakearts.com> Message-ID: <4E66B965.20401@meadowlakearts.com> On 9/6/2011 1:05 PM, Robert Martin wrote: > On Tue, Sep 6, 2011 at 3:25 AM, Nicky D. wrote: > >> As strange as this might sound, 6/12 GB might be too much. >> >> There are a lot of casts down to U32. There might be a hidden overflow there, >> turning some counter into a very small number. >> _______________________________________________ > it may then be something in the pool causing a C5* type error where > the code does not handle that large of a total memory and wraps around > the memory space. > > > * a C5 Galaxy is a very large cargo plane and if you are not careful > things can get very messy. Even some airports that handle Jumbo Jets > can't handle a C5. > > Empty weight: 380,000 lb (172,370 kg) > Loaded weight: 769,000 lb (348,800 kg) > > anybody wanna bet that some counter in the code should be the next size bigger?? > > > The only ones I ever shipped on were your good old reliable herky-birds :) I'm betting the level of discomfort when they were rigged with seats probably scaled up in proportion to the size with the galaxy? Sooner you than me dude. From dave at meadowlakearts.com Tue Sep 6 17:33:06 2011 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 06 Sep 2011 19:33:06 -0500 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E645DDE.2050201@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> Message-ID: <4E66BBC2.4030504@meadowlakearts.com> Gotta give kudos to Bao on this one.. After Grumpity assigned it, 1 minute from status "Acknowledged" to "Fix Pending" - If you can zero in on it that fast, Bao, you are really in tune with your code :) Looking forward to seeing your fix hit the trunk :) From bao at lindenlab.com Tue Sep 6 19:49:28 2011 From: bao at lindenlab.com (Bao Linden) Date: Tue, 6 Sep 2011 20:49:28 -0600 Subject: [opensource-dev] ok wtf is this? In-Reply-To: <4E66BBC2.4030504@meadowlakearts.com> References: <4E645DDE.2050201@meadowlakearts.com> <4E66BBC2.4030504@meadowlakearts.com> Message-ID: Guys, Thank you all for the input. A new fix is at http://codereview.lindenlab.com/6723148/ . Please review it and/or test it. All comments/suggestions/complaints are welcome and much appreciated. The reasons why we introduced this memory pool management scheme are because 1) we want to make the memory allocation/deallocation process more controllable. You might know that there are flaws in our code, third-parties code and graphics drivers which causes memory leaking or absurd memory allocations. Those flaws are normally very hard to catch. We want to extend this memory pool management to intercept and monitor all memory activities in the future. and 2) as some of you already pointed out, we ask for regular 4MB memory chunks from the heap to minimize memory address fragmentation. This is an on-going project. So if you have something you want me to know, please email me at bao at lindenlab.com. Thanks a lot, Bao On Tue, Sep 6, 2011 at 6:33 PM, Dave Booth wrote: > Gotta give kudos to Bao on this one.. > > After Grumpity assigned it, 1 minute from status "Acknowledged" to "Fix > Pending" - If you can zero in on it that fast, Bao, you are really in > tune with your code :) > > Looking forward to seeing your fix hit the trunk :) > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110906/10f7c179/attachment.htm From nexiim at gmail.com Tue Sep 6 22:29:23 2011 From: nexiim at gmail.com (Nexii Malthus) Date: Wed, 7 Sep 2011 06:29:23 +0100 Subject: [opensource-dev] Standard Reference Mesh Avatars anybody?? In-Reply-To: References: Message-ID: Doesn't Make Human have severe issues with making an efficient mesh reasonably optimised for realtime 3D rendering? That seems like the first issue to address for them. - Nexii On Tue, Sep 6, 2011 at 11:23 PM, Robert Martin wrote: > given that the Mesh docs seem to be a dogs breakfast does anybody have > interest in creating a set of "reference" Avatars (with Clothing > maybe??)? Im thinking that it would help say the Make Human project if > they had something to look at to see where they would need to end up > (if they wanted to support SL). > > heck a nice library of "standard" objects would work also. > > -- > Robert L Martin > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110907/b7ef4efd/attachment.htm From hitomi.tiponi at yahoo.co.uk Wed Sep 7 03:29:50 2011 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Wed, 7 Sep 2011 11:29:50 +0100 (BST) Subject: [opensource-dev] Viewer Evolution User Group Meetings Message-ID: <1315391390.43960.YahooMailRC@web23907.mail.ird.yahoo.com> It is now 2 months since the last of these meetings were held. When I last asked about them 7 weeks ago I was told by Trilo (thanks) that Esbee planned on restarting the meetings in the future with a greater scope. I wondered if there was a planned timescale for this yet. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110907/26835e37/attachment.htm From log at lindenlab.com Wed Sep 7 07:49:50 2011 From: log at lindenlab.com (Log Linden) Date: Wed, 07 Sep 2011 14:49:50 -0000 Subject: [opensource-dev] Review Request: LLProxy bugfixes and cleanup. Message-ID: <20110907144950.10512.16560@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/463/ ----------------------------------------------------------- Review request for Viewer. Summary ------- The LLProxy code was merged before I could get all the recommended code review changes implemented, so these changes are all bugfixes to the code that I changed in https://codereview.secondlife.com/r/374/, which is already in viewer-development. I also added a simple unit test of the LLSingleton template to test the functionality that I added. Diffs ----- indra/llcommon/CMakeLists.txt 04642a178228 indra/llcommon/llsingleton.h 04642a178228 indra/llcommon/tests/llsingleton_test.cpp PRE-CREATION indra/llmessage/llcurl.h 04642a178228 indra/llmessage/llcurl.cpp 04642a178228 indra/llmessage/llpacketring.h 04642a178228 indra/llmessage/llpacketring.cpp 04642a178228 indra/llmessage/llproxy.h 04642a178228 indra/llmessage/llproxy.cpp 04642a178228 Diff: http://codereview.secondlife.com/r/463/diff Testing ------- Builds with this code are available on the project page: https://wiki.secondlife.com/wiki/User:Log_Linden/Socks5Viewer . Thanks, Log -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110907/3fce4f39/attachment-0001.htm From vsavchuk at productengine.com Wed Sep 7 10:05:51 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 07 Sep 2011 17:05:51 -0000 Subject: [opensource-dev] Review Request: STORM-1577 Convert chat translation to third party paid translation services Message-ID: <20110907170551.10514.19967@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/464/ ----------------------------------------------------------- Review request for Viewer and Oz Linden. Summary ------- Removed usage of the deprecated Google Translate v1 API. Implemented machine translation via Google Translate v2 and Bing Translate APIs. This addresses bug STORM-1577. http://jira.secondlife.com/browse/STORM-1577 Diffs ----- indra/newview/CMakeLists.txt 8da01486a36a indra/newview/app_settings/settings.xml 8da01486a36a indra/newview/llfloaterpreference.h 8da01486a36a indra/newview/llfloaterpreference.cpp 8da01486a36a indra/newview/llfloatertranslationsettings.h PRE-CREATION indra/newview/llfloatertranslationsettings.cpp PRE-CREATION indra/newview/lltranslate.h 8da01486a36a indra/newview/lltranslate.cpp 8da01486a36a indra/newview/llviewerfloaterreg.cpp 8da01486a36a indra/newview/llviewermessage.cpp 8da01486a36a indra/newview/skins/default/xui/en/floater_translation_settings.xml PRE-CREATION indra/newview/skins/default/xui/en/panel_preferences_chat.xml 8da01486a36a indra/newview/skins/default/xui/en/strings.xml 8da01486a36a Diff: http://codereview.secondlife.com/r/464/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110907/d1a54ad0/attachment.htm From richard at lindenlab.com Wed Sep 7 11:41:08 2011 From: richard at lindenlab.com (Richard Nelson) Date: Wed, 07 Sep 2011 18:41:08 -0000 Subject: [opensource-dev] Review Request: LLProxy bugfixes and cleanup. In-Reply-To: <20110907144950.10512.16560@domU-12-31-38-00-90-68.compute-1.internal> References: <20110907144950.10512.16560@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110907184108.10512.7972@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/463/#review1016 ----------------------------------------------------------- Ship it! Looks good! - Richard On Sept. 7, 2011, 7:49 a.m., Log Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/463/ > ----------------------------------------------------------- > > (Updated Sept. 7, 2011, 7:49 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > The LLProxy code was merged before I could get all the recommended code review changes implemented, so these changes are all bugfixes to the code that I changed in https://codereview.secondlife.com/r/374/, which is already in viewer-development. I also added a simple unit test of the LLSingleton template to test the functionality that I added. > > > Diffs > ----- > > indra/llcommon/CMakeLists.txt 04642a178228 > indra/llcommon/llsingleton.h 04642a178228 > indra/llcommon/tests/llsingleton_test.cpp PRE-CREATION > indra/llmessage/llcurl.h 04642a178228 > indra/llmessage/llcurl.cpp 04642a178228 > indra/llmessage/llpacketring.h 04642a178228 > indra/llmessage/llpacketring.cpp 04642a178228 > indra/llmessage/llproxy.h 04642a178228 > indra/llmessage/llproxy.cpp 04642a178228 > > Diff: http://codereview.secondlife.com/r/463/diff > > > Testing > ------- > > Builds with this code are available on the project page: https://wiki.secondlife.com/wiki/User:Log_Linden/Socks5Viewer . > > > Thanks, > > Log > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110907/aaeba6f1/attachment.htm From vsavchuk at productengine.com Wed Sep 7 12:25:32 2011 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 07 Sep 2011 19:25:32 -0000 Subject: [opensource-dev] Review Request: STORM-1587 A lot of notifications are shown in English for other locales in 3.0.3 Beta Message-ID: <20110907192532.10513.87385@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/465/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Make sure LLUI::setupPaths() gets called before initializing notifications. This addresses bug STORM-1587. http://jira.secondlife.com/browse/STORM-1587 Diffs ----- indra/newview/llappviewer.cpp 3d4dff671209 Diff: http://codereview.secondlife.com/r/465/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110907/1b43da40/attachment.htm From slitovchuk at productengine.com Thu Sep 8 10:02:00 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 08 Sep 2011 17:02:00 -0000 Subject: [opensource-dev] Review Request: STORM-1587 A lot of notifications are shown in English for other locales in 3.0.3 Beta In-Reply-To: <20110907192532.10513.87385@domU-12-31-38-00-90-68.compute-1.internal> References: <20110907192532.10513.87385@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110908170200.10512.32457@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/465/#review1017 ----------------------------------------------------------- Ship it! looks good to me. - Seth On Sept. 7, 2011, 12:25 p.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/465/ > ----------------------------------------------------------- > > (Updated Sept. 7, 2011, 12:25 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > Make sure LLUI::setupPaths() gets called before initializing notifications. > > > This addresses bug STORM-1587. > http://jira.secondlife.com/browse/STORM-1587 > > > Diffs > ----- > > indra/newview/llappviewer.cpp 3d4dff671209 > > Diff: http://codereview.secondlife.com/r/465/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110908/46ee0991/attachment.htm From tapplek at gmail.com Thu Sep 8 14:04:00 2011 From: tapplek at gmail.com (Matthew Fulmer) Date: Thu, 8 Sep 2011 17:04:00 -0400 Subject: [opensource-dev] Looking for help for better animation tools In-Reply-To: References: Message-ID: On Tue, Aug 30, 2011 at 10:12 AM, Stickman wrote: > The first tool is a pretty simple modification of the Second Life > client. When you upload a BVH animation, the Second Life client will > convert it to the internal Second Life animation format and then > upload it to the asset server. > > This modification would simply allow you to save it to the local hard > drive, rather than having it be uploaded. I'll look into this one sometime, but I don't have reliable access to a computer I can develop on right now From Lance.Corrimal at eregion.de Fri Sep 9 06:06:46 2011 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 09 Sep 2011 13:06:46 -0000 Subject: [opensource-dev] Review Request: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape. In-Reply-To: <20110712184718.10350.92087@domU-12-31-38-00-90-68.compute-1.internal> References: <20110712184718.10350.92087@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110909130646.10508.28107@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/388/#review1018 ----------------------------------------------------------- under certain conditions the hollow value "snaps back" to 95.0: * stretching a hollowed prim * entering a "wrong number" manually, e.g. 99.999 otherwise it works fine. - Lance On July 12, 2011, 11:47 a.m., Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/388/ > ----------------------------------------------------------- > > (Updated July 12, 2011, 11:47 a.m.) > > > Review request for Viewer. > > > Summary > ------- > > As a Builder, I want to be able to create prims that are more than 95 % hollow which will allow me to create more realistic paper sheets, flags, fabric bits, ribbons, etc. > > > This addresses bug STORM-58. > http://jira.secondlife.com/browse/STORM-58 > > > Diffs > ----- > > doc/contributions.txt d4cd5f0f33d2 > indra/llmath/llvolume.cpp d4cd5f0f33d2 > indra/newview/llpanelobject.cpp d4cd5f0f33d2 > indra/newview/skins/default/xui/en/floater_tools.xml d4cd5f0f33d2 > > Diff: http://codereview.secondlife.com/r/388/diff > > > Testing > ------- > > Built viewer locally and testes Viewer Phase of Acceptance Criteria. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110909/3caf906b/attachment.htm From jamey at beau.org Fri Sep 9 07:53:37 2011 From: jamey at beau.org (Jamey Fletcher) Date: Fri, 09 Sep 2011 09:53:37 -0500 Subject: [opensource-dev] Review Request: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape. In-Reply-To: <20110909130646.10508.28107@domU-12-31-38-00-90-68.compute-1.internal> References: <20110712184718.10350.92087@domU-12-31-38-00-90-68.compute-1.internal> <20110909130646.10508.28107@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4E6A2871.30104@beau.org> Lance Corrimal wrote: > under certain conditions the hollow value"snaps back" to 95.0: > * stretching a hollowed prim > * entering a"wrong number" manually, e.g. 99.999 I believe all prim size/parameter restraints are clamped on the server, due to the Megaprims debacle. I think there was some testing of hollows greater than 95%, and some issues were run into with the physics engine. As the physics engine has changed twice, at least, since then I think, it may be possible to increase it to 99%. From slitovchuk at productengine.com Fri Sep 9 14:58:30 2011 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Fri, 09 Sep 2011 21:58:30 -0000 Subject: [opensource-dev] Review Request: STORM-1577 Convert chat translation to third party paid translation services In-Reply-To: <20110907170551.10514.19967@domU-12-31-38-00-90-68.compute-1.internal> References: <20110907170551.10514.19967@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110909215830.11180.10262@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/464/#review1019 ----------------------------------------------------------- Ship it! Looks good to me. - Seth On Sept. 7, 2011, 10:05 a.m., Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/464/ > ----------------------------------------------------------- > > (Updated Sept. 7, 2011, 10:05 a.m.) > > > Review request for Viewer and Oz Linden. > > > Summary > ------- > > Removed usage of the deprecated Google Translate v1 API. > Implemented machine translation via Google Translate v2 and Bing Translate APIs. > > > This addresses bug STORM-1577. > http://jira.secondlife.com/browse/STORM-1577 > > > Diffs > ----- > > indra/newview/CMakeLists.txt 8da01486a36a > indra/newview/app_settings/settings.xml 8da01486a36a > indra/newview/llfloaterpreference.h 8da01486a36a > indra/newview/llfloaterpreference.cpp 8da01486a36a > indra/newview/llfloatertranslationsettings.h PRE-CREATION > indra/newview/llfloatertranslationsettings.cpp PRE-CREATION > indra/newview/lltranslate.h 8da01486a36a > indra/newview/lltranslate.cpp 8da01486a36a > indra/newview/llviewerfloaterreg.cpp 8da01486a36a > indra/newview/llviewermessage.cpp 8da01486a36a > indra/newview/skins/default/xui/en/floater_translation_settings.xml PRE-CREATION > indra/newview/skins/default/xui/en/panel_preferences_chat.xml 8da01486a36a > indra/newview/skins/default/xui/en/strings.xml 8da01486a36a > > Diff: http://codereview.secondlife.com/r/464/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110909/23b4d8f0/attachment.htm From oz at lindenlab.com Fri Sep 9 15:06:39 2011 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 09 Sep 2011 18:06:39 -0400 Subject: [opensource-dev] Snowstorm Team Reveiw Build Message-ID: <4E6A8DEF.7010903@lindenlab.com> *Snowstorm Team Issues: Functional Review build* STORM-918 Changes in Group Role Titles or Assignments Not Reflected in Title Dropdown STORM-1028 Speak button label not displaying at default window size STORM-1297 Clicking on Block in a dialog box from an object blocks the object owner, not the object, and sets the wrong block type STORM-1532 Unnecessary capability request spam STORM-1587 A lot of notifications are shown in English for other locales in 3.0.3 Beta Windows | Macintosh | Linux ------------------------------------------------------------------------ Details for these builds (build logs, included changesets) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110909/0a4884b7/attachment.htm From aklo at skyhighway.com Fri Sep 9 21:26:19 2011 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Fri, 9 Sep 2011 21:26:19 -0700 Subject: [opensource-dev] Review Request: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape. Message-ID: <935add37d2aed6e26feb61ff89f17459.squirrel@cruziomail.cruzio.com> Jamey (or anyone else that would like to answer), can you please explain "the Megaprims debacle"? i know it's a little off-topic, but i've always wondered why Megaprims have such a bad rep. i can see how they could be abused, but i don't see how the abuse could be anything more than a minor annoyance. Thx! And pls forgive my asking if ppl would really not like to have questions like this here. - AK -------------------------------------------------------------------------------- Lance Corrimal wrote: > under certain conditions the hollow value"snaps back" to 95.0: > * stretching a hollowed prim > * entering a"wrong number" manually, e.g. 99.999 I believe all prim size/parameter restraints are clamped on the server, due to the Megaprims debacle. I think there was some testing of hollows greater than 95%, and some issues were run into with the physics engine. As the physics engine has changed twice, at least, since then I think, it may be possible to increase it to 99%. _______________________________________________ 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 From zabb65 at gmail.com Fri Sep 9 21:31:07 2011 From: zabb65 at gmail.com (Zabb65) Date: Sat, 10 Sep 2011 00:31:07 -0400 Subject: [opensource-dev] Review Request: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape. In-Reply-To: <4E6A2871.30104@beau.org> References: <20110712184718.10350.92087@domU-12-31-38-00-90-68.compute-1.internal> <20110909130646.10508.28107@domU-12-31-38-00-90-68.compute-1.internal> <4E6A2871.30104@beau.org> Message-ID: The clamp for primitive parameters was in place long before the megaprim "debacle", unless you are referring to the one in early 2006, possibly even earlier than that. From jamey at beau.org Fri Sep 9 21:48:24 2011 From: jamey at beau.org (Jamey Fletcher) Date: Fri, 09 Sep 2011 23:48:24 -0500 Subject: [opensource-dev] Review Request: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape. In-Reply-To: References: <20110712184718.10350.92087@domU-12-31-38-00-90-68.compute-1.internal> <20110909130646.10508.28107@domU-12-31-38-00-90-68.compute-1.internal> <4E6A2871.30104@beau.org> Message-ID: <4E6AEC18.7080208@beau.org> Zabb65 wrote: > The clamp for primitive parameters was in place long before the > megaprim "debacle", unless you are referring to the one in early 2006, > possibly even earlier than that. >> From what I know, doing this will require that the server be updated > to relax this restriction. That is the one I'm talking about - the one that resulted in a large part of the grid having objects created by Gene Replacement. Somewhere prior to time frame, the server did not clamp the prim dimensions - it was done client side. However, reverse-engineering of the protocol resulted in libsecondlife, which was used to create the most infamous of the "copybots", as well the megaprims labeled as created by Gene Replacement. These prims were made full-permission and handed out quite widely - the 20x20x0.5 cube prim is still one of the mainstays of building. However, due to some of the other prims created, including a 65535x65535x0.01 "infinite prim", which when rezzed often required Linden intervention to remove, Megaprims got the reputation for being laggy and bad for the system. Linden Labs refused to support them, but also did not take action to remove them from the grid, unless they were specifically involved in a griefing action, such as the above prim. For a long time, there were camps both within Linden Labs, and among the users, over whether or not to increase the limits. Claims and counter-claims got pretty heated at times. Finally, Andrew Linden, one of the anti-megaprim camp, proposed a series of checkpoints that if fulfilled, would lead him to supported "Megaprim Liberation Day". The biggest thing was some way that users could remove megaprims from encroaching on their land, even if the center of the megaprim was not on their land. The suggested fix at the time (and I suspect the one finally implemented) involved having parcels as a special object type in the physics engine, and checking for collision. With the implementation of Mesh, though, we have something near full Megaprim liberation - we can create prims up to 64x64x64. There will be times when even larger prims will be useful - and the Gene Replacement megaprims, as well as the second-wave ones created when the servers had clamping turned off by mistake a couple of years ago, are still in inventories and available. But for the most part, the current maximum size is a very nice one, and I've already started using it to reduce my prim count. Now, I just need to figure out why v3 won't run for me, so I can check into the "not involved in collisions" flag, which, but one reading of the announcement, means that prims flagged that way don't count against your parcel prim limit (though I suspect physics-enabled vehicle prim limit was what was meant). From sldev at free.fr Mon Sep 12 06:22:45 2011 From: sldev at free.fr (Henri Beauchamp) Date: Mon, 12 Sep 2011 15:22:45 +0200 Subject: [opensource-dev] Review Request: STORM-1567 Mute button for llDialog popup In-Reply-To: <20110822164322.10807.7875@domU-12-31-38-00-90-68.compute-1.internal> References: <20110822164322.10807.7875@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20110912152245.65d08e83.sldev@free.fr> On Mon, 22 Aug 2011 16:43:22 -0000, Jonathan Yap wrote: > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/449/ > ----------------------------------------------------------- > > Review request for Viewer. > > > Summary > ------- > > Add a block button to popups from llDialog calls. Clicking on the Block > button adds the object to the block list. The type of block is Object. There is an issue with the way this is implemented: existing scripts using a "Mute" button in their own menu get this button interpreted as a viewer-side block action request from the user. Note that this is also an issue with llDialog()s using "Ignore" as a button, but the latter has been documented like forever on the LSL portal, thus not being a real issue, while this new blocking feature breaks *existing* contents. The reason why client side buttons and script side llDialog() buttons get mixed up is that the buttons in the script menus got the same internal "name" as the "text" they are set for, and since UI dialogs are all referred by their "name" field in the viewer UI, the first matching "name" in a list of buttons is used to trigger the corresponding action (here, block by object UUID for any "Mute" button in the dialog). The fix is simple (and also fixes the "Ignore" button issue): you just have to use a "name" field for the client side buttons ("Ignore" and "Block") that scripts are unlikely to ever use. For the Cool VL Viewer (v1.26.0.19 and v1.26.1.6, to be released this week), I use "client_side_mute" and "client_side_ignore" as the "Block" and "Ignore" button names in the notification menu definition (in notifications.xml). For v3, this would read as: [NAME]'s '<nolink>[TITLE]</nolink>' [MESSAGE]