From robin.cornelius at gmail.com Tue Jul 1 00:46:10 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 1 00:46:13 2008 Subject: [sldev] [LLMozLib] Missing scrollbars and other notifications Message-ID: Hey, I've done some more hacking on the xulrunner linked mozlib and got it working a little better. I've hacked in some notifyinvalidate calls in certain areas such as scrollby etc and key down, which although not very efficient, means that the page gets a redraw now and it is possible to scroll the web pages via the mouse wheel, the invisible scroll bars or the up/down arrows. As these events are not injected for web on prim type applications it should have no overhead normally, only when using the search functions or browsing a web site in the viewer so i can live with this. Note this is when using an unpatched xulrunner/GRE NOT the linden patched xul libraries. What is annoying me are a couple of things:- 1) Missing scroll bars. Or invisible scroll bars (on the top level web display). I'm not 100% clear why they are invisible in my incarnation and i was wondering if anyone knows what can be done to make them display. they appear to function and do what is expected but just appear as a black area at the side of the window. I wonder if i need to actually draw them myself as i don't have a toolkit on the window as we have overridden the chrome window but i am not sure on this. 2) Extra notifications, is it possible to hook in to any exported API that can give an event when something like a javascript function reloads something. To things i have noticed, on the your viewer is out of date on the web splash screen does not appear unless i generate some screen refreshes after state complete has been reached on the web page. I was wondering if there are any hooks that can notify about this. Also on the showcase page, clicking on a new showcase loads in an image via javascript and this is also not updated for the same reason. My concern is that there is NO exported mozilla API that does this in any fashion which is why Callum added the toolkitobserver in the first place and that i am kind of stuck where i am, which is usable but not ideal and it is a compromise between a few annoyances with a standard system xulrunner to doing what is 100% expected with a private patched xulrunner. Robin From evolutie at gmail.com Tue Jul 1 04:45:06 2008 From: evolutie at gmail.com (evolutie) Date: Tue Jul 1 04:45:09 2008 Subject: [sldev] Can anyone help? In-Reply-To: <4867EEF9.9010400@usfastweb.com> References: <4867EEF9.9010400@usfastweb.com> Message-ID: <5fb4b1fa0807010445u5fa7601fu1840e5bade793322@mail.gmail.com> Hi Terry, Check this page: http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 hope that will help. evo On Sun, Jun 29, 2008 at 10:22 PM, Terry F. wrote: > > I'm having some trouble compiling 1.20.11RC can anyone help? > I am a "Noob" compiling the viewer and I keep getting errors. > I'm using VS2005 Express. > Nicholaz has helped me in the past by sending me a "PRE" converted, Ready to > compile folder and I have been able to build this fine, so this leads me to > believe my setup and program settings are correct. > I'm just not sure where I'm going wrong trying to convert and prepare the > downloaded material on my own. > I'm sure it's something I'm overlooking, but I can't figure it out. > I've spent countless hours trying to resolve my problems but cannot > successfully download, convert/prepare, and build the viewer. > > I open the "indra_complete.sln" file. > I've set "newview" as my default project and "unloaded" the test, > win_crash_logger and win_updater projects. > I choose "Release" then click build, and it eventually errors. > > Any help would be greatly appreciated! > > I'm getting this error(There are others, but I'm trying to solve each in > order): > > llsys.cpp(144) : error C2665: 'utf16str_to_utf8str' : none of the 2 > overloads could convert all the argument types > i:\linden\indra\llcommon\llstring.h(430): could be 'std::string > utf16str_to_utf8str(const llutf16string &)' > while trying to match the argument list '(WCHAR [128])' > > Thank-you, > -Terry > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- http://www.creativemachinery.org From seg at haxxed.com Tue Jul 1 09:32:35 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jul 1 09:32:38 2008 Subject: [sldev] Using OS X Image I/O for jpeg200 handling? In-Reply-To: <485EB387.5060305@uni-oldenburg.de> References: <485EB387.5060305@uni-oldenburg.de> Message-ID: <1218b5bc0807010932v39689f7j727d8f71e58a8311@mail.gmail.com> On Sun, Jun 22, 2008 at 3:18 PM, Michael Schlenker wrote: > just wondered if it would be worth the time to investigate Apples Image I/O > Framework for jpeg2000 handling for the open source viewer on OS X. Its > basically the kakadu lib shipped with Apples OS, so should be better than > libjpeg. (at least according to a comment in > http://www.wilshipley.com/blog/2005/09/jpeg2000-cool-but-slow.html ) I don't see a lot of value in this. Linden Lab already has a KDU license, so it adds little value to them. Not a lot of value to open source, OSX is something of a minority platform, (everything is, next to Windows) open source effort seems best spent on improving OpenJPEG. But I also see nothing wrong with it. If it's shipped with OSX, it should fall under the 'system libraries' exception in the GPL. > Has there been any work in that direction? > Patches welcome. :) There's already some abstraction in the code to allow switching between KDU and OpenJPEG, so plugging in support for Apple's framework should be possible to do without disturbing things too much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080701/86b97779/attachment.htm From suzhanna.rossini at balsaestates.com Tue Jul 1 10:28:16 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Tue Jul 1 10:28:28 2008 Subject: SV: [sldev] Building with VS2008? In-Reply-To: References: <48693A12.5020103@balsaestates.com> Message-ID: <05ee01c8db9f$d93e4940$8bbadbc0$@rossini@balsaestates.com> > You will run into many problems with Visual Studio 2008 and the > current release candidate viewer (1.20). Visual Studio 2003 is the > only officially supported Windows compiler there. > > Things will be much easier if you pull the release branch and use > cmake, which can generate Visual Studio 2008 project files. Okay... I tried that, but I used the pre-built libraries from 1.20 Viewer-2 r90229. Seems like most compiled clean enough, some warnings here and there, but I also got a list of errors while linking. llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) aprutil-1.lib(open.obj) : error LNK2019: unresolved external symbol __imp__wcscpy referenced in function _utf8_to_unicode_path aprutil-1.lib(filesys.obj) : error LNK2001: unresolved external symbol __imp__wcscpy aprutil-1.lib(dir.obj) : error LNK2001: unresolved external symbol __imp__wcscpy aprutil-1.lib(apr_snprintf.obj) : error LNK2019: unresolved external symbol __imp__modf referenced in function _apr_cvt aprutil-1.lib(proc.obj) : error LNK2019: unresolved external symbol __imp__wcschr referenced in function _apr_proc_create@24 aprutil-1.lib(dir.obj) : error LNK2001: unresolved external symbol __imp__wcschr aprutil-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol __imp__strspn referenced in function _find_addresses aprutil-1.lib(pipe.obj) : error LNK2019: unresolved external symbol __imp__getpid referenced in function _apr_create_nt_pipe OLDNAMES.lib(getpid.obi) : error LNK2001: unresolved external symbol __imp__getpid OLDNAMES.lib(getpid.obi) : error LNK2001: unresolved external symbol __imp___getpid aprutil-1.lib(start.obj) : error LNK2019: unresolved external symbol __imp____p__wenviron referenced in function _apr_app_initialize@12 aprutil-1.lib(start.obj) : error LNK2019: unresolved external symbol __imp____p__environ referenced in function _apr_app_initialize@12 aprutil-1.lib(start.obj) : error LNK2019: unresolved external symbol __imp____p__wenviron referenced in function _apr_app_initialize@12 aprutil-1.lib(start.obj) : error LNK2019: unresolved external symbol __imp____p__environ referenced in function _apr_app_initialize@12 aprutil-1.lib(open.obj) : error LNK2019: unresolved external symbol __imp__wcscpy referenced in function _utf8_to_unicode_path aprutil-1.lib(dir.obj) : error LNK2001: unresolved external symbol __imp__wcscpy aprutil-1.lib(filesys.obj) : error LNK2001: unresolved external symbol __imp__wcscpy aprutil-1.lib(dir.obj) : error LNK2019: unresolved external symbol __imp__wcschr referenced in function _apr_dir_read@12 aprutil-1.lib(proc.obj) : error LNK2001: unresolved external symbol __imp__wcschr aprutil-1.lib(apr_snprintf.obj) : error LNK2019: unresolved external symbol __imp__modf referenced in function _apr_cvt aprutil-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol __imp__strspn referenced in function _find_addresses aprutil-1.lib(pipe.obj) : error LNK2019: unresolved external symbol __imp__getpid referenced in function _apr_create_nt_pipe OLDNAMES.lib(getpid.obi) : error LNK2001: unresolved external symbol __imp__getpid OLDNAMES.lib(getpid.obi) : error LNK2001: unresolved external symbol __imp___getpid To me, at a glance, it looks like it's the Apache libraries that gives the errors, so I guess I'll rebuild them and see if things get better.. Or am I on the wrong track? > > > On Mon, Jun 30, 2008 at 2:54 PM, Suzhanna Rossini > wrote: > > I'm struggling to build the client with VS2008, but I'm running into > a whole > > lot of obstacles. > > Is there anybody out there that can give pointers and advice? I'm > rather new > > to the Windows way of doing things, and VS2008 is the only > environment I > > have available. > > > > Thank you! > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > From robla at lindenlab.com Tue Jul 1 10:38:57 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 1 10:39:02 2008 Subject: [sldev] No nominees for Contributor of the Year? Message-ID: <486A6BB1.9040006@lindenlab.com> Hi all, Nominations have poured in for many of the categories of Hippo awards. However, here's a rather surprising result: https://jira.secondlife.com/browse/MISC-1305 After a week of being open, no one has ventured a nomination for "Contributor of the Year". Surely you all think that someone here is worthy, don't you? Rob From jhurliman at jhurliman.org Tue Jul 1 12:39:38 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jul 1 12:39:41 2008 Subject: [sldev] llcubemap.cpp missing in release (r723)? Message-ID: CMake generate complains about a missing llcubemap.cpp. Looking in release/indra/llrender (SVN revision 723) I see llcubemap.h but no .cpp file. Is this a problem with the commit or the CMake file? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080701/bb5afd9b/attachment.htm From soft at lindenlab.com Tue Jul 1 13:40:51 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 1 13:40:55 2008 Subject: [sldev] llcubemap.cpp missing in release (r723)? In-Reply-To: References: Message-ID: On Tue, Jul 1, 2008 at 2:39 PM, John Hurliman wrote: > CMake generate complains about a missing llcubemap.cpp. Looking in > release/indra/llrender (SVN revision 723) I see llcubemap.h but no .cpp > file. Is this a problem with the commit or the CMake file? I found the problem. Hang tight, I'll do an export and test the build on Windows before republishing. From marinekelley at gmail.com Tue Jul 1 15:30:16 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Tue Jul 1 15:30:18 2008 Subject: [sldev] No nominees for Contributor of the Year? In-Reply-To: <486A6BB1.9040006@lindenlab.com> References: <486A6BB1.9040006@lindenlab.com> Message-ID: <9e52a8c10807011530j4048e024lf3d7c87f0a7b0c03@mail.gmail.com> Hello all, I have added a comment about my work. It is Mature (very much) and not PG (at all), and probably not eligible for any kind of public nomination, but I just wanted to talk about the RestrainedLife viewer, which is quite popular within the BDSM community in SL and has allowed some people to start their own businesses in selling RLV compatible stuff. Marine 2008/7/1 Rob Lanphier : > Hi all, > > Nominations have poured in for many of the categories of Hippo awards. > However, here's a rather surprising result: > https://jira.secondlife.com/browse/MISC-1305 > > After a week of being open, no one has ventured a nomination for > "Contributor of the Year". Surely you all think that someone here is > worthy, don't you? > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080702/ffe08e10/attachment.htm From dahliatrimble at gmail.com Tue Jul 1 16:32:03 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Jul 1 16:32:05 2008 Subject: [sldev] No nominees for Contributor of the Year? In-Reply-To: <486A6BB1.9040006@lindenlab.com> References: <486A6BB1.9040006@lindenlab.com> Message-ID: Well it hasn't done much to increase sales of my LSL based lip-sync hud, but I'd like to nominate the contributor of the lip sync patch - sorry cant remember his name off hand, On Tue, Jul 1, 2008 at 10:38 AM, Rob Lanphier wrote: > Hi all, > > Nominations have poured in for many of the categories of Hippo awards. > However, here's a rather surprising result: > https://jira.secondlife.com/browse/MISC-1305 > > After a week of being open, no one has ventured a nomination for > "Contributor of the Year". Surely you all think that someone here is > worthy, don't you? > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080701/93539729/attachment.htm From aimee at ama-zing.co.uk Tue Jul 1 18:28:35 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jul 1 18:28:49 2008 Subject: [sldev] No nominees for Contributor of the Year? In-Reply-To: References: <486A6BB1.9040006@lindenlab.com> Message-ID: On Jul 2, 2008, at 00:32, Dahlia Trimble wrote: > Well it hasn't done much to increase sales of my LSL based lip-sync > hud, but I'd like to nominate the contributor of the lip sync patch > - sorry cant remember his name off hand, That would be Mike Monkowski, MM Alder, and I'd definitely second that. Aimee. From gbrandon at gmail.com Tue Jul 1 18:33:05 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Tue Jul 1 18:33:10 2008 Subject: [sldev] No nominees for Contributor of the Year? In-Reply-To: References: <486A6BB1.9040006@lindenlab.com> Message-ID: Someone should dump a big list of all the community contributions this year to jog our memories :D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080701/8abdafb5/attachment.htm From yesha at metaverse-labs.com Tue Jul 1 20:48:27 2008 From: yesha at metaverse-labs.com (Yesha Sivan) Date: Tue Jul 1 20:48:30 2008 Subject: [sldev] Call for Beta: Aqros Mobile SL messenger Message-ID: <3e3ef2f00807012048v7409105alf17e4650cc5b5946@mail.gmail.com> I have been working with Aqros to fine tune their Social Virtual Worlds Messenger. Their vision is simple: "Allow you to connect with your virtual worlds friends anywhere with your mobile." The first version worlds with Second Life. It looks like this: To download the Beta client go to http://get.aqros.com To read more about Aqros see http://blog.aqros.com (Lots of info here.) My full blog post on this is: http://www.dryesha.com/2008/06/first-look-aqros-beta-social-mobile.html Let me know what you think... -- Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080702/5dbddb6c/attachment.htm From gigstaggart at gmail.com Tue Jul 1 21:03:59 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 1 21:04:03 2008 Subject: [sldev] Call for Beta: Aqros Mobile SL messenger In-Reply-To: <3e3ef2f00807012048v7409105alf17e4650cc5b5946@mail.gmail.com> References: <3e3ef2f00807012048v7409105alf17e4650cc5b5946@mail.gmail.com> Message-ID: <486AFE2F.2050200@gmail.com> Yesha Sivan wrote: > Let me know what you think... Cool. Is it open source? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080702/d87ffe95/smime-0001.bin From suzhanna.rossini at balsaestates.com Wed Jul 2 01:02:37 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Wed Jul 2 01:02:45 2008 Subject: [sldev] Compiling apr Message-ID: <006b01c8dc19$fe8d10d0$fba73270$@rossini@balsaestates.com> I'm trying to compile apr, but runs into missing header files for PySQL, Oracle and more.. Are the apr_dbd_* parts needed at all? Or do I have to install all those header files to satisfy the build? From Anders at Arnholm.se Wed Jul 2 01:27:59 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Jul 2 01:29:15 2008 Subject: [sldev] Call for Beta: Aqros Mobile SL messenger In-Reply-To: <486AFE2F.2050200@gmail.com> References: <3e3ef2f00807012048v7409105alf17e4650cc5b5946@mail.gmail.com> <486AFE2F.2050200@gmail.com> Message-ID: <20080702082759.GH19105@arnholm.se> On Wed, Jul 02, 2008 at 12:03:59AM -0400, Jason Giglio wrote: > Yesha Sivan wrote: > > Let me know what you think... > > Cool. Is it open source? With the follwoing in term: Prohibited Uses. You may not, without written permission from us: (a) Use, copy, modify, merge or transfer copies of the Software except as expressly authorized in this Agreement; (b) Use any back-up or archival copies of the Software (or allow someone else to use such copies) for any purpose; (c) Disassemble, decompile or "unlock" reverse translate, reverse engineer or in any manner decode the Software for an reason; (d) Sublicense, lease, sell, rent, lend, or otherwise transfer the Software; or (e) Remove or alter any marks or designations indicating the ownership of copyrights, trademarks or other intellectual property rights of any party contained in the Software. Take not, and I really would have liked a download with out sending my phone number to them... With a such one one could have figured out if it's just there sloppy testing or bad Java programing that make the Sony-Ericsson phone not work. / Balp -- o_ Anders Arnholm, o/ /\ anders@arnholm.se /|_, \\ http://anders.arnholm.se/ / ` -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tao.takashi at googlemail.com Wed Jul 2 04:36:37 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Wed Jul 2 04:36:40 2008 Subject: [sldev] [AWG] [ANN] pyogp mailing list now available Message-ID: <23bbb49e0807020436h4a91bed8icc274b6debc0a4c7@mail.gmail.com> Hi! We now have a mailing list dedicated to the development of the pyogp project which consists of - a library for connecting and implementing OGP compatible components - a test harness for testing OGP compatible components if they are truely compatible and potentially more. You can find the mailing list and subscribe to it at https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp or if you prefer to use a newsreader for doing so you can subscribe to gmane.comp.python.pyogp on the server news.gmane.org. You can also access the web interface here: http://dir.gmane.org/gmane.comp.python.pyogp There are also some messages on it already about the structure so far and how we go from there. There is also some information now on the wiki about how we develop, what's being used and what the structure of the project is. More will be added later. You can find this here: https://wiki.secondlife.com/wiki/Pyogp/ cheers, Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From tom at streamsense.net Wed Jul 2 09:40:54 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Jul 2 09:42:29 2008 Subject: [sldev] shadow-draft problem Message-ID: <486BAF96.5080000@streamsense.net> Hi folks, I'm having some issues with the shadow-draft tree (http://svn.secondlife.com/trac/linden/browser/branches/shadow-draft) All appears to compile perfectly, but on execution the client crashes with an error apparently related to llkdu.dll: > SecondLife.exe!LLError::crashAndLoop(const std::basic_string,std::allocator > & message="ERROR: LLImageGL::createGLTexture failed to make texture") Line 1101 + 0x3 bytes C++ Has anyone encountered this before? Do I remember an issue similar to this previously where the llkdu.dll supplied in the libs tree was out of date? Thanks Tom From glenn at lindenlab.com Wed Jul 2 09:49:39 2008 From: glenn at lindenlab.com (Glenn Fisher) Date: Wed Jul 2 09:49:42 2008 Subject: [sldev] Scripting Survey Message-ID: Thank you to the many of you who took time to take our scripting survey - we had almost 250 responses, and its taken a while to sort through the responses. Here's a topline summary: Priority order based on weighting the rankings (the number is the weighted ranking): HTTPIn 1569 LLGive..with Confirmation 1506 C#1.0 Scripts 1313 Script Libraries 1305 CollectionClasses 1030 CLI Assemblies 1015 Improved Scheduling 903 Script Resource Limits 786 (If ranked solely by the number of responses to rank #1, Collection Classes and CLI Assemblies change order, but the rest are the same. The number of comments varied between 95 and 134, but number of comments doesn't correlate with ranking. Glenn Glenn Fisher Director of Business Programs Linden Lab -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080702/e45d127c/attachment.htm From nik at terminaldischarge.net Wed Jul 2 10:00:53 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Jul 2 10:01:24 2008 Subject: [sldev] Scripting Survey In-Reply-To: References: Message-ID: <486BB445.2070102@terminaldischarge.net> Pretty much as I expected :) Glenn Fisher wrote: > Thank you to the many of you who took time to take our scripting > survey - we had almost 250 responses, and its taken a while to sort > through the responses. Here's a topline summary: > > Priority order based on weighting the rankings (the number is the > weighted ranking): > HTTPIn 1569 > LLGive..with Confirmation 1506 > C#1.0 Scripts 1313 > Script Libraries 1305 > CollectionClasses 1030 > CLI Assemblies 1015 > Improved Scheduling 903 > Script Resource Limits 786 Still think script resource limits is a big No-No though. > (If ranked solely by the number of responses to rank #1, Collection > Classes and CLI Assemblies change order, but the rest are the same. > The number of comments varied between 95 and 134, but number of > comments doesn't correlate with ranking. > > Glenn > > Glenn Fisher > Director of Business Programs > Linden Lab > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From soft at lindenlab.com Wed Jul 2 12:42:30 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 2 12:42:33 2008 Subject: [sldev] shadow-draft problem In-Reply-To: <486BAF96.5080000@streamsense.net> References: <486BAF96.5080000@streamsense.net> Message-ID: The easiest way to test that is to erase or rename llkdu.dll - if that's absent, the viewer falls back on openjpeg for decoding. It is indeed likely that the llkdu is out of sync. In the near future we're going to stop exporting llkdu in any branch except release candidate and official release to deal with this kind of problem. In the long term, we want to remove the dependencies that can make llkdu incompatible when viewer headers change. On Wed, Jul 2, 2008 at 11:40 AM, Thomas Grimshaw wrote: > Hi folks, > > I'm having some issues with the shadow-draft tree > (http://svn.secondlife.com/trac/linden/browser/branches/shadow-draft) > > All appears to compile perfectly, but on execution the client crashes with > an error apparently related to llkdu.dll: > >> SecondLife.exe!LLError::crashAndLoop(const >> std::basic_string,std::allocator > & >> message="ERROR: LLImageGL::createGLTexture failed to make texture") Line >> 1101 + 0x3 bytes C++ > > Has anyone encountered this before? Do I remember an issue similar to this > previously where the llkdu.dll supplied in the libs tree was out of date? > > Thanks > > Tom > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From tom at streamsense.net Wed Jul 2 12:54:36 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Jul 2 12:56:14 2008 Subject: [sldev] shadow-draft problem In-Reply-To: References: <486BAF96.5080000@streamsense.net> Message-ID: <486BDCFC.2070300@streamsense.net> When I remove llkdu.dll it still falls over.. The thread 'Win32 Thread' (0x1688) has exited with code 0 (0x0). Unhandled exception at 0x006f0a2e in SecondLife.exe: 0xC0000005: Access violation writing location 0x00000000. I'm currently rebuilding with debug info to get some more useful information. Seems like a dereferenced null pointer, or something. Tom. Soft wrote: > The easiest way to test that is to erase or rename llkdu.dll - if > that's absent, the viewer falls back on openjpeg for decoding. > > It is indeed likely that the llkdu is out of sync. In the near future > we're going to stop exporting llkdu in any branch except release > candidate and official release to deal with this kind of problem. In > the long term, we want to remove the dependencies that can make llkdu > incompatible when viewer headers change. > > On Wed, Jul 2, 2008 at 11:40 AM, Thomas Grimshaw wrote: > >> Hi folks, >> >> I'm having some issues with the shadow-draft tree >> (http://svn.secondlife.com/trac/linden/browser/branches/shadow-draft) >> >> All appears to compile perfectly, but on execution the client crashes with >> an error apparently related to llkdu.dll: >> >> >>> SecondLife.exe!LLError::crashAndLoop(const >>> std::basic_string,std::allocator > & >>> message="ERROR: LLImageGL::createGLTexture failed to make texture") Line >>> 1101 + 0x3 bytes C++ >>> >> Has anyone encountered this before? Do I remember an issue similar to this >> previously where the llkdu.dll supplied in the libs tree was out of date? >> >> Thanks >> >> Tom >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> From neil30328 at hotmail.com Wed Jul 2 16:13:05 2008 From: neil30328 at hotmail.com (neil roger) Date: Wed Jul 2 16:13:11 2008 Subject: [sldev] RE: SLDev Digest, Vol 19, Issue 4 In-Reply-To: <20080702190025.505E8113992@stupor.lindenlab.com> References: <20080702190025.505E8113992@stupor.lindenlab.com> Message-ID: yeah. Um so if I wanted to using the sl client and combine it with C# will that be possible or do I need C++.> From: sldev-request@lists.secondlife.com> Subject: SLDev Digest, Vol 19, Issue 4> To: sldev@lists.secondlife.com> Date: Wed, 2 Jul 2008 12:00:25 -0700> > Send SLDev mailing list submissions to> sldev@lists.secondlife.com> > To subscribe or unsubscribe via the World Wide Web, visit> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> or, via email, send a message with subject or body 'help' to> sldev-request@lists.secondlife.com> > You can reach the person managing the list at> sldev-owner@lists.secondlife.com> > When replying, please edit your Subject line so it is more specific> than "Re: Contents of SLDev digest..."> > > Today's Topics:> > 1. Compiling apr (Suzhanna Rossini)> 2. Re: Call for Beta: Aqros Mobile SL messenger (Anders Arnholm)> 3. [AWG] [ANN] pyogp mailing list now available> (Christian Scholz / Tao Takashi (SL))> 4. shadow-draft problem (Thomas Grimshaw)> 5. Scripting Survey (Glenn Fisher)> 6. Re: Scripting Survey (Nik Radford)> > > ----------------------------------------------------------------------> > Message: 1> Date: Wed, 2 Jul 2008 10:02:37 +0200> From: "Suzhanna Rossini" > Subject: [sldev] Compiling apr> To: > Message-ID: <006b01c8dc19$fe8d10d0$fba73270$@rossini@balsaestates.com>> Content-Type: text/plain; charset="UTF-8"> > I'm trying to compile apr, but runs into missing header files for PySQL, Oracle and more..> Are the apr_dbd_* parts needed at all? Or do I have to install all those header files to satisfy the build?> > > > ------------------------------> > Message: 2> Date: Wed, 2 Jul 2008 10:27:59 +0200> From: Anders Arnholm > Subject: Re: [sldev] Call for Beta: Aqros Mobile SL messenger> To: Jason Giglio > Cc: sldev@lists.secondlife.com, Yesha Sivan > Message-ID: <20080702082759.GH19105@arnholm.se>> Content-Type: text/plain; charset=us-ascii> > On Wed, Jul 02, 2008 at 12:03:59AM -0400, Jason Giglio wrote:> > Yesha Sivan wrote:> > > Let me know what you think...> > > > Cool. Is it open source?> > With the follwoing in term:> > Prohibited Uses. You may not, without written permission from us:> > (a) Use, copy, modify, merge or transfer copies of the Software except> as expressly authorized in this Agreement;> > (b) Use any back-up or archival copies of the Software (or allow someone> else to use such copies) for any purpose;> > (c) Disassemble, decompile or "unlock" reverse translate, reverse> engineer or in any manner decode the Software for an reason;> > (d) Sublicense, lease, sell, rent, lend, or otherwise transfer the> Software; or> > (e) Remove or alter any marks or designations indicating the ownership> of copyrights, trademarks or other intellectual property rights of any> party contained in the Software.> > Take not, and I really would have liked a download with out sending my> phone number to them... With a such one one could have figured out if> it's just there sloppy testing or bad Java programing that make the> Sony-Ericsson phone not work.> > / Balp> -- > o_ Anders Arnholm,> o/ /\ anders@arnholm.se> /|_, \\ http://anders.arnholm.se/> /> `> > -- > This message has been scanned for viruses and> dangerous content by MailScanner, and is> believed to be clean.> > > > ------------------------------> > Message: 3> Date: Wed, 2 Jul 2008 13:36:37 +0200> From: "Christian Scholz / Tao Takashi (SL)"> > Subject: [sldev] [AWG] [ANN] pyogp mailing list now available> To: "Second Life Developer Mailing List" > Message-ID:> <23bbb49e0807020436h4a91bed8icc274b6debc0a4c7@mail.gmail.com>> Content-Type: text/plain; charset=ISO-8859-1> > Hi!> > We now have a mailing list dedicated to the development of the pyogp> project which consists of> > - a library for connecting and implementing OGP compatible components> - a test harness for testing OGP compatible components if they are> truely compatible> > and potentially more.> > You can find the mailing list and subscribe to it at> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp> > or if you prefer to use a newsreader for doing so you can subscribe to> > gmane.comp.python.pyogp> > on the server news.gmane.org. You can also access the web interface here:> > http://dir.gmane.org/gmane.comp.python.pyogp> > There are also some messages on it already about the structure so far> and how we go from there. There is also some information now on the> wiki about how we develop, what's being used and what the structure of> the project is. More will be added later. You can find this here:> > https://wiki.secondlife.com/wiki/Pyogp/> > cheers,> > Tao> > -- > Christian Scholz> Tao Takashi (Second Life name)> taotakashi@gmail.com> Blog/Podcast: http://mrtopf.de/blog> Planet: http://worldofsl.com> > Company: http://comlounge.net> Tech Video Blog: http://comlounge.tv> IRC: MrTopf/Tao_T> > > ------------------------------> > Message: 4> Date: Wed, 02 Jul 2008 17:40:54 +0100> From: Thomas Grimshaw > Subject: [sldev] shadow-draft problem> To: Second Life Developer Mailing List > Message-ID: <486BAF96.5080000@streamsense.net>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > Hi folks,> > I'm having some issues with the shadow-draft tree > (http://svn.secondlife.com/trac/linden/browser/branches/shadow-draft)> > All appears to compile perfectly, but on execution the client crashes > with an error apparently related to llkdu.dll:> > > SecondLife.exe!LLError::crashAndLoop(const > std::basic_string,std::allocator > & > message="ERROR: LLImageGL::createGLTexture failed to make texture") > Line 1101 + 0x3 bytes C++> > Has anyone encountered this before? Do I remember an issue similar to > this previously where the llkdu.dll supplied in the libs tree was out of > date?> > Thanks> > Tom> > > > > > ------------------------------> > Message: 5> Date: Wed, 2 Jul 2008 09:49:39 -0700> From: Glenn Fisher > Subject: [sldev] Scripting Survey> To: sldev@lists.secondlife.com> Message-ID: > Content-Type: text/plain; charset="us-ascii"> > Thank you to the many of you who took time to take our scripting > survey - we had almost 250 responses, and its taken a while to sort > through the responses. Here's a topline summary:> > Priority order based on weighting the rankings (the number is the > weighted ranking):> HTTPIn 1569> LLGive..with Confirmation 1506> C#1.0 Scripts 1313> Script Libraries 1305> CollectionClasses 1030> CLI Assemblies 1015> Improved Scheduling 903> Script Resource Limits 786> (If ranked solely by the number of responses to rank #1, Collection > Classes and CLI Assemblies change order, but the rest are the same.> The number of comments varied between 95 and 134, but number of > comments doesn't correlate with ranking.> > Glenn> > Glenn Fisher> Director of Business Programs> Linden Lab> > > > -------------- next part --------------> An HTML attachment was scrubbed...> URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080702/e45d127c/attachment-0001.htm> > ------------------------------> > Message: 6> Date: Wed, 02 Jul 2008 18:00:53 +0100> From: Nik Radford > Subject: Re: [sldev] Scripting Survey> To: Glenn Fisher > Cc: sldev@lists.secondlife.com> Message-ID: <486BB445.2070102@terminaldischarge.net>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > > Pretty much as I expected :)> > Glenn Fisher wrote:> > Thank you to the many of you who took time to take our scripting > > survey - we had almost 250 responses, and its taken a while to sort > > through the responses. Here's a topline summary:> >> > Priority order based on weighting the rankings (the number is the > > weighted ranking):> > HTTPIn 1569> > LLGive..with Confirmation 1506> > C#1.0 Scripts 1313> > Script Libraries 1305> > CollectionClasses 1030> > CLI Assemblies 1015> > Improved Scheduling 903> > Script Resource Limits 786> Still think script resource limits is a big No-No though.> > > (If ranked solely by the number of responses to rank #1, Collection > > Classes and CLI Assemblies change order, but the rest are the same.> > The number of comments varied between 95 and 134, but number of > > comments doesn't correlate with ranking.> >> > Glenn> >> > Glenn Fisher> > Director of Business Programs> > Linden Lab> >> >> >> > ------------------------------------------------------------------------> >> > _______________________________________________> > Policies and (un)subscribe information available here:> > http://wiki.secondlife.com/wiki/SLDev> > Please read the policies before posting to keep unmoderated posting privileges> > > > ------------------------------> > _______________________________________________> SLDev mailing list> SLDev@lists.secondlife.com> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> > > End of SLDev Digest, Vol 19, Issue 4> ************************************ _________________________________________________________________ Enter the Zune-A-Day Giveaway for your chance to win ? day after day after day http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V1 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080702/c4b363af/attachment-0001.htm From darien_caldwell at comcast.net Wed Jul 2 16:21:29 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Wed Jul 2 16:21:47 2008 Subject: [sldev] Scripting Survey (Changed to Bounce Score) References: <486BB445.2070102@terminaldischarge.net> Message-ID: I never received the email below from Glenn. I went and checked my subscription, and it says "We have received some recent bounces from your address. Your current bounce score is 1.0 out of a maximum of 5.0" So what could be causing emails to be bounced? Wasn't having issues before. - Dari ----- Original Message ----- From: "Nik Radford" To: "Glenn Fisher" Cc: Sent: Wednesday, July 02, 2008 10:00 AM Subject: Re: [sldev] Scripting Survey > > Pretty much as I expected :) > > Glenn Fisher wrote: >> Thank you to the many of you who took time to take our scripting >> urvey - we had almost 250 responses, and its taken a while to sort >> through the responses. Here's a topline summary: >> >> Priority order based on weighting the rankings (the number is the >> weighted ranking): >> HTTPIn 1569 >> LLGive..with Confirmation 1506 >> C#1.0 Scripts 1313 >> Script Libraries 1305 >> CollectionClasses 1030 >> CLI Assemblies 1015 >> Improved Scheduling 903 >> Script Resource Limits 786 > Still think script resource limits is a big No-No though. > >> (If ranked solely by the number of responses to rank #1, Collection >> Classes and CLI Assemblies change order, but the rest are the same. >> The number of comments varied between 95 and 134, but number of comments >> doesn't correlate with ranking. >> >> Glenn >> >> Glenn Fisher >> Director of Business Programs >> Linden Lab >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From mrfrans at gmail.com Wed Jul 2 16:59:38 2008 From: mrfrans at gmail.com (Frans) Date: Wed Jul 2 16:59:42 2008 Subject: [sldev] Scripting Survey (Changed to Bounce Score) In-Reply-To: References: <486BB445.2070102@terminaldischarge.net> Message-ID: <7765f2c60807021659u2339b2f6sb3c0ab338a89c202@mail.gmail.com> A full mailbox? Some sort of overactive spam filter? On Thu, Jul 3, 2008 at 1:21 AM, Darien Caldwell wrote: > I never received the email below from Glenn. I went and checked my > subscription, and it says > "We have received some recent bounces from your address. Your current > bounce score is 1.0 out of a maximum of 5.0" > > So what could be causing emails to be bounced? Wasn't having issues before. > > - Dari > > -- Jeroen/Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080703/e2003c53/attachment.htm From nik at terminaldischarge.net Thu Jul 3 01:22:07 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Thu Jul 3 01:22:08 2008 Subject: [sldev] Scripting Survey In-Reply-To: <43F5BDD4-4A25-4DB6-8E6D-9C5BD09F7158@lindenlab.com> References: <486BB445.2070102@terminaldischarge.net> <43F5BDD4-4A25-4DB6-8E6D-9C5BD09F7158@lindenlab.com> Message-ID: <57814.213.106.235.26.1215073327.squirrel@webmail.terminaldischarge.net> Glenn, Thanks for the reply, in reality we already have one pretty big limit, and thats the 16K scripts size limit, which I know is being upped to 64K with mono. I don't suggest removing this limit. This one is fair. However alot of the lag that was caused on sims was due to the poor scheduling of scripts. Where every script was getting a minimum time even when they were idling. So the number of scripts present in the sim became an extremely active part how performance was effected. (correct me if I'm wrong however). I believe improving the scheduler will have a large impact on increasing sim performace where a sim contains alot scripts an imposing limits isn't likely to be needed. Though I'm sure there could be some extreme cases where some sort of limit might be needed. Where I'd suggest making a scripts priority lower in the scheduler (only running its events every couple of frames instead of every single frame) maybe a better idea rather than imposing somesort of wall that disables the script. Let me know your thoughts :) Also going to forward this to the list, see if it can spark a discussion (and hopefully not a flame) :) Nik > Nik, > We got responses that ranged from "Yes!" to "OMG, No way" for Script > Resource Limits. I guess it depends a lot on your style of > developing scripts and your view of how this will impact your work. > Thanks for your participation and response! > Glenn > > On Jul 2, 2008, at 10:00 AM, Nik Radford wrote: > >> >> Pretty much as I expected :) >> >> Glenn Fisher wrote: >>> Thank you to the many of you who took time to take our scripting >>> survey - we had almost 250 responses, and its taken a while to >>> sort through the responses. Here's a topline summary: >>> >>> Priority order based on weighting the rankings (the number is the >>> weighted ranking): >>> HTTPIn 1569 >>> LLGive..with Confirmation 1506 >>> C#1.0 Scripts 1313 >>> Script Libraries 1305 >>> CollectionClasses 1030 >>> CLI Assemblies 1015 >>> Improved Scheduling 903 >>> Script Resource Limits 786 >> Still think script resource limits is a big No-No though. >> >>> (If ranked solely by the number of responses to rank #1, >>> Collection Classes and CLI Assemblies change order, but the rest >>> are the same. >>> The number of comments varied between 95 and 134, but number of >>> comments doesn't correlate with ranking. >>> >>> Glenn >>> >>> Glenn Fisher >>> Director of Business Programs >>> Linden Lab >>> >>> >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated >>> posting privileges >> > > Nik. ------------------------------------------ E-Mail: Nik@Terminaldischarge.net (We)Blog: http://blog.terminaldischarge.net From gigstaggart at gmail.com Thu Jul 3 02:15:43 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 3 02:16:44 2008 Subject: [sldev] Scripting Survey In-Reply-To: <57814.213.106.235.26.1215073327.squirrel@webmail.terminaldischarge.net> References: <486BB445.2070102@terminaldischarge.net> <43F5BDD4-4A25-4DB6-8E6D-9C5BD09F7158@lindenlab.com> <57814.213.106.235.26.1215073327.squirrel@webmail.terminaldischarge.net> Message-ID: <486C98BF.70307@gmail.com> Nik Radford wrote: > However alot of the lag that was caused on sims was due to the poor > scheduling of scripts. Where every script was getting a minimum time even > when they were idling. So the number of scripts present in the sim became > an extremely active part how performance was effected. (correct me if I'm > wrong however). I believe improving the scheduler will have a large impact This is correct. I believe this was encapsulated in the "improved script scheduling" item. On the plus side, idle scripts are using less time now that CPUs are faster, an idle script uses about 0.0015 ms per frame on class 5, compared to 0.003ms on class 4. This is still too much really, a few thousand scripts still cause serious CPU contention. This thread is sort of offtopic, we probably shouldn't let it grow too big. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080703/e25ca223/smime.bin From nik at terminaldischarge.net Thu Jul 3 02:38:22 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Thu Jul 3 02:38:24 2008 Subject: [Fwd: Re: [sldev] Possible solutions for alternatives to imposing hard resouce limits for scripts (Was: Scripting Survey)] Message-ID: <58284.213.106.235.26.1215077902.squirrel@webmail.terminaldischarge.net> (Forgot to post to the list) > Nik Radford wrote: > > However alot of the lag that was caused on sims was due to the poor >> scheduling of scripts. Where every script was getting a minimum time >> even >> when they were idling. So the number of scripts present in the sim >> became >> an extremely active part how performance was effected. (correct me if >> I'm >> wrong however). I believe improving the scheduler will have a large >> impact > > This is correct. I believe this was encapsulated in the "improved > script scheduling" item. > > On the plus side, idle scripts are using less time now that CPUs are > faster, an idle script uses about 0.0015 ms per frame on class 5, > compared to 0.003ms on class 4. Thats good :) Still the script shouldn't see any execution time if it's idle. > > This is still too much really, a few thousand scripts still cause > serious CPU contention. > > This thread is sort of offtopic, we probably shouldn't let it grow too > big. > I've changed the topic to show what I was hoping to discuss. Particually the idea of handling scripts that are resource intensive. A resouce limit suggests to me that the script may be stopped dead if it hits it. Where as I believe it should just be denoted less excution time so as not to impact the rest of the region, effectively giving the script a "time dialation". Though only in extreme cases, where the scheduler can't really spare the time to feed the scripts hunger. Of course if the script is the only one in the sim, then the sim can denote all its allocated frame time (and frames) to running the script. The idea seems feasible. One question, that perhaps a Linden can answer: do individual scripts get allocated the same amount of execution time each frame or is there a larger total execution time that is split (like pie :)) between all scripts on the sim? Of course this is all bearing in mind that the scheduler is rewritten :) Nik. > -Jason > From robin.cornelius at gmail.com Thu Jul 3 04:53:26 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jul 3 04:53:29 2008 Subject: [sldev] Open source meeting, call for items, Thursday 2PM Message-ID: Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda The agenda is current bare. So if you have any items you wish to discuss please add it to the list and see you in Hippotropolis later. Robin From evolutie at gmail.com Thu Jul 3 10:17:45 2008 From: evolutie at gmail.com (evolutie) Date: Thu Jul 3 10:17:48 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces Message-ID: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> Hi, Sunday 6 july at 1 PM PDT at http://slurl.com/secondlife/Odyssey/85/153/45/ there will be a dorkbot session that I think is interesting for many on this list. JJ Ventrella will present the avatar puppeteering project, for which the client code was recently made available to the community. http://www.avatarpuppeteering.com/ Philippe Bossut will present the Segalen / HandsFree3D project. He has developed several demos using 3D camera motion tracking to interface with Second Life, and spent the last weeks on connecting his work to the puppeteering feature. http://www.handsfree3d.com/ This will be a good opportunity to get informed, discuss and ask questions concerning these technologies and features, so I hope to see you all there ;-) More in information and links about the event, projects and presenters can be found at http://rhizomatic.wordpress.com/2008/07/03/dorkbot-session-announcement-4/ chrz, Evo -- http://www.creativemachinery.org From chris.collins at uc.edu Thu Jul 3 11:00:54 2008 From: chris.collins at uc.edu (Chris Collins) Date: Thu Jul 3 11:03:09 2008 Subject: [sldev] SLEDcc 2008 - Meeting 7/8 & Updates In-Reply-To: References: Message-ID: <200807031802.EUP35420@mprelay4.uc.edu> Hi all! I wanted to give a brief update on our progress with the planning for the Second Life Education Community Conference 2008, part of the official Second Life Community Convention taking place in Tampa, FL and in Second Life from September 5 - 7, 2008. First, thank you to everyone who sent a proposal submission! Our reviewers are just wrapping up and we hope to be able to alert everyone as to the status of their proposal by July 8th. Shortly thereafter we'll be able to start putting the program together and I think you will be very excited about the terrific sessions we have in store. Next up, "The Sleddies" Award Competition is about to begin! This competition was conceived as a way to recognize the tremendous efforts of the educational community in Second Life by giving the entire Second Life community an opportunity to vote on the spaces, builds, events, and learning objects that educators have created in-world. We didn't want this to be just a popularity contest, however, so we convened committees of educators who are also experienced in Second Life to create rubrics for the 6 different "strands" or themes of the SLEDcc conference. Please see the Competition Rules and the 6 Strand Rubrics at http://sledcc.wikispaces.com/Sleddies+Competition and start thinking about your submissions! We'll be opening up the submission form shortly and will send more information in a separate communication. For those of you planning to attend SLEDcc08 either in Tampa, FL or in Second Life, we also invite you to join us in our partnership with the RezEd community and begin planning and networking now! We already have a request to share a room in Tampa to help offset costs and if you have other questions, ideas, thoughts, or any suggestions, feel free to post in the SLEDcc08 group on RezEd: http://www.rezed.org/group/sledcc2008 (And while you're there, check out all the other wonderful resources the RezEd folks have put together for educators in virtual worlds - great stuff!) And last but not least, we invite you to join us at our next planning meeting this coming Tuesday, July 8th, at 1PM SLT in our temporary home in the Chilbo sim: http://slurl.com/secondlife/Chilbo/167/129/109 We will have a map of the facilities layout of the conference space in Tampa, ask for your feedback on The Sleddies voting kiosks, distribute posters, banners and other objects that you can put up to help spread the word about SLEDcc08 at your own in-world locations, and help answer any questions you may have about the conference. We especially hope anyone who already has or who might want to volunteer for either the Tampa or in-world SLEDcc08 will join us, as we have a number of positions left to fill! See http://sledcc.wikispaces.com/Volunteer+Opportunities for more information. Have a wonderful holiday weekend and hope to see you next Tuesday! Sincerely, - Chris/Fleep On behalf of.. Chris Collins (SL: Fleep Tuque) Hilary Mason (SL: Ann Enigma) Jennifer Ragan-Fore (SL: Kittygloom Cassidy) Jonathon Richter (SL: Wainbrave Bernal) Co-Chairs, Second Life Education Community Conference 2008 Member of the Second Life Community Convention 2008 http://sledcc.wikispaces.com sledcc08@googlegroups.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080703/9df731fa/attachment.htm From alissa_sabre at yahoo.co.jp Thu Jul 3 19:21:06 2008 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Thu Jul 3 19:21:15 2008 Subject: [sldev] Req. for review of a new wiki page Message-ID: <1edikwve54s0G7LwwkJ4GJk.alissa_sabre@yahoo.co.jp> Reading some recent discussion on the viewer build process and its wiki explanation, I considered writing this: http://wiki.secondlife.com/wiki/Is_it_up_to_date%3F The page is primarily for reference from viewer build process pages, but I wrote it more general contexts in mind. Commends and/or edits are welcome. Alissa Sabre -------------------------------------- Stop! Global Warming ~ Yahoo! JAPAN Earth Project http://pr.mail.yahoo.co.jp/earthproject/ From me at signpostmarv.name Thu Jul 3 19:38:34 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Thu Jul 3 19:38:40 2008 Subject: [sldev] Req. for review of a new wiki page In-Reply-To: <1edikwve54s0G7LwwkJ4GJk.alissa_sabre@yahoo.co.jp> References: <1edikwve54s0G7LwwkJ4GJk.alissa_sabre@yahoo.co.jp> Message-ID: <486D8D2A.1090804@signpostmarv.name> I don't suppose there's a MediaWiki extension that gives user-level toggle of per-article alerts indicating an article is "stale" ? global toggle may be too obtrusive, but avid wikipedians may find it more useful when clicking Special:Random of course, I could always put together a greasemonkey script that moves/clones the last modification date to the top of the page to be more noticeable :-P ~ Marv. alissa_sabre@yahoo.co.jp wrote: > Reading some recent discussion on the viewer build process and its > wiki explanation, I considered writing this: > > http://wiki.secondlife.com/wiki/Is_it_up_to_date%3F > > The page is primarily for reference from viewer build process pages, > but I wrote it more general contexts in mind. > > Commends and/or edits are welcome. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080704/e5daa882/smime.bin From lenglish5 at cox.net Thu Jul 3 23:32:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jul 3 23:32:30 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> Message-ID: <486DC3FB.6030002@cox.net> evolutie wrote: > Hi, > > Sunday 6 july at 1 PM PDT at > http://slurl.com/secondlife/Odyssey/85/153/45/ there will be a dorkbot > session that I think is interesting for many on this list. > > JJ Ventrella will present the avatar puppeteering project, for which > the client code was recently made available to the community. > http://www.avatarpuppeteering.com/ > Philippe Bossut will present the Segalen / HandsFree3D project. He has > developed several demos using 3D camera motion tracking to interface > with Second Life, and spent the last weeks on connecting his work to > the puppeteering feature. > http://www.handsfree3d.com/ > > This will be a good opportunity to get informed, discuss and ask > questions concerning these technologies and features, so I hope to see > you all there ;-) > More in information and links about the event, projects and presenters > can be found at > http://rhizomatic.wordpress.com/2008/07/03/dorkbot-session-announcement-4/ > > chrz, > Evo > > > Definitely try to be there. And... I'd like to point out that a "pointing device" is probably not the best way to do real-time animation control. 3D mocap using a 3D camera might be the most sexy, but there's always multiple keypresses (especially on a Mac), and dare I mention MIDI keyboards? I could see an infinite number of non-mocap interfaces possible for this technology, such as the animation equivalent of stroke-based font creation, http://www.macintouch.com/gaiji.html, where fundamental units of animation movement would mapped to individual keys on a computer or MIDI keyboard and evoked by sequences of simple or chorded keypresses. Velocity from a MIDI keyboard could corresspond to range of motion, for example, while each "note" would correspond to a specific motion or set of motions. Playback using MIDI would be possible, and tracks for "avatar animation" could be combined with audible MIDI tracks to create a new form of dance animation with accompaniment, which could be minutes or even hours long, given the relative compression of MIDI over sound or even XML. No doubt other input technologies could be devised as well. Perhaps, rather than trying to figure out a one-size fits all strategy, or even a handful, the best thing to do would be to devise a plug-in architecture to control the overall system? And of course, should LL ever get around to defining non-humanoid, non-BVH-driven avatars and animation, the system should allow for extensions to handle that as well. L From fire at eslteacherlink.co.kr Fri Jul 4 00:32:03 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Fri Jul 4 00:32:08 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <486DC3FB.6030002@cox.net> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> <486DC3FB.6030002@cox.net> Message-ID: <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> The puppetering branch is really exciting. Way to go LL for releasing it to the Dev community. After seeing Jonnhy Lee's head tracking video, I'm wondering it if we could strap a wii remote to each wrist, one on our LCD monitor, wear a head tracking lights, and have full puppeteering control using our own bodies, and -- fancy C# programming of course...... Im sure you've already seen Johnny Lee's videos, but here they are again - and a few other links truly amazing stuff - *Head Tracking* http://youtube.com/watch?v=Jd3-eiid-Uw http://youtube.com/watch?v=DGJ4zu9fAkk *Wii Remote C# Links* http://churchcrosstalk.typepad.com/jonedmiston/2008/06/c-wii-remote-fu.html* *Interface for Virtual Earth http://blogs.msdn.com/coding4fun/archive/2007/10/18/5506286.aspx* Wii Remote Drivers *http://www.wiili.org/index.php/Wiimote_driver* **CAVE VR System* http://www.visualgenomics.ca/index.php?option=com_content&task=view&id=120&Itemid=207 http://www.cave.vt.edu/ http://youtube.com/watch?v=N6NN5JKlIi0 *Holographic Projection* http://www.ubiqwindow.jp/ http:/youtube.com/watch?v=WLconRxEyzc On Fri, Jul 4, 2008 at 3:32 PM, Lawson English wrote: > evolutie wrote: > >> Hi, >> >> Sunday 6 july at 1 PM PDT at >> http://slurl.com/secondlife/Odyssey/85/153/45/ there will be a dorkbot >> session that I think is interesting for many on this list. >> >> JJ Ventrella will present the avatar puppeteering project, for which >> the client code was recently made available to the community. >> http://www.avatarpuppeteering.com/ >> Philippe Bossut will present the Segalen / HandsFree3D project. He has >> developed several demos using 3D camera motion tracking to interface >> with Second Life, and spent the last weeks on connecting his work to >> the puppeteering feature. >> http://www.handsfree3d.com/ >> >> This will be a good opportunity to get informed, discuss and ask >> questions concerning these technologies and features, so I hope to see >> you all there ;-) >> More in information and links about the event, projects and presenters >> can be found at >> http://rhizomatic.wordpress.com/2008/07/03/dorkbot-session-announcement-4/ >> >> chrz, >> Evo >> >> >> >> > Definitely try to be there. And... I'd like to point out that a "pointing > device" is probably not the best way to do real-time animation control. 3D > mocap using a 3D camera might be the most sexy, but there's always multiple > keypresses (especially on a Mac), and dare I mention MIDI keyboards? > > I could see an infinite number of non-mocap interfaces possible for this > technology, such as the animation equivalent of stroke-based font creation, > http://www.macintouch.com/gaiji.html, where fundamental units of animation > movement would mapped to individual keys on a computer or MIDI keyboard and > evoked by sequences of simple or chorded keypresses. Velocity from a MIDI > keyboard could corresspond to range of motion, for example, while each > "note" would correspond to a specific motion or set of motions. Playback > using MIDI would be possible, and tracks for "avatar animation" could be > combined with audible MIDI tracks to create a new form of dance animation > with accompaniment, which could be minutes or even hours long, given the > relative compression of MIDI over sound or even XML. > > > > No doubt other input technologies could be devised as well. Perhaps, rather > than trying to figure out a one-size fits all strategy, or even a handful, > the best thing to do would be to devise a plug-in architecture to control > the overall system? And of course, should LL ever get around to defining > non-humanoid, non-BVH-driven avatars and animation, the system should allow > for extensions to handle that as well. > > > > > L > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Paul Preibisch Creative Director B3D Media Labs Ltd. Seoul, South Korea Facebook Second Life Link Application: http://www.facebook.com/applications/Second_Life_Link/10242435556 Skype: eslteacherlink.com Second Life Id: Fire Centaur English Village SLURL: http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& Facebook Groups: Second Life for Educators: http://www.f8.facebook.com/group.php?gid=2387164946 Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080704/f80cb392/attachment.htm From me at signpostmarv.name Fri Jul 4 00:37:38 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jul 4 00:37:44 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> <486DC3FB.6030002@cox.net> <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> Message-ID: <486DD342.1080602@signpostmarv.name> Fire in Korea wrote: > The puppetering branch is really exciting. Way to go LL for releasing > it to the Dev community. > > After seeing Jonnhy Lee's head tracking video, I'm wondering it if we > could strap a wii remote to each wrist, one on our LCD monitor, wear a > head tracking lights, and have full puppeteering control using our own > bodies, and -- fancy C# programming of course...... Since most people aren't ambidextrous, wouldn't wiimote + nunchuck be suitable for most purposes ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080704/d360bc07/smime-0001.bin From fire at eslteacherlink.co.kr Fri Jul 4 01:51:34 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Fri Jul 4 01:51:38 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <486DD342.1080602@signpostmarv.name> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> <486DC3FB.6030002@cox.net> <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> <486DD342.1080602@signpostmarv.name> Message-ID: <1dabc2a30807040151i3ca6488akade444c4952e03fb@mail.gmail.com> hmm, good point! On Fri, Jul 4, 2008 at 4:37 PM, SignpostMarv Martin wrote: > Fire in Korea wrote: > >> The puppetering branch is really exciting. Way to go LL for releasing it >> to the Dev community. >> >> After seeing Jonnhy Lee's head tracking video, I'm wondering it if we >> could strap a wii remote to each wrist, one on our LCD monitor, wear a head >> tracking lights, and have full puppeteering control using our own bodies, >> and -- fancy C# programming of course...... >> > > Since most people aren't ambidextrous, wouldn't wiimote + nunchuck be > suitable for most purposes ? > > > ~ Marv. > -- Paul Preibisch Creative Director B3D Media Labs Ltd. Seoul, South Korea Facebook Second Life Link Application: http://www.facebook.com/applications/Second_Life_Link/10242435556 Skype: eslteacherlink.com Second Life Id: Fire Centaur English Village SLURL: http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& Facebook Groups: Second Life for Educators: http://www.f8.facebook.com/group.php?gid=2387164946 Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080704/e2a133b2/attachment.htm From me at signpostmarv.name Fri Jul 4 06:58:18 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Jul 4 06:58:22 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <1dabc2a30807040151i3ca6488akade444c4952e03fb@mail.gmail.com> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> <486DC3FB.6030002@cox.net> <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> <486DD342.1080602@signpostmarv.name> <1dabc2a30807040151i3ca6488akade444c4952e03fb@mail.gmail.com> Message-ID: <486E2C7A.5040902@signpostmarv.name> Do note that you'd probably need to go via GlovePIE + PPJoy for Wiimote control, unless you wanted someone to write a native Wiimote driver. Fire in Korea wrote: > hmm, good point! > > On Fri, Jul 4, 2008 at 4:37 PM, SignpostMarv Martin > > wrote: > > Fire in Korea wrote: > > The puppetering branch is really exciting. Way to go LL for > releasing it to the Dev community. > > After seeing Jonnhy Lee's head tracking video, I'm wondering > it if we could strap a wii remote to each wrist, one on our > LCD monitor, wear a head tracking lights, and have full > puppeteering control using our own bodies, and -- fancy C# > programming of course...... > > > Since most people aren't ambidextrous, wouldn't wiimote + nunchuck > be suitable for most purposes ? > > > ~ Marv. > > > > > -- > Paul Preibisch > Creative Director > > B3D Media Labs Ltd. > Seoul, South Korea > Facebook Second Life Link Application: > http://www.facebook.com/applications/Second_Life_Link/10242435556 > Skype: eslteacherlink.com > Second Life Id: Fire Centaur > English Village SLURL: > http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& > > > Facebook Groups: > Second Life for Educators: > http://www.f8.facebook.com/group.php?gid=2387164946 > Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080704/d474cf17/smime.bin From fire at eslteacherlink.co.kr Fri Jul 4 07:23:42 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Fri Jul 4 07:23:45 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <486E2C7A.5040902@signpostmarv.name> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> <486DC3FB.6030002@cox.net> <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> <486DD342.1080602@signpostmarv.name> <1dabc2a30807040151i3ca6488akade444c4952e03fb@mail.gmail.com> <486E2C7A.5040902@signpostmarv.name> Message-ID: <1dabc2a30807040723y5eccb9d1jcdcebf9ddc448087@mail.gmail.com> I found a good link on GlovePIE here - Im dashing on my scooter to the Electronics district here in Seoul tomorrow morning to pick up a Wii remote!!! http://carl.kenner.googlepages.com/glovepie On Fri, Jul 4, 2008 at 10:58 PM, SignpostMarv Martin wrote: > Do note that you'd probably need to go via GlovePIE + PPJoy for Wiimote > control, unless you wanted someone to write a native Wiimote driver. > > Fire in Korea wrote: > >> hmm, good point! >> >> On Fri, Jul 4, 2008 at 4:37 PM, SignpostMarv Martin > me@signpostmarv.name>> wrote: >> >> Fire in Korea wrote: >> >> The puppetering branch is really exciting. Way to go LL for >> releasing it to the Dev community. >> >> After seeing Jonnhy Lee's head tracking video, I'm wondering >> it if we could strap a wii remote to each wrist, one on our >> LCD monitor, wear a head tracking lights, and have full >> puppeteering control using our own bodies, and -- fancy C# >> programming of course...... >> >> >> Since most people aren't ambidextrous, wouldn't wiimote + nunchuck >> be suitable for most purposes ? >> >> >> ~ Marv. >> >> >> >> >> -- >> Paul Preibisch >> Creative Director >> >> B3D Media Labs Ltd. >> Seoul, South Korea >> Facebook Second Life Link Application: >> http://www.facebook.com/applications/Second_Life_Link/10242435556 >> Skype: eslteacherlink.com >> Second Life Id: Fire Centaur >> English Village SLURL: >> http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village&< >> http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& >> > >> >> Facebook Groups: >> Second Life for Educators: >> http://www.f8.facebook.com/group.php?gid=2387164946 >> Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 >> > -- Paul Preibisch Creative Director B3D Media Labs Ltd. Seoul, South Korea Facebook Second Life Link Application: http://www.facebook.com/applications/Second_Life_Link/10242435556 Skype: eslteacherlink.com Second Life Id: Fire Centaur English Village SLURL: http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& Facebook Groups: Second Life for Educators: http://www.f8.facebook.com/group.php?gid=2387164946 Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080704/b41c78a2/attachment.htm From robla at lindenlab.com Sun Jul 6 21:46:39 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Jul 6 21:46:45 2008 Subject: [sldev] Nominations so far for Hippo awards Message-ID: <1215405999.9341.22.camel@oopsy.hsd1.wa.comcast.net> Hi everyone, I'd like everyone to make sure that the community recognizes the most qualified people for the Hippos this year. This is a great set of nominees so far, but I'm sure there are other people that deserve recognition. Be sure to nominate people *in every category you think they are qualified for*. Don't sell your nominee short by only nominating in a single category. For example, I think the "Best Community Influence" category has a couple of great candidates, but I'd be very surprised if everyone in the community thinks that these are the only two candidates worthy of consideration. So, please, get your nominations in before the deadline on Tuesday, July 8, at noon PDT. Here's a list of the nominations so far, with links to the issues in JIRA where we're accepting nominations. Best Documentation http://jira.secondlife.com/browse/MISC-1301 * SignpostMarv Martin * Asuka Neely * Strife Onizuka * Gally Young? * Day Oh * Saijanai Kuhn * Catherine Pfeffer Best Project Organizer http://jira.secondlife.com/browse/MISC-1302 * Lex Neva * McCabe Maxsted * Harleen Gretzky * Strife Onizuka Best Contribution http://jira.secondlife.com/browse/MISC-1303 * Mm Alder * Ellla McMahon * Gellan Glenelg * JB Kraft * tangletwigs fairymeadow * Able Whitman * Seg Baphomet * Marine Kelley * Realxtend development team * Nicholaz Beresford Best Community Influence (Jesse Malthus Award) http://jira.secondlife.com/browse/MISC-1304 * Zha Ewry * Lex Neva Contributor of the Year ?http://jira.secondlife.com/browse/MISC-1305 * Gigs Taggart * Harleen Gretzky * Alissa Sabre * Carjay McGinnis * Maxwolfe Goodliffe * Fox Diller * Whoops Babii * Michelle2 Zenovka * Marine Kelley * Nicholaz Beresford From suzhanna.rossini at balsaestates.com Mon Jul 7 12:05:23 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Mon Jul 7 12:05:34 2008 Subject: [sldev] Unresolved externals Message-ID: <00a101c8e064$69278c10$3b76a430$@rossini@balsaestates.com> I'm trying to build the client with VS2008, and everything works smooth and fine up to linking, I get this no matter how I try: 3>Linking... 3>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(class std::basic_string,class std::allocator > const &,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) 3>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) Anyone with ideas please? Currently I'm using a svn pull of "Release", r732. From evolutie at gmail.com Mon Jul 7 15:03:17 2008 From: evolutie at gmail.com (evolutie) Date: Mon Jul 7 15:03:20 2008 Subject: [sldev] dorkbot meeting avatar puppeteering and physical interfaces In-Reply-To: <1dabc2a30807040723y5eccb9d1jcdcebf9ddc448087@mail.gmail.com> References: <5fb4b1fa0807031017k721f6bebtb9dad4b9f9e00e2d@mail.gmail.com> <486DC3FB.6030002@cox.net> <1dabc2a30807040032u1d9bc0f6l756c3f39a7294120@mail.gmail.com> <486DD342.1080602@signpostmarv.name> <1dabc2a30807040151i3ca6488akade444c4952e03fb@mail.gmail.com> <486E2C7A.5040902@signpostmarv.name> <1dabc2a30807040723y5eccb9d1jcdcebf9ddc448087@mail.gmail.com> Message-ID: <5fb4b1fa0807071503u5791795v552781e0280ca1ca@mail.gmail.com> Hi, Here's a report on yesterdays dorkbot session. http://rhizomatic.wordpress.com/2008/07/07/report-on-the-dorkbot-meeting-of-6-july/ Because of the enthousiasm of people wanting further development of these technologies, I created a group called "Avatar Puppeteers". It's open to join :-) chrZ, evo On Fri, Jul 4, 2008 at 4:23 PM, Fire in Korea wrote: > I found a good link on GlovePIE here - Im dashing on my scooter to the > Electronics district here in Seoul tomorrow morning to pick up a Wii > remote!!! > > http://carl.kenner.googlepages.com/glovepie > > On Fri, Jul 4, 2008 at 10:58 PM, SignpostMarv Martin > wrote: >> >> Do note that you'd probably need to go via GlovePIE + PPJoy for Wiimote >> control, unless you wanted someone to write a native Wiimote driver. >> >> Fire in Korea wrote: >>> >>> hmm, good point! >>> >>> On Fri, Jul 4, 2008 at 4:37 PM, SignpostMarv Martin >> > wrote: >>> >>> Fire in Korea wrote: >>> >>> The puppetering branch is really exciting. Way to go LL for >>> releasing it to the Dev community. >>> >>> After seeing Jonnhy Lee's head tracking video, I'm wondering >>> it if we could strap a wii remote to each wrist, one on our >>> LCD monitor, wear a head tracking lights, and have full >>> puppeteering control using our own bodies, and -- fancy C# >>> programming of course...... >>> >>> >>> Since most people aren't ambidextrous, wouldn't wiimote + nunchuck >>> be suitable for most purposes ? >>> >>> >>> ~ Marv. >>> >>> >>> >>> >>> -- >>> Paul Preibisch >>> Creative Director >>> >>> B3D Media Labs Ltd. >>> Seoul, South Korea >>> Facebook Second Life Link Application: >>> http://www.facebook.com/applications/Second_Life_Link/10242435556 >>> Skype: eslteacherlink.com >>> Second Life Id: Fire Centaur >>> English Village SLURL: >>> http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& >>> >>> >>> Facebook Groups: >>> Second Life for Educators: >>> http://www.f8.facebook.com/group.php?gid=2387164946 >>> Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 > > > > -- > Paul Preibisch > Creative Director > > B3D Media Labs Ltd. > Seoul, South Korea > Facebook Second Life Link Application: > http://www.facebook.com/applications/Second_Life_Link/10242435556 > Skype: eslteacherlink.com > Second Life Id: Fire Centaur > English Village SLURL: > http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& > > Facebook Groups: > Second Life for Educators: > http://www.f8.facebook.com/group.php?gid=2387164946 > Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- http://www.creativemachinery.org From mumismo at gmail.com Mon Jul 7 19:07:08 2008 From: mumismo at gmail.com (Jordi Polo) Date: Mon Jul 7 19:07:17 2008 Subject: [sldev] about openjpeg Message-ID: I've just downloaded and trying to compile the viewer source. I have noticed that it uses the openjpeg library version 1.1 It exists a 1.3 version what supposedly is much faster. I just wanted to point it out just in case you don't keep track of outside libraries (viewer is big enough to be very busy coding!) -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080708/9addba85/attachment.htm From gigstaggart at gmail.com Mon Jul 7 23:06:45 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 7 23:06:57 2008 Subject: [sldev] about openjpeg In-Reply-To: References: Message-ID: <487303F5.9050306@gmail.com> Jordi Polo wrote: > I've just downloaded and trying to compile the viewer source. > I have noticed that it uses the openjpeg library version 1.1 It exists a > 1.3 version what supposedly is much faster. I just wanted to point it out > just in case you don't keep track of outside libraries (viewer is big enough > to be very busy coding!) Jordi, I think I hear you volunteering to do some benchmarks :P The way I understand it 1.3 is mainly improved for GIS uses, with a few speedups that would affect SL too. If you could run some side-by-side tests with the type of decoding the SL client does, that would be very cool. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080708/3ff1604a/smime.bin From gigstaggart at gmail.com Tue Jul 8 03:13:10 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 8 03:13:21 2008 Subject: [sldev] cmake weirdness Message-ID: <48733DB6.7010601@gmail.com> I think something is broken with cmake/develop.py now. When I tell develop.py to just generate the build files, it starts downloading a bunch of stuff I already have from Amazon. What's up with that? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080708/02b83c37/smime.bin From soft at lindenlab.com Tue Jul 8 06:35:25 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 8 06:35:27 2008 Subject: [sldev] cmake weirdness In-Reply-To: <48733DB6.7010601@gmail.com> References: <48733DB6.7010601@gmail.com> Message-ID: On Tue, Jul 8, 2008 at 5:13 AM, Jason Giglio wrote: > I think something is broken with cmake/develop.py now. When I tell > develop.py to just generate the build files, it starts downloading a > bunch of stuff I already have from Amazon. > > What's up with that? Which branch are you working in? The new cmake setup pulls individual library bundles as needed - we're phasing out the single giant library tarballs. The cmake scripts cache these locally so that as libraries are updated or as you switch between branches, only the libs that you're using for the first time will need to be downloaded. From wuhanzymail at 163.com Tue Jul 8 08:19:31 2008 From: wuhanzymail at 163.com (Ying Zhong) Date: Tue Jul 8 08:19:46 2008 Subject: [sldev] Fatal error when running SL client 1.20 Message-ID: <48738583.1090901@163.com> Hi guys, I downloaded Branch_1-20-Viewer-2-r90824 and had it compiled successfully. But when I try to run it under "ReleaseNoOpt" there is an fatal error says: ERROR:LLImageGL::createGLTexture failed to make texture There was one email talked about this error before but there was no solutions for this error. So, would anyone give me some suggestions? I will be appreciated for that very much! Best Regards, Ying From aimee at ama-zing.co.uk Tue Jul 8 09:38:17 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jul 8 09:38:32 2008 Subject: [sldev] XML files AWOL Message-ID: <1049D407-DF16-47C7-AA1E-BDA215AF2649@ama-zing.co.uk> Did someone forget to add the xui files to Branch_1-20-Viewer-2 in their new location when doing the skinning stuff ... or am I just being too impatient? :) Seems to be broken at the moment. Aimee. From soft at lindenlab.com Tue Jul 8 09:59:28 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 8 09:59:31 2008 Subject: [sldev] XML files AWOL In-Reply-To: <1049D407-DF16-47C7-AA1E-BDA215AF2649@ama-zing.co.uk> References: <1049D407-DF16-47C7-AA1E-BDA215AF2649@ama-zing.co.uk> Message-ID: On Tue, Jul 8, 2008 at 11:38 AM, Aimee Walton wrote: > Did someone forget to add the xui files to Branch_1-20-Viewer-2 in their new > location when doing the skinning stuff ... or am I just being too impatient? > :) Seems to be broken at the moment. I didn't know the skinning went into 1.20 - if it did, I'd bet they didn't update the export files. I'll have a look. From chris.collins at uc.edu Tue Jul 8 12:40:20 2008 From: chris.collins at uc.edu (Chris Collins) Date: Tue Jul 8 12:38:30 2008 Subject: [sldev] SLEDcc Meeting Today @ 1PM SLT In-Reply-To: <7.1.0.9.2.20080703133627.0796dd68@uc.edu> References: <7.1.0.9.2.20080703133627.0796dd68@uc.edu> Message-ID: <200807081938.EPM65839@mprelay3.uc.edu> Hi all, Reminder: Please join the SLEDcc planning meeting today at 1PM SLT in our temporary home in the Chilbo sim: http://slurl.com/secondlife/Chilbo/167/129/109 We will have a map of the facilities layout of the conference space in Tampa, ask for your feedback on The Sleddies voting kiosks, distribute posters, banners and other objects that you can put up to help spread the word about SLEDcc08 at your own in-world locations, and help answer any questions you may have about the conference. We especially hope anyone who already has or who might want to volunteer for either the Tampa or in-world SLEDcc08 will join us, as we have a number of positions left to fill! See http://sledcc.wikispaces.com/Volunteer+Opportunities for more information. Thanks and hope to see you soon! - Chris/Fleep Chris Collins (SL: Fleep Tuque) Co-Chair, Second Life Education Community Conference 2008 Member of the Second Life Community Convention 2008 http://sledcc.wikispaces.com sledcc08@googlegroups.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080708/cfb0d356/attachment.htm From sllists at boroon.dasgupta.ch Tue Jul 8 12:43:52 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jul 8 12:43:58 2008 Subject: [sldev] [HELP] CMake: Version 2.5 of Python required; Problem with missing directory 'indra/viewer-linux-i686' Message-ID: <4873C378.1010802@boroon.dasgupta.ch> Hi all, After reading that it now handles library downloads by itself, I decided to give cmake another try. (Before that, I didn't know where to place the downloaded libraries relative to the build tree and didn't want to guess.) I svn up'ed my checkout of the "release" branch (to revision 738) and run ./develop.py from the indra directory. First I noticed I had to upgrade Python from 2.4 to 2.5, otherwise it would be missing ElementTree and the uuid module (and maybe more). Should this be mentioned at http://wiki.secondlife.com/wiki/CMake? After upgrading I got the following: > ~/slsrc/svn/release/linden/indra $ *./develop.py* > Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -G > \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE > -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" > \'/home//slsrc/svn/release/linden/indra\'' in > 'viewer-linux-i686' > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Check size of void* > -- Check size of void* - done > -- Check for working CXX compiler: /usr/bin/g++ > -- Check for working CXX compiler: /usr/bin/g++ -- works > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/ogg-vorbis-1.03-1.1.2-linux-20080613.tar.bz2 > to local file > /var/tmpinstall.cache/ogg-vorbis-1.03-1.1.2-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/ogg-vorbis-1.03-1.1.2-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/apr_suite-1.2.8-linux-20080618.tar.bz2 > to local file > /var/tmp//install.cache/apr_suite-1.2.8-linux-20080618.tar.bz2 > Extracting > /var/tmp//install.cache/apr_suite-1.2.8-linux-20080618.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.32.0-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/boost-1.32.0-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/boost-1.32.0-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/expat-1.95.8-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/expat-1.95.8-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/expat-1.95.8-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/zlib-1.1.4-linux-20080618.tar.bz2 > to local file > /var/tmp//install.cache/zlib-1.1.4-linux-20080618.tar.bz2 > Extracting > /var/tmp//install.cache/zlib-1.1.4-linux-20080618.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/ares-1.3.0-linux-20080618.tar.bz2 > to local file > /var/tmp//install.cache/ares-1.3.0-linux-20080618.tar.bz2 > Extracting > /var/tmp//install.cache/ares-1.3.0-linux-20080618.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/curl-7.16.0-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/curl-7.16.0-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/curl-7.16.0-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/openSSL-0.9.7c-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/openSSL-0.9.7c-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/openSSL-0.9.7c-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/xmlrpc-epi-0.51-linux-20080618.tar.bz2 > to local file > /var/tmp//install.cache/xmlrpc-epi-0.51-linux-20080618.tar.bz2 > Extracting > /var/tmp//install.cache/xmlrpc-epi-0.51-linux-20080618.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/jpeglib-6b-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/jpeglib-6b-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/jpeglib-6b-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/libpng-1.2.18-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/libpng-1.2.18-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/libpng-1.2.18-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/openjpeg-1.2-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/openjpeg-1.2-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/openjpeg-1.2-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/gstreamer-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/gstreamer-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/gstreamer-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/libxml-2.6.24-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/libxml-2.6.24-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/libxml-2.6.24-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/GL-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/GL-linux-20080613.tar.bz2 to > /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/glh_linear-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/glh_linear-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/glh_linear-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/SDL-1.2.5-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/SDL-1.2.5-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/SDL-1.2.5-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/mesa-7.0-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/mesa-7.0-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/mesa-7.0-linux-20080613.tar.bz2 to > /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/llmozlib-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/llmozlib-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/llmozlib-linux-20080613.tar.bz2 to > /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/freetype-2.1.5-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/freetype-2.1.5-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/freetype-2.1.5-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/gtk-atk-pango-glib-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/gtk-atk-pango-glib-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/gtk-atk-pango-glib-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/elfio-1.0.3-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/elfio-1.0.3-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/elfio-1.0.3-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so > -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so > - found > -- Looking for gethostbyname > -- Looking for gethostbyname - found > -- Looking for connect > -- Looking for connect - found > -- Looking for remove > -- Looking for remove - found > -- Looking for shmat > -- Looking for shmat - found > -- Looking for IceConnectionNumber in ICE > -- Looking for IceConnectionNumber in ICE - found > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/ndofdev-linux-20080618.tar.bz2 > to local file > /var/tmp//install.cache/ndofdev-linux-20080618.tar.bz2 > Extracting > /var/tmp//install.cache/ndofdev-linux-20080618.tar.bz2 to > /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/libstdc++-6.0-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/libstdc++-6.0-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/libstdc++-6.0-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/libuuid-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/libuuid-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/libuuid-linux-20080613.tar.bz2 to > /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/vivox-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/vivox-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/vivox-linux-20080613.tar.bz2 to > /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > Downloading > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/fontconfig-2.2.3-linux-20080613.tar.bz2 > to local file > /var/tmp//install.cache/fontconfig-2.2.3-linux-20080613.tar.bz2 > Extracting > /var/tmp//install.cache/fontconfig-2.2.3-linux-20080613.tar.bz2 > to /home//slsrc/svn/release/linden > Writing state to /home//slsrc/svn/release/linden/installed.xml > *CMake Error: Cannot find source file > "/home/**/slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/attentions.xml"* > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: CMake failed to properly look up cmSourceFile: > character/attentions.xml > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/attentionsN.xml" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: CMake failed to properly look up cmSourceFile: > character/attentionsN.xml > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/avatar_lad.xml" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: CMake failed to properly look up cmSourceFile: > character/avatar_lad.xml > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/avatar_skeleton.xml" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: CMake failed to properly look up cmSourceFile: > character/avatar_skeleton.xml > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/genepool.xml" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: CMake failed to properly look up cmSourceFile: > character/genepool.xml > -- Version of viewer is 1.20.11.0 > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/newview/character/attentions.xml" > for target "secondlife-bin" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/newview/character/attentionsN.xml" > for target "secondlife-bin" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/newview/character/avatar_lad.xml" > for target "secondlife-bin" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/newview/character/avatar_skeleton.xml" > for target "secondlife-bin" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > CMake Error: Cannot find source file > "/home//slsrc/svn/release/linden/indra/newview/character/genepool.xml" > for target "secondlife-bin" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm > .hpp .hxx .in .txx > -- Configuring done > Cleaning 'viewer-linux-i686' > Traceback (most recent call last): > File "./develop.py", line 664, in > main(sys.argv[1:]) > File "./develop.py", line 637, in main > setup.run_cmake() > File "./develop.py", line 155, in run_cmake > self.run(cmd, 'cmake') > File "./develop.py", line 135, in run > (name, event, status)) > __main__.CommandError: the command 'cmake' exited with status 255 [replaced my user name with and marked the first error line with bold face] The directory indra/viewer-linux-i686 doesn't exist, but I also can't find any file named attentions.xml anywhere else in the tree. Any idea what might be wrong? Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080708/681547df/attachment-0001.htm From secret.argent at gmail.com Tue Jul 8 13:32:06 2008 From: secret.argent at gmail.com (Argent) Date: Tue Jul 8 13:32:09 2008 Subject: [sldev] Google data exchange format Message-ID: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> Just announced on slashdot: http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html A fast, compact IDL that's got a well-tested open-source implementation and is an order of magnitude faster than XML? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080708/8e5a90d1/attachment.htm From jacek.antonelli at gmail.com Tue Jul 8 13:50:02 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Tue Jul 8 13:50:07 2008 Subject: [sldev] Req. for peer review: Convert Advanced menu to XUI Message-ID: <105c09f0807081350g61a7701o86c998f05b2b7064@mail.gmail.com> I've spent the past 2 days updating my work on VWR-2896 (http://jira.secondlife.com/browse/VWR-2896) to apply to the menus on the latest RCs. I've checked it pretty thoroughly, but it's a big change, so some extra eyes would be appreciated. In particular, I want to make sure that the patches apply cleanly for other people. I did all the development on this with Git, and this is the first patch I've generated from that, so I want to make sure it's good. == NOTES 1. Applies to version 1.20 RC12 w/ mods The work is based off 1.20 RC12, but with my cleaned-up menu XML (http://jira.secondlife.com/browse/VWR-8056). I don't think the xui_advanced_menu patch will apply to the original messy menu. You can save yourself some trouble by just dropping in the attached menu_viewer.xml into skins/xui/en-us/; it has the clean menus with the patch already applied. 2. Replicates original menus as closely as possible If I did my job right, the XUIfied menu should look at behave the same as the old menu. The only exception to this is that "Rendering > HTTP Get Textures" is visible in the XUI menus, whereas it had been conditionally disabled at compile time in the original menus. It could be commented out of the XML if you like. 3. Yeah, you have to compile it Sorry, it won't work by just dropping in the XML file. You'll have to (re)compile the viewer, since the callback classes are written in C++ by necessity. == CHANGES -- advanced_menu_callbacks...patch.txt: 1. Disables the C++ from generating its own Advanced menu (or else there'd be a duplicate). 2. Adds a lot of small callback classes. Generally, these are one-to-one with the menu items, except thaht: - Toggle items each have two classes, one for toggling and one for updating the checkbox on the menu. - Very-closely related items (e.g. the various render types) are grouped together into the same class(es). 3. Registers event listeners. Maps the classes to functions that can be called from XUI. -- xui_advanced_menu...patch.txt: 1. Adds the XML for the Advanced menu. == WHAT TO CHECK 1. That the patch applies cleanly. 2. That the menus do what they should. (I've checked and re-checked this, but it never hurts to have more eyes.) Regards, - Jacek -------------- next part -------------- --- linden/indra/newview/llviewermenu.cpp +++ linden/indra/newview/llviewermenu.cpp @@ -750,10 +750,13 @@ void init_menus() gLandmarkMenu = menu; */ + // Advanced (Client) menu is XUI now! \o/ + /* menu = new LLMenuGL(CLIENT_MENU_NAME); init_client_menu(menu); gMenuBarView->appendMenu( menu ); menu->updateParent(LLMenuGL::sMenuContainer); + */ menu = new LLMenuGL(SERVER_MENU_NAME); init_server_menu(menu); @@ -7720,6 +7723,2118 @@ class LLWorldDayCycle : public view_listener_t + +//------------------------------------------------------------------- +// Advanced menu +//------------------------------------------------------------------- + + +/////////////////// +// SHOW CONSOLES // +/////////////////// + + +class LLAdvancedToggleConsole : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString console_type = userdata.asString(); + if ("frame" == console_type) + { + toggle_visibility( (void*)gDebugView->mFrameStatView ); + } + else if ("texture" == console_type) + { + toggle_visibility( (void*)gTextureView ); + } + else if ("debug" == console_type) + { + toggle_visibility( (void*)((LLView*)gDebugView->mDebugConsolep) ); + } + else if ("fast timers" == console_type) + { + toggle_visibility( (void*)gDebugView->mFastTimerView ); + } + else if ("memory" == console_type) + { + toggle_visibility( (void*)gDebugView->mMemoryView ); + } + return true; + } +}; + + +class LLAdvancedCheckConsole : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString console_type = userdata["data"].asString(); + bool new_value = false; + if ("frame" == console_type) + { + new_value = get_visibility( (void*)gDebugView->mFrameStatView ); + } + else if ("texture" == console_type) + { + new_value = get_visibility( (void*)gTextureView ); + } + else if ("debug" == console_type) + { + new_value = get_visibility( (void*)((LLView*)gDebugView->mDebugConsolep) ); + } + else if ("fast timers" == console_type) + { + new_value = get_visibility( (void*)gDebugView->mFastTimerView ); + } + else if ("memory" == console_type) + { + new_value = get_visibility( (void*)gDebugView->mMemoryView ); + } + + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////////// +// DUMP INTO TO CONSOLE // +////////////////////////// + + +class LLAdvancedDumpInfoToConsole : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString info_type = userdata.asString(); + if ("region" == info_type) + { + handle_region_dump_settings(NULL); + } + else if ("group" == info_type) + { + handle_dump_group_info(NULL); + } + else if ("capabilities" == info_type) + { + handle_dump_capabilities_info(NULL); + } + return true; + } +}; + + + +/////////////////////////////// +// RELOAD SETTINGS OVERRIDES // +/////////////////////////////// + + +class LLAdvancedReloadSettingsOverrides : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + reload_personal_settings_overrides(NULL); + return true; + } +}; + + + +////////////// +// HUD INFO // +////////////// + + +class LLAdvancedToggleHUDInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString info_type = userdata.asString(); + if ("velocity" == info_type) + { + toggle_visibility( (void*)gVelocityBar ); + } + else if ("camera" == info_type) + { + gDisplayCameraPos = !(gDisplayCameraPos); + } + else if ("wind" == info_type) + { + gDisplayWindInfo = !(gDisplayWindInfo); + } + else if ("fov" == info_type) + { + gDisplayFOV = !(gDisplayFOV); + } + return true; + } +}; + +class LLAdvancedCheckHUDInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString info_type = userdata["data"].asString(); + bool new_value = false; + if ("velocity" == info_type) + { + new_value = get_visibility( (void*)gVelocityBar ); + } + else if ("camera" == info_type) + { + new_value = gDisplayCameraPos; + } + else if ("wind" == info_type) + { + new_value = gDisplayWindInfo; + } + else if ("fov" == info_type) + { + new_value = gDisplayFOV; + } + + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + + return true; + } +}; + + + +/////////////////////// +// CLEAR GROUP CACHE // +/////////////////////// + + +class LLAdvancedClearGroupCache : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLGroupMgr::debugClearAllGroups(NULL); + return true; + } +}; + + + + +///////////////// +// RENDER TYPE // +///////////////// + + +U32 render_type_from_string(LLString render_type) +{ + if ("simple" == render_type) + { + return LLPipeline::RENDER_TYPE_SIMPLE; + } + else if ("alpha" == render_type) + { + return LLPipeline::RENDER_TYPE_ALPHA; + } + else if ("tree" == render_type) + { + return LLPipeline::RENDER_TYPE_TREE; + } + else if ("avatar" == render_type) + { + return LLPipeline::RENDER_TYPE_AVATAR; + } + else if ("terrain" == render_type) + { + return LLPipeline::RENDER_TYPE_TERRAIN; + } + else if ("sky" == render_type) + { + return LLPipeline::RENDER_TYPE_SKY; + } + else if ("water" == render_type) + { + return LLPipeline::RENDER_TYPE_WATER; + } + else if ("ground" == render_type) + { + return LLPipeline::RENDER_TYPE_GROUND; + } + else if ("volume" == render_type) + { + return LLPipeline::RENDER_TYPE_VOLUME; + } + else if ("grass" == render_type) + { + return LLPipeline::RENDER_TYPE_GRASS; + } + else if ("clouds" == render_type) + { + return LLPipeline::RENDER_TYPE_CLOUDS; + } + else if ("particles" == render_type) + { + return LLPipeline::RENDER_TYPE_PARTICLES; + } + else if ("bump" == render_type) + { + return LLPipeline::RENDER_TYPE_BUMP; + } + else + { + return 0; + } +} + + +class LLAdvancedToggleRenderType : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + U32 render_type = render_type_from_string( userdata.asString() ); + if ( render_type != 0 ) + { + LLPipeline::toggleRenderTypeControl( (void*)render_type ); + } + return true; + } +}; + + +class LLAdvancedCheckRenderType : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + U32 render_type = render_type_from_string( userdata["data"].asString() ); + bool new_value = false; + + if ( render_type != 0 ) + { + new_value = LLPipeline::hasRenderTypeControl( (void*)render_type ); + } + + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////// +// FEATURE // +///////////// + + +U32 feature_from_string(LLString feature) +{ + if ("ui" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_UI; + } + else if ("selected" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_SELECTED; + } + else if ("highlighted" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_HIGHLIGHTED; + } + else if ("dynamic textures" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_DYNAMIC_TEXTURES; + } + else if ("foot shadows" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_FOOT_SHADOWS; + } + else if ("fog" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_FOG; + } + else if ("palette" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_PALETTE; + } + else if ("fr info" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_FR_INFO; + } + else if ("flexible" == feature) + { + return LLPipeline::RENDER_DEBUG_FEATURE_FLEXIBLE; + } + else + { + return 0; + } +}; + + +class LLAdvancedToggleFeature : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + U32 feature = feature_from_string( userdata.asString() ); + + if ( feature != 0 ) + { + LLPipeline::toggleRenderDebugFeature( (void*)feature ); + } + + return true; + } +}; + + +class LLAdvancedCheckFeature : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + U32 feature = feature_from_string( userdata["data"].asString() ); + bool new_value = false; + + if ( feature != 0 ) + { + new_value = LLPipeline::toggleRenderDebugFeatureControl( (void*)feature ); + } + + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////// +// INFO DISPLAY // +////////////////// + + +U32 info_display_from_string(LLString info_display) +{ + if ("verify" == info_display) + { + return LLPipeline::RENDER_DEBUG_VERIFY; + } + else if ("bboxes" == info_display) + { + return LLPipeline::RENDER_DEBUG_BBOXES; + } + else if ("points" == info_display) + { + return LLPipeline::RENDER_DEBUG_POINTS; + } + else if ("octree" == info_display) + { + return LLPipeline::RENDER_DEBUG_OCTREE; + } + else if ("occlusion" == info_display) + { + return LLPipeline::RENDER_DEBUG_OCCLUSION; + } + else if ("render batches" == info_display) + { + return LLPipeline::RENDER_DEBUG_BATCH_SIZE; + } + else if ("texture anim" == info_display) + { + return LLPipeline::RENDER_DEBUG_TEXTURE_ANIM; + } + else if ("texture priority" == info_display) + { + return LLPipeline::RENDER_DEBUG_TEXTURE_PRIORITY; + } + else if ("shame" == info_display) + { + return LLPipeline::RENDER_DEBUG_SHAME; + } + else if ("texture area" == info_display) + { + return LLPipeline::RENDER_DEBUG_TEXTURE_AREA; + } + else if ("face area" == info_display) + { + return LLPipeline::RENDER_DEBUG_FACE_AREA; + } + else if ("picking" == info_display) + { + return LLPipeline::RENDER_DEBUG_PICKING; + } + else if ("lights" == info_display) + { + return LLPipeline::RENDER_DEBUG_LIGHTS; + } + else if ("particles" == info_display) + { + return LLPipeline::RENDER_DEBUG_PARTICLES; + } + else if ("composition" == info_display) + { + return LLPipeline::RENDER_DEBUG_COMPOSITION; + } + else if ("glow" == info_display) + { + return LLPipeline::RENDER_DEBUG_GLOW; + } + else + { + return 0; + } +}; + + +class LLAdvancedToggleInfoDisplay : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + U32 info_display = info_display_from_string( userdata.asString() ); + + if ( info_display != 0 ) + { + LLPipeline::toggleRenderDebug( (void*)info_display ); + } + + return true; + } +}; + + +class LLAdvancedCheckInfoDisplay : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + U32 info_display = info_display_from_string( userdata["data"].asString() ); + bool new_value = false; + + if ( info_display != 0 ) + { + new_value = LLPipeline::toggleRenderDebugControl( (void*)info_display ); + } + + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////// +// SELECT BUFFER // +/////////////////// + + +class LLAdvancedToggleSelectBuffer : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gDebugSelect = !(gDebugSelect); + return true; + } +}; + +class LLAdvancedCheckSelectBuffer : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gDebugSelect; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////////// +// RANDOMIZE FRAMERATE // +///////////////////////// + + +class LLAdvancedToggleRandomizeFramerate : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gRandomizeFramerate = !(gRandomizeFramerate); + return true; + } +}; + +class LLAdvancedCheckRandomizeFramerate : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gRandomizeFramerate; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////////// +// PERIODIC SLOW FRAME // +///////////////////////// + + +class LLAdvancedTogglePeriodicSlowFrame : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gPeriodicSlowFrame = !(gPeriodicSlowFrame); + return true; + } +}; + +class LLAdvancedCheckPeriodicSlowFrame : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gPeriodicSlowFrame; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////// +// FRAME TEST // +//////////////// + + +class LLAdvancedToggleFrameTest : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLPipeline::sRenderFrameTest = !(LLPipeline::sRenderFrameTest); + return true; + } +}; + +class LLAdvancedCheckFrameTest : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLPipeline::sRenderFrameTest; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////////// +// HIDE SELECTED OBJECTS // +/////////////////////////// + + +class LLAdvancedToggleHideSelectedObjects : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gHideSelectedObjects = !(gHideSelectedObjects); + return true; + } +}; + +class LLAdvancedCheckHideSelectedObjects : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gHideSelectedObjects; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////////// +// SELECTED TEXTURE INFO // +/////////////////////////// + + +class LLAdvancedSelectedTextureInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_selected_texture_info(NULL); + return true; + } +}; + + + +////////////////////// +// TOGGLE WIREFRAME // +////////////////////// + + +class LLAdvancedToggleWireframe : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gUseWireframe = !(gUseWireframe); + return true; + } +}; + +class LLAdvancedCheckWireframe : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gUseWireframe; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////// +// DISABLE TEXTURES // +////////////////////// + + +class LLAdvancedToggleDisableTextures : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + menu_toggle_variable((void*)&LLViewerImage::sDontLoadVolumeTextures); + return true; + } +}; + +class LLAdvancedCheckDisableTextures : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = menu_check_variable((void*)&LLViewerImage::sDontLoadVolumeTextures); + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////////// +// DUMP SCRIPTED CAMERA // +////////////////////////// + + +class LLAdvancedDumpScriptedCamera : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_dump_followcam(NULL); + return true; + } +}; + + + +////////////////////////////// +// DUMP REGION OBJECT CACHE // +////////////////////////////// + + +class LLAdvancedDumpRegionObjectCache : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_dump_region_object_cache(NULL); + return true; + } +}; + + + +//////////////// +// SLURL TEST // +//////////////// + + +class LLAdvancedSLURLTest : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_slurl_test(NULL); + return true; + } +}; + + + +//////////////////////// +// TOGGLE EDITABLE UI // +//////////////////////// + + +class LLAdvancedToggleEditableUI : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + edit_ui(NULL); + return true; + } +}; + +// *TODO: Add corresponding "Check" for EditableUI, so it can +// become a menu_item_check. Need to add check_edit_ui(void*) +// or functional equivalent to do that. + + + +////////////////////// +// ASYNC KEYSTROKES // +////////////////////// + + +class LLAdvancedToggleAsyncKeystrokes : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gHandleKeysAsync = !(gHandleKeysAsync); + return true; + } +}; + +class LLAdvancedCheckAsyncKeystrokes : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gHandleKeysAsync; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////// +// DUMP SELECT MGR // +///////////////////// + + +class LLAdvancedDumpSelectMgr : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + dump_select_mgr(NULL); + return true; + } +}; + + + +//////////////////// +// DUMP INVENTORY // +//////////////////// + + +class LLAdvancedDumpInventory : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + dump_inventory(NULL); + return true; + } +}; + + + +/////////////////////// +// DUMP FOCUS HOLDER // +/////////////////////// + + +class LLAdvancedDumpFocusHolder : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_dump_focus(NULL); + return true; + } +}; + + + +//////////////////////////////// +// PRINT SELECTED OBJECT INFO // +//////////////////////////////// + + +class LLAdvancedPrintSelectedObjectInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + print_object_info(NULL); + return true; + } +}; + + + +////////////////////// +// PRINT AGENT INFO // +////////////////////// + + +class LLAdvancedPrintAgentInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + print_agent_nvpairs(NULL); + return true; + } +}; + + + +//////////////////////////////// +// PRINT TEXTURE MEMORY STATS // +//////////////////////////////// + + +class LLAdvancedPrintTextureMemoryStats : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + output_statistics(NULL); + return true; + } +}; + + + +////////////////////// +// DEBUG SELECT MGR // +////////////////////// + + +class LLAdvancedToggleDebugSelectMgr : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gDebugSelectMgr = !(gDebugSelectMgr); + return true; + } +}; + +class LLAdvancedCheckDebugSelectMgr : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gDebugSelectMgr; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////// +// DEBUG CLICKS // +////////////////// + + +class LLAdvancedToggleDebugClicks : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gDebugClicks = !(gDebugClicks); + return true; + } +}; + +class LLAdvancedCheckDebugClicks : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gDebugClicks; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////// +// DEBUG VIEWS // +///////////////// + + +class LLAdvancedToggleDebugViews : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLView::sDebugRects = !(LLView::sDebugRects); + return true; + } +}; + +class LLAdvancedCheckDebugViews : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLView::sDebugRects; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////// +// XUI NAME TOOLTIPS // +/////////////////////// + + +class LLAdvancedToggleXUINameTooltips : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + toggle_show_xui_names(NULL); + return true; + } +}; + +class LLAdvancedCheckXUINameTooltips : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = check_show_xui_names(NULL); + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////////////// +// DEBUG MOUSE EVENTS // +//////////////////////// + + +class LLAdvancedToggleDebugMouseEvents : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLView::sDebugMouseHandling = !(LLView::sDebugMouseHandling); + return true; + } +}; + +class LLAdvancedCheckDebugMouseEvents : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLView::sDebugMouseHandling; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////// +// DEBUG KEYS // +//////////////// + + +class LLAdvancedToggleDebugKeys : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLView::sDebugKeys = !(LLView::sDebugKeys); + return true; + } +}; + +class LLAdvancedCheckDebugKeys : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLView::sDebugKeys; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////// +// DEBUG WINDOW PROC // +/////////////////////// + + +class LLAdvancedToggleDebugWindowProc : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gDebugWindowProc = !(gDebugWindowProc); + return true; + } +}; + +class LLAdvancedCheckDebugWindowProc : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gDebugWindowProc; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////////////////// +// DEBUG TEXT EDITOR TIPS // +//////////////////////////// + + +class LLAdvancedToggleDebugTextEditorTips : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gDebugTextEditorTips = !(gDebugTextEditorTips); + return true; + } +}; + +class LLAdvancedCheckDebugTextEditorTips : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gDebugTextEditorTips; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////// +// SHOW FLOATER TEST // +/////////////////////// + + +class LLAdvancedShowFloaterTest : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLFloaterTest::show(NULL); + return true; + } +}; + + + +///////////////////////// +// EXPORT MENUS TO XML // +///////////////////////// + + +class LLAdvancedExportMenusToXML : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_export_menus_to_xml(NULL); + return true; + } +}; + + + +///////////// +// EDIT UI // +///////////// + + +class LLAdvancedEditUI : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLFloaterEditUI::show(NULL); + return true; + } +}; + + + +////////////////////// +// LOAD UI FROM XML // +////////////////////// + + +class LLAdvancedLoadUIFromXML : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_load_from_xml(NULL); + return true; + } +}; + + + +//////////////////// +// SAVE UI TO XML // +//////////////////// + + +class LLAdvancedSaveUIToXML : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_save_to_xml(NULL); + return true; + } +}; + + + +/////////////// +// XUI NAMES // +/////////////// + + +class LLAdvancedToggleXUINames : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + toggle_show_xui_names(NULL); + return true; + } +}; + +class LLAdvancedCheckXUINames : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = check_show_xui_names(NULL); + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////////////// +// GRAB BAKED TEXTURE // +//////////////////////// + + +class LLAdvancedGrabBakedTexture : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString texture_type = userdata.asString(); + if ("eyes" == texture_type) + { + handle_grab_texture( (void*)LLVOAvatar::TEX_EYES_BAKED ); + } + else if ("head" == texture_type) + { + handle_grab_texture( (void*)LLVOAvatar::TEX_HEAD_BAKED ); + } + else if ("upper" == texture_type) + { + handle_grab_texture( (void*)LLVOAvatar::TEX_UPPER_BAKED ); + } + else if ("lower" == texture_type) + { + handle_grab_texture( (void*)LLVOAvatar::TEX_SKIRT_BAKED ); + } + else if ("skirt" == texture_type) + { + handle_grab_texture( (void*)LLVOAvatar::TEX_SKIRT_BAKED ); + } + + return true; + } +}; + +class LLAdvancedEnableGrabBakedTexture : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString texture_type = userdata["data"].asString(); + bool new_value = false; + + if ("iris" == texture_type) + { + new_value = enable_grab_texture( (void*)LLVOAvatar::TEX_EYES_BAKED ); + } + else if ("head" == texture_type) + { + new_value = enable_grab_texture( (void*)LLVOAvatar::TEX_HEAD_BAKED ); + } + else if ("upper" == texture_type) + { + new_value = enable_grab_texture( (void*)LLVOAvatar::TEX_UPPER_BAKED ); + } + else if ("lower" == texture_type) + { + new_value = enable_grab_texture( (void*)LLVOAvatar::TEX_LOWER_BAKED ); + } + else if ("skirt" == texture_type) + { + new_value = enable_grab_texture( (void*)LLVOAvatar::TEX_SKIRT_BAKED ); + } + + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////// +// ALLOW IDLE / AFK // +////////////////////// + + +class LLAdvancedToggleAllowIdleAFK : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gAllowIdleAFK = !(gAllowIdleAFK); + return true; + } +}; + +class LLAdvancedCheckAllowIdleAFK : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gAllowIdleAFK; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////// +// APPEARANCE TO XML // +/////////////////////// + + +class LLAdvancedAppearanceToXML : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLVOAvatar::dumpArchetypeXML(NULL); + return true; + } +}; + + + +/////////////////////////////// +// TOGGLE CHARACTER GEOMETRY // +/////////////////////////////// + + +class LLAdvancedToggleCharacterGeometry : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_god_request_avatar_geometry(NULL); + return true; + } +}; + +class LLAdvancedEnableCharacterGeometry : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + enable_god_customer_service(NULL); + return true; + } +}; + + + +///////////////////////////// +// TEST MALE / TEST FEMALE // +///////////////////////////// + + +class LLAdvancedTestMale : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_test_male(NULL); + return true; + } +}; + + +class LLAdvancedTestFemale : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_test_female(NULL); + return true; + } +}; + + + +/////////////// +// TOGGLE PG // +/////////////// + + +class LLAdvancedTogglePG : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_toggle_pg(NULL); + return true; + } +}; + + + +///////////////////////// +// ALLOW SELECT AVATAR // +///////////////////////// + + +class LLAdvancedToggleAllowSelectAvatar : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gAllowSelectAvatar = !(gAllowSelectAvatar); + return true; + } +}; + +class LLAdvancedCheckAllowSelectAvatar : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gAllowSelectAvatar; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////////////////// +// ALLOW TAP-TAP-HOLD RUN // +//////////////////////////// + + +class LLAdvancedToggleAllowTapTapHoldRun : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gAllowTapTapHoldRun = !(gAllowTapTapHoldRun); + return true; + } +}; + +class LLAdvancedCheckAllowTapTapHoldRun : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gAllowTapTapHoldRun; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////////////// +// FORCE PARAMS TO DEFAULT // +///////////////////////////// + + +class LLAdvancedForceParamsToDefault : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLAgent::clearVisualParams(NULL); + return true; + } +}; + + + +////////////////////////// +// RELOAD VERTEX SHADER // +////////////////////////// + + +class LLAdvancedReloadVertexShader : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + reload_vertex_shader(NULL); + return true; + } +}; + + + +//////////////////// +// ANIMATION INFO // +//////////////////// + + +class LLAdvancedToggleAnimationInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLVOAvatar::sShowAnimationDebug = !(LLVOAvatar::sShowAnimationDebug); + return true; + } +}; + +class LLAdvancedCheckAnimationInfo : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLVOAvatar::sShowAnimationDebug; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////////////////// +// SLOW MOTION ANIMATIONS // +//////////////////////////// + + +class LLAdvancedToggleSlowMotionAnimations : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + slow_mo_animations(NULL); + return true; + } +}; + +// *TODO: Add a corresponding "Check" event for SlowMotionAnimations, +// so that it can become a menu_item_check with the "X" indicator. +// See indra/newview/skins/xui/en_us/menu_viewer.xml + + + +////////////////// +// SHOW LOOK AT // +////////////////// + + +class LLAdvancedToggleShowLookAt : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLHUDEffectLookAt::sDebugLookAt = !(LLHUDEffectLookAt::sDebugLookAt); + return true; + } +}; + +class LLAdvancedCheckShowLookAt : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLHUDEffectLookAt::sDebugLookAt; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////// +// SHOW POINT AT // +/////////////////// + + +class LLAdvancedToggleShowPointAt : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLHUDEffectPointAt::sDebugPointAt = !(LLHUDEffectPointAt::sDebugPointAt); + return true; + } +}; + +class LLAdvancedCheckShowPointAt : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLHUDEffectPointAt::sDebugPointAt; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////////// +// DEBUG JOINT UPDATES // +///////////////////////// + + +class LLAdvancedToggleDebugJointUpdates : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLVOAvatar::sJointDebug = !(LLVOAvatar::sJointDebug); + return true; + } +}; + +class LLAdvancedCheckDebugJointUpdates : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLVOAvatar::sJointDebug; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////// +// DISABLE LOD // +///////////////// + + +class LLAdvancedToggleDisableLOD : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLViewerJoint::sDisableLOD = !(LLViewerJoint::sDisableLOD); + return true; + } +}; + +class LLAdvancedCheckDisableLOD : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLViewerJoint::sDisableLOD; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////////// +// DEBUG CHARACTER VIS // +///////////////////////// + + +class LLAdvancedToggleDebugCharacterVis : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLVOAvatar::sDebugInvisible = !(LLVOAvatar::sDebugInvisible); + return true; + } +}; + +class LLAdvancedCheckDebugCharacterVis : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLVOAvatar::sDebugInvisible; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////////// +// SHOW COLLISION PLANE // +////////////////////////// + +/*************************** + * + * Disabled. See DEV-14477 + * + *************************** + +class LLAdvancedToggleShowCollisionPlane : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLVOAvatar::sShowFootPlane = !(LLVOAvatar::sShowFootPlane); + return true; + } +}; + +class LLAdvancedCheckShowCollisionPlane : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLVOAvatar::sShowFootPlane; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + +***************************/ + + +///////////////////////////// +// SHOW COLLISION SKELETON // +///////////////////////////// + + +class LLAdvancedToggleShowCollisionSkeleton : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLVOAvatar::sShowCollisionVolumes = !(LLVOAvatar::sShowCollisionVolumes); + return true; + } +}; + +class LLAdvancedCheckShowCollisionSkeleton : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLVOAvatar::sShowCollisionVolumes; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////////// +// DISPLAY AGENT TARGET // +////////////////////////// + + +class LLAdvancedToggleDisplayAgentTarget : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLAgent::sDebugDisplayTarget = !(LLAgent::sDebugDisplayTarget); + return true; + } +}; + +class LLAdvancedCheckDisplayAgentTarget : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLAgent::sDebugDisplayTarget; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +/////////////////////////// +// DEBUG AVATAR ROTATION // +/////////////////////////// + + +class LLAdvancedToggleDebugAvatarRotation : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gDebugAvatarRotation = !(gDebugAvatarRotation); + return true; + } +}; + +class LLAdvancedCheckDebugAvatarRotation : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gDebugAvatarRotation; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////////// +// DUMP ATTACHMENTS // +////////////////////// + + +class LLAdvancedDumpAttachments : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_dump_attachments(NULL); + return true; + } +}; + + + +///////////////////// +// REBAKE TEXTURES // +///////////////////// + + +class LLAdvancedRebakeTextures : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_rebake_textures(NULL); + return true; + } +}; + + + +/////////////////////////// +// DEBUG AVATAR TEXTURES // +/////////////////////////// + + +class LLAdvancedDebugAvatarTextures : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_debug_avatar_textures(NULL); + return true; + } +}; + + + +//////////////////////////////// +// DUMP AVATAR LOCAL TEXTURES // +//////////////////////////////// + + +class LLAdvancedDumpAvatarLocalTextures : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_dump_avatar_local_textures(NULL); + return true; + } +}; + + + +///////////////// +// MESSAGE LOG // +///////////////// + + +class LLAdvancedEnableMessageLog : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_viewer_enable_message_log(NULL); + return true; + } +}; + +class LLAdvancedDisableMessageLog : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_viewer_disable_message_log(NULL); + return true; + } +}; + + + +///////////////// +// DROP PACKET // +///////////////// + + +class LLAdvancedDropPacket : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + drop_packet(NULL); + return true; + } +}; + + + +///////////////////////// +// FRAME STATS LOGGING // +///////////////////////// + + +class LLAdvancedFrameStatsLogging : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString command = userdata.asString(); + if ("start logging" == command) + { + LLFrameStats::startLogging(NULL); + } + else if ("stop logging" == command) + { + LLFrameStats::stopLogging(NULL); + } + else if ("timed logging 10" == command) + { + LLFrameStats::timedLogging10(NULL); + } + else if ("timed logging 30" == command) + { + LLFrameStats::timedLogging30(NULL); + } + else if ("timed logging 60" == command) + { + LLFrameStats::timedLogging60(NULL); + } + + return true; + } +}; + + + +///////////////// +// AGENT PILOT // +///////////////// + + +class LLAdvancedAgentPilot : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLString command = userdata.asString(); + if ("start playback" == command) + { + LLAgentPilot::startPlayback(NULL); + } + else if ("stop playback" == command) + { + LLAgentPilot::stopPlayback(NULL); + } + else if ("start record" == command) + { + LLAgentPilot::startRecord(NULL); + } + else if ("stop record" == command) + { + LLAgentPilot::saveRecord(NULL); + } + + return true; + } +}; + + + +////////////////////// +// AGENT PILOT LOOP // +////////////////////// + + +class LLAdvancedToggleAgentPilotLoop : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLAgentPilot::sLoop = !(LLAgentPilot::sLoop); + return true; + } +}; + +class LLAdvancedCheckAgentPilotLoop : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = LLAgentPilot::sLoop; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +///////////////////////// +// SHOW OBJECT UPDATES // +///////////////////////// + + +class LLAdvancedToggleShowObjectUpdates : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + gShowObjectUpdates = !(gShowObjectUpdates); + return true; + } +}; + +class LLAdvancedCheckShowObjectUpdates : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = gShowObjectUpdates; + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +//////////////////// +// COMPRESS IMAGE // +//////////////////// + + +class LLAdvancedCompressImage : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_compress_image(NULL); + return true; + } +}; + + + +////////////////////// +// CLOTHING FLOATER // +////////////////////// + + +class LLAdvancedToggleClothingFloater : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_clothing(NULL); + return true; + } +}; + +// There is no LLAdvancedCheckClothingFloater. + + + +///////////////////////// +// SHOW DEBUG SETTINGS // +///////////////////////// + + +class LLAdvancedShowDebugSettings : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLFloaterSettingsDebug::show(NULL); + return true; + } +}; + + + +//////////////////////// +// VIEW ADMIN OPTIONS // +//////////////////////// + + +class LLAdvancedToggleViewAdminOptions : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_admin_override_toggle(NULL); + return true; + } +}; + +class LLAdvancedCheckViewAdminOptions : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + bool new_value = check_admin_override(NULL); + LLString control_name = userdata["control"].asString(); + gMenuHolder->findControl(control_name)->setValue(new_value); + return true; + } +}; + + + +////////////////// +// ADMIN STATUS // +////////////////// + + +class LLAdvancedRequestAdminStatus : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_god_mode(NULL); + return true; + } +}; + +class LLAdvancedLeaveAdminStatus : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + handle_leave_god_mode(NULL); + return true; + } +}; + + + static void addMenu(view_listener_t *menu, const char *name) { sMenus.push_back(menu); @@ -7928,4 +10043,155 @@ void initialize_menus() addMenu(new LLSomethingSelected(), "SomethingSelected"); addMenu(new LLSomethingSelectedNoHUD(), "SomethingSelectedNoHUD"); addMenu(new LLEditableSelected(), "EditableSelected"); + + + // Advanced (top level menu) + addMenu(new LLAdvancedToggleConsole(), "Advanced.ToggleConsole"); + addMenu(new LLAdvancedCheckConsole(), "Advanced.CheckConsole"); + addMenu(new LLAdvancedDumpInfoToConsole(), "Advanced.DumpInfoToConsole"); + addMenu(new LLAdvancedReloadSettingsOverrides(), "Advanced.ReloadSettingsOverrides"); + + // Advanced > HUD Info + addMenu(new LLAdvancedToggleHUDInfo(), "Advanced.ToggleHUDInfo"); + addMenu(new LLAdvancedCheckHUDInfo(), "Advanced.CheckHUDInfo"); + + addMenu(new LLAdvancedClearGroupCache(), "Advanced.ClearGroupCache"); + + // Advanced > Render > Types + addMenu(new LLAdvancedToggleRenderType(), "Advanced.ToggleRenderType"); + addMenu(new LLAdvancedCheckRenderType(), "Advanced.CheckRenderType"); + + // Advanced > Render > Features + addMenu(new LLAdvancedToggleFeature(), "Advanced.ToggleFeature"); + addMenu(new LLAdvancedCheckFeature(), "Advanced.CheckFeature"); + + // Advanced > Render > Info Displays + addMenu(new LLAdvancedToggleInfoDisplay(), "Advanced.ToggleInfoDisplay"); + addMenu(new LLAdvancedCheckInfoDisplay(), "Advanced.CheckInfoDisplay"); + addMenu(new LLAdvancedToggleSelectBuffer(), "Advanced.ToggleSelectBuffer"); + addMenu(new LLAdvancedCheckSelectBuffer(), "Advanced.CheckSelectBuffer"); + addMenu(new LLAdvancedToggleRandomizeFramerate(), "Advanced.ToggleRandomizeFramerate"); + addMenu(new LLAdvancedCheckRandomizeFramerate(), "Advanced.CheckRandomizeFramerate"); + addMenu(new LLAdvancedTogglePeriodicSlowFrame(), "Advanced.TogglePeriodicSlowFrame"); + addMenu(new LLAdvancedCheckPeriodicSlowFrame(), "Advanced.CheckPeriodicSlowFrame"); + addMenu(new LLAdvancedToggleFrameTest(), "Advanced.ToggleFrameTest"); + addMenu(new LLAdvancedCheckFrameTest(), "Advanced.CheckFrameTest"); + addMenu(new LLAdvancedToggleHideSelectedObjects(), "Advanced.ToggleHideSelectedObjects"); + addMenu(new LLAdvancedCheckHideSelectedObjects(), "Advanced.CheckHideSelectedObjects"); + addMenu(new LLAdvancedSelectedTextureInfo(), "Advanced.SelectedTextureInfo"); + addMenu(new LLAdvancedToggleWireframe(), "Advanced.ToggleWireframe"); + addMenu(new LLAdvancedCheckWireframe(), "Advanced.CheckWireframe"); + addMenu(new LLAdvancedToggleDisableTextures(), "Advanced.ToggleDisableTextures"); + addMenu(new LLAdvancedCheckDisableTextures(), "Advanced.CheckDisableTextures"); + + // Advanced > World + addMenu(new LLAdvancedDumpScriptedCamera(), "Advanced.DumpScriptedCamera"); + addMenu(new LLAdvancedDumpRegionObjectCache(), "Advanced.DumpRegionObjectCache"); + + // Advanced > UI + addMenu(new LLAdvancedSLURLTest(), "Advanced.SLURLTest"); + addMenu(new LLAdvancedToggleEditableUI(), "Advanced.ToggleEditableUI"); + //addMenu(new LLAdvancedCheckEditableUI(), "Advanced.CheckEditableUI"); + addMenu(new LLAdvancedToggleAsyncKeystrokes(), "Advanced.ToggleAsyncKeystrokes"); + addMenu(new LLAdvancedCheckAsyncKeystrokes(), "Advanced.CheckAsyncKeystrokes"); + addMenu(new LLAdvancedDumpSelectMgr(), "Advanced.DumpSelectMgr"); + addMenu(new LLAdvancedDumpInventory(), "Advanced.DumpInventory"); + addMenu(new LLAdvancedDumpFocusHolder(), "Advanced.DumpFocusHolder"); + addMenu(new LLAdvancedPrintSelectedObjectInfo(), "Advanced.PrintSelectedObjectInfo"); + addMenu(new LLAdvancedPrintAgentInfo(), "Advanced.PrintAgentInfo"); + addMenu(new LLAdvancedPrintTextureMemoryStats(), "Advanced.PrintTextureMemoryStats"); + addMenu(new LLAdvancedToggleDebugSelectMgr(), "Advanced.ToggleDebugSelectMgr"); + addMenu(new LLAdvancedCheckDebugSelectMgr(), "Advanced.CheckDebugSelectMgr"); + addMenu(new LLAdvancedToggleDebugClicks(), "Advanced.ToggleDebugClicks"); + addMenu(new LLAdvancedCheckDebugClicks(), "Advanced.CheckDebugClicks"); + addMenu(new LLAdvancedCheckDebugViews(), "Advanced.CheckDebugViews"); + addMenu(new LLAdvancedToggleDebugViews(), "Advanced.ToggleDebugViews"); + addMenu(new LLAdvancedToggleXUINameTooltips(), "Advanced.ToggleXUINameTooltips"); + addMenu(new LLAdvancedCheckXUINameTooltips(), "Advanced.CheckXUINameTooltips"); + addMenu(new LLAdvancedToggleDebugMouseEvents(), "Advanced.ToggleDebugMouseEvents"); + addMenu(new LLAdvancedCheckDebugMouseEvents(), "Advanced.CheckDebugMouseEvents"); + addMenu(new LLAdvancedToggleDebugKeys(), "Advanced.ToggleDebugKeys"); + addMenu(new LLAdvancedCheckDebugKeys(), "Advanced.CheckDebugKeys"); + addMenu(new LLAdvancedToggleDebugWindowProc(), "Advanced.ToggleDebugWindowProc"); + addMenu(new LLAdvancedCheckDebugWindowProc(), "Advanced.CheckDebugWindowProc"); + addMenu(new LLAdvancedToggleDebugTextEditorTips(), "Advanced.ToggleDebugTextEditorTips"); + addMenu(new LLAdvancedCheckDebugTextEditorTips(), "Advanced.CheckDebugTextEditorTips"); + + // Advanced > XUI + addMenu(new LLAdvancedShowFloaterTest(), "Advanced.ShowFloaterTest"); + addMenu(new LLAdvancedExportMenusToXML(), "Advanced.ExportMenusToXML"); + addMenu(new LLAdvancedEditUI(), "Advanced.EditUI"); + addMenu(new LLAdvancedLoadUIFromXML(), "Advanced.LoadUIFromXML"); + addMenu(new LLAdvancedSaveUIToXML(), "Advanced.SaveUIToXML"); + addMenu(new LLAdvancedToggleXUINames(), "Advanced.ToggleXUINames"); + addMenu(new LLAdvancedCheckXUINames(), "Advanced.CheckXUINames"); + + // Advanced > Character > Grab Baked Texture + addMenu(new LLAdvancedGrabBakedTexture(), "Advanced.GrabBakedTexture"); + addMenu(new LLAdvancedEnableGrabBakedTexture(), "Advanced.EnableGrabBakedTexture"); + + // Advanced > Character > Character Tests + addMenu(new LLAdvancedToggleAllowIdleAFK(), "Advanced.ToggleAllowIdleAFK"); + addMenu(new LLAdvancedCheckAllowIdleAFK(), "Advanced.CheckAllowIdleAFK"); + addMenu(new LLAdvancedAppearanceToXML(), "Advanced.AppearanceToXML"); + addMenu(new LLAdvancedToggleCharacterGeometry(), "Advanced.ToggleCharacterGeometry"); + addMenu(new LLAdvancedTestMale(), "Advanced.TestMale"); + addMenu(new LLAdvancedTestFemale(), "Advanced.TestFemale"); + addMenu(new LLAdvancedTogglePG(), "Advanced.TogglePG"); + addMenu(new LLAdvancedToggleAllowSelectAvatar(), "Advanced.ToggleAllowSelectAvatar"); + addMenu(new LLAdvancedCheckAllowSelectAvatar(), "Advanced.CheckAllowSelectAvatar"); + + // Advanced > Character (toplevel) + addMenu(new LLAdvancedToggleAllowTapTapHoldRun(), "Advanced.ToggleAllowTapTapHoldRun"); + addMenu(new LLAdvancedCheckAllowTapTapHoldRun(), "Advanced.CheckAllowTapTapHoldRun"); + addMenu(new LLAdvancedForceParamsToDefault(), "Advanced.ForceParamsToDefault"); + addMenu(new LLAdvancedReloadVertexShader(), "Advanced.ReloadVertexShader"); + addMenu(new LLAdvancedToggleAnimationInfo(), "Advanced.ToggleAnimationInfo"); + addMenu(new LLAdvancedCheckAnimationInfo(), "Advanced.CheckAnimationInfo"); + addMenu(new LLAdvancedToggleSlowMotionAnimations(), "Advanced.ToggleSlowMotionAnimations"); + //addMenu(new LLAdvancedCheckSlowMotionAnimations(), "Advanced.CheckSlowMotionAnimations"); + addMenu(new LLAdvancedToggleShowLookAt(), "Advanced.ToggleShowLookAt"); + addMenu(new LLAdvancedCheckShowLookAt(), "Advanced.CheckShowLookAt"); + addMenu(new LLAdvancedToggleShowPointAt(), "Advanced.ToggleShowPointAt"); + addMenu(new LLAdvancedCheckShowPointAt(), "Advanced.CheckShowPointAt"); + addMenu(new LLAdvancedToggleDebugJointUpdates(), "Advanced.ToggleDebugJointUpdates"); + addMenu(new LLAdvancedCheckDebugJointUpdates(), "Advanced.CheckDebugJointUpdates"); + addMenu(new LLAdvancedToggleDisableLOD(), "Advanced.ToggleDisableLOD"); + addMenu(new LLAdvancedCheckDisableLOD(), "Advanced.CheckDisableLOD"); + addMenu(new LLAdvancedToggleDebugCharacterVis(), "Advanced.ToggleDebugCharacterVis"); + addMenu(new LLAdvancedCheckDebugCharacterVis(), "Advanced.CheckDebugCharacterVis"); +// addMenu(new LLAdvancedToggleShowCollisionPlane(), "Advanced.ToggleShowCollisionPlane"); +// addMenu(new LLAdvancedCheckShowCollisionPlane(), "Advanced.CheckShowCollisionPlane"); + addMenu(new LLAdvancedToggleShowCollisionSkeleton(), "Advanced.ToggleShowCollisionSkeleton"); + addMenu(new LLAdvancedCheckShowCollisionSkeleton(), "Advanced.CheckShowCollisionSkeleton"); + addMenu(new LLAdvancedToggleDisplayAgentTarget(), "Advanced.ToggleDisplayAgentTarget"); + addMenu(new LLAdvancedCheckDisplayAgentTarget(), "Advanced.CheckDisplayAgentTarget"); + addMenu(new LLAdvancedToggleDebugAvatarRotation(), "Advanced.ToggleDebugAvatarRotation"); + addMenu(new LLAdvancedCheckDebugAvatarRotation(), "Advanced.CheckDebugAvatarRotation"); + addMenu(new LLAdvancedDumpAttachments(), "Advanced.DumpAttachments"); + addMenu(new LLAdvancedRebakeTextures(), "Advanced.RebakeTextures"); + addMenu(new LLAdvancedDebugAvatarTextures(), "Advanced.DebugAvatarTextures"); + addMenu(new LLAdvancedDumpAvatarLocalTextures(), "Advanced.DumpAvatarLocalTextures"); + + // Advanced > Network + addMenu(new LLAdvancedEnableMessageLog(), "Advanced.EnableMessageLog"); + addMenu(new LLAdvancedDisableMessageLog(), "Advanced.DisableMessageLog"); + addMenu(new LLAdvancedDropPacket(), "Advanced.DropPacket"); + + // Advanced > Recorder + addMenu(new LLAdvancedFrameStatsLogging(), "Advanced.FrameStatsLogging"); + addMenu(new LLAdvancedAgentPilot(), "Advanced.AgentPilot"); + addMenu(new LLAdvancedToggleAgentPilotLoop(), "Advanced.ToggleAgentPilotLoop"); + addMenu(new LLAdvancedCheckAgentPilotLoop(), "Advanced.CheckAgentPilotLoop"); + + // Advanced (toplevel) + addMenu(new LLAdvancedToggleShowObjectUpdates(), "Advanced.ToggleShowObjectUpdates"); + addMenu(new LLAdvancedCheckShowObjectUpdates(), "Advanced.CheckShowObjectUpdates"); + addMenu(new LLAdvancedCompressImage(), "Advanced.CompressImage"); + addMenu(new LLAdvancedToggleClothingFloater(), "Advanced.ToggleClothingFloater"); + addMenu(new LLAdvancedShowDebugSettings(), "Advanced.ShowDebugSettings"); + addMenu(new LLAdvancedToggleViewAdminOptions(), "Advanced.ToggleViewAdminOptions"); + addMenu(new LLAdvancedCheckViewAdminOptions(), "Advanced.CheckViewAdminOptions"); + addMenu(new LLAdvancedRequestAdminStatus(), "Advanced.RequestAdminStatus"); + addMenu(new LLAdvancedLeaveAdminStatus(), "Advanced.LeaveAdminStatus"); } -------------- next part -------------- --- linden/indra/newview/skins/xui/en-us/menu_viewer.xml +++ linden/indra/newview/skins/xui/en-us/menu_viewer.xml @@ -701,11 +701,956 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -------------- next part -------------- A non-text attachment was scrubbed... Name: menu_viewer.xml Type: text/xml Size: 76816 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080708/39986f56/menu_viewer-0001.bin From gigstaggart at gmail.com Tue Jul 8 14:07:02 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 8 14:07:17 2008 Subject: [sldev] cmake weirdness In-Reply-To: References: <48733DB6.7010601@gmail.com> Message-ID: <4873D6F6.40505@gmail.com> Soft wrote: > Which branch are you working in? > release/trunk > The new cmake setup pulls individual library bundles as needed - we're > phasing out the single giant library tarballs. The cmake scripts cache > these locally so that as libraries are updated or as you switch > between branches, only the libs that you're using for the first time > will need to be downloaded. So this means it will be impossible to make a portable build with cmake from here on out, because it'll assume you have the system level libraries of the system you built it on? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080708/5214b077/smime.bin From soft at lindenlab.com Tue Jul 8 16:26:30 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 8 16:26:34 2008 Subject: [sldev] cmake weirdness In-Reply-To: <4873D6F6.40505@gmail.com> References: <48733DB6.7010601@gmail.com> <4873D6F6.40505@gmail.com> Message-ID: On Tue, Jul 8, 2008 at 4:07 PM, Jason Giglio wrote: > >> The new cmake setup pulls individual library bundles as needed - we're >> phasing out the single giant library tarballs. The cmake scripts cache >> these locally so that as libraries are updated or as you switch >> between branches, only the libs that you're using for the first time >> will need to be downloaded. > > So this means it will be impossible to make a portable build with cmake > from here on out, because it'll assume you have the system level > libraries of the system you built it on? I'm not clear on where you see that. The new system pulls the same libraries that were previously in the monolithic library bundles. It shouldn't ever select system-provided libraries in cases where it didn't previously - it still downloads these. Fundamentally, this is designed as an alternative delivery mechanism to stop you from having to download the giant library bundle repeatedly when only one library has actually changed. That should be all it affects - any other change should be filed as a bug in JIRA or brought up here. Hopefully we can make it more clear and friendly before 1.21 forks off of release/. I apologize for this hitting release/ without a preview branch for us to iterate over the changes and get them more polished. This should have been handled more like the first wave of cmake changes. Unfortunately, this was one of those cases where the right hand didn't know what the left was doing. From gigstaggart at gmail.com Tue Jul 8 22:24:08 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 8 22:24:22 2008 Subject: [sldev] cmake weirdness In-Reply-To: References: <48733DB6.7010601@gmail.com> <4873D6F6.40505@gmail.com> Message-ID: <48744B78.1020807@gmail.com> Soft wrote: >> So this means it will be impossible to make a portable build with cmake >> from here on out, because it'll assume you have the system level >> libraries of the system you built it on? > > I'm not clear on where you see that. > Maybe I misunderstood. > brought up here. Hopefully we can make it more clear and friendly > before 1.21 forks off of release/. > I apologize for this hitting release/ without a preview branch for us > to iterate over the changes and get them more polished. This should > have been handled more like the first wave of cmake changes. No that part is actually OK with me. I think LL keeps too many branches and I'm actually ok with trunk being a wild and crazy place. Just need to understand what the intent of this is and how it works. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080709/aa2ebc6d/smime.bin From belxjander at gmail.com Wed Jul 9 00:10:16 2008 From: belxjander at gmail.com (Belxjander Serechai) Date: Wed Jul 9 00:10:19 2008 Subject: [sldev] [IDEA] - OpenGridProtocol - Agent/Avatar question... Message-ID: <4880eb1a0807090010u7dd1d2ddl4ac0e297afe95504@mail.gmail.com> Just a random thought... but what IS the difference between a user-agent and any other object? both have a "core mesh" and texture assets applied... the only difference *I* see is one has an "Agent" directly controlling movement and events and the other is "scripted" reactions to "Agent" presence... Whats stopping the "Avatar" of a given user being an arbitrary "object" mesh + asset listing? or would objects need an extra "agent attachments" tag for placing Attachments? Maybe a dumb question... but would that open up pandoras box socially? be talking to almost *anything* as AV ... even allowing for "scuplty" Octopii and other "weirdness" AVs in addition to whats done to the existing AV meshes now ? Curious and Wondering, Jeremy Sutherland (Real Life), AKA Belxjander Serechai (General Internet), Freija Yoshikawa ( LLSL & osgrid.org ) From tateru.nino at gmail.com Wed Jul 9 00:20:08 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 9 00:21:34 2008 Subject: [sldev] [IDEA] - OpenGridProtocol - Agent/Avatar question... In-Reply-To: <4880eb1a0807090010u7dd1d2ddl4ac0e297afe95504@mail.gmail.com> References: <4880eb1a0807090010u7dd1d2ddl4ac0e297afe95504@mail.gmail.com> Message-ID: <487466A8.3000604@weblogsinc.com> Well, technically an agent doesn't have a mesh or textures or any of that. The agent is the part you _don't_ see. There's an avatar, which is an object such as you describe, which is associated with an agent and coincides with it in space. The agent represents the invisible presence and the communications umbilical back to the viewer. Belxjander Serechai wrote: > Just a random thought... but what IS the difference between a > user-agent and any other object? > > both have a "core mesh" and texture assets applied... > > the only difference *I* see is one has an "Agent" directly controlling > movement and events > and the other is "scripted" reactions to "Agent" presence... > > Whats stopping the "Avatar" of a given user being an arbitrary > "object" mesh + asset listing? > or would objects need an extra "agent attachments" tag for placing > Attachments? > > Maybe a dumb question... but would that open up pandoras box socially? > be talking to almost *anything* as AV ... even allowing for > "scuplty" Octopii and other > "weirdness" AVs in addition to whats done to the existing AV meshes now ? > > Curious and Wondering, > Jeremy Sutherland (Real Life), > AKA Belxjander Serechai (General Internet), > Freija Yoshikawa ( LLSL & osgrid.org ) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://www.massively.com/ From tateru.nino at gmail.com Wed Jul 9 00:45:46 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 9 00:47:13 2008 Subject: [sldev] [IDEA] - OpenGridProtocol - Agent/Avatar question... In-Reply-To: <4880eb1a0807090042g50077ab2t431eb610b75e5866@mail.gmail.com> References: <4880eb1a0807090010u7dd1d2ddl4ac0e297afe95504@mail.gmail.com> <487466A8.3000604@weblogsinc.com> <4880eb1a0807090042g50077ab2t431eb610b75e5866@mail.gmail.com> Message-ID: <48746CAA.1020306@gmail.com> Well, when the viewer is advised that there is an agent around, 'Ruth' is what is placed into the 3D view until the object data for the avatar becomes available to the viewer. In cases where the object data never becomes available or becomes only partially available the avatar remains wholly or partly Ruth. The alternative is having the agent present but invisible. It's true that just about any kind of mesh could be substituted for Ruth (and indeed has been in a recent 1.20 viewer), but the important part is that it's a placeholder asset that is always immediately available to the viewer without needing additional communications. What Ruth is, is defined by what the viewer chooses to place. Leastways that's the answer if I understood your question correctly. :) Belxjander Serechai wrote: > So what is stopping the Agent from getting a given "object" from > storage to avoid all this "ruth"ing business? > or is that impractical for other reasons ? > > On Wed, Jul 9, 2008 at 4:20 PM, Tateru Nino wrote: > >> Well, technically an agent doesn't have a mesh or textures or any of that. >> The agent is the part you _don't_ see. There's an avatar, which is an object >> such as you describe, which is associated with an agent and coincides with >> it in space. The agent represents the invisible presence and the >> communications umbilical back to the viewer. >> >> Belxjander Serechai wrote: >> >>> Just a random thought... but what IS the difference between a >>> user-agent and any other object? >>> >>> both have a "core mesh" and texture assets applied... >>> >>> the only difference *I* see is one has an "Agent" directly controlling >>> movement and events >>> and the other is "scripted" reactions to "Agent" presence... >>> >>> Whats stopping the "Avatar" of a given user being an arbitrary >>> "object" mesh + asset listing? >>> or would objects need an extra "agent attachments" tag for placing >>> Attachments? >>> >>> Maybe a dumb question... but would that open up pandoras box socially? >>> be talking to almost *anything* as AV ... even allowing for >>> "scuplty" Octopii and other >>> "weirdness" AVs in addition to whats done to the existing AV meshes now ? >>> >>> Curious and Wondering, >>> Jeremy Sutherland (Real Life), >>> AKA Belxjander Serechai (General Internet), >>> Freija Yoshikawa ( LLSL & osgrid.org ) >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >> -- >> Tateru Nino >> http://www.massively.com/ >> >> >> > > From dahliatrimble at gmail.com Wed Jul 9 00:50:50 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Jul 9 00:50:53 2008 Subject: [sldev] [IDEA] - OpenGridProtocol - Agent/Avatar question... In-Reply-To: <48746CAA.1020306@gmail.com> References: <4880eb1a0807090010u7dd1d2ddl4ac0e297afe95504@mail.gmail.com> <487466A8.3000604@weblogsinc.com> <4880eb1a0807090042g50077ab2t431eb610b75e5866@mail.gmail.com> <48746CAA.1020306@gmail.com> Message-ID: Actually an agent has a physical mesh used for collisions but it's probably not the same shape as the avatar, but about the same size On Wed, Jul 9, 2008 at 12:45 AM, Tateru Nino wrote: > Well, when the viewer is advised that there is an agent around, 'Ruth' is > what is placed into the 3D view until the object data for the avatar becomes > available to the viewer. In cases where the object data never becomes > available or becomes only partially available the avatar remains wholly or > partly Ruth. > > The alternative is having the agent present but invisible. It's true that > just about any kind of mesh could be substituted for Ruth (and indeed has > been in a recent 1.20 viewer), but the important part is that it's a > placeholder asset that is always immediately available to the viewer without > needing additional communications. What Ruth is, is defined by what the > viewer chooses to place. > > Leastways that's the answer if I understood your question correctly. :) > > Belxjander Serechai wrote: > >> So what is stopping the Agent from getting a given "object" from >> storage to avoid all this "ruth"ing business? >> or is that impractical for other reasons ? >> >> >> On Wed, Jul 9, 2008 at 4:20 PM, Tateru Nino >> wrote: >> >> >>> Well, technically an agent doesn't have a mesh or textures or any of >>> that. >>> The agent is the part you _don't_ see. There's an avatar, which is an >>> object >>> such as you describe, which is associated with an agent and coincides >>> with >>> it in space. The agent represents the invisible presence and the >>> communications umbilical back to the viewer. >>> >>> Belxjander Serechai wrote: >>> >>> >>>> Just a random thought... but what IS the difference between a >>>> user-agent and any other object? >>>> >>>> both have a "core mesh" and texture assets applied... >>>> >>>> the only difference *I* see is one has an "Agent" directly controlling >>>> movement and events >>>> and the other is "scripted" reactions to "Agent" presence... >>>> >>>> Whats stopping the "Avatar" of a given user being an arbitrary >>>> "object" mesh + asset listing? >>>> or would objects need an extra "agent attachments" tag for placing >>>> Attachments? >>>> >>>> Maybe a dumb question... but would that open up pandoras box socially? >>>> be talking to almost *anything* as AV ... even allowing for >>>> "scuplty" Octopii and other >>>> "weirdness" AVs in addition to whats done to the existing AV meshes now >>>> ? >>>> >>>> Curious and Wondering, >>>> Jeremy Sutherland (Real Life), >>>> AKA Belxjander Serechai (General Internet), >>>> Freija Yoshikawa ( LLSL & osgrid.org ) >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>>> >>>> >>>> >>> -- >>> Tateru Nino >>> http://www.massively.com/ >>> >>> >>> >>> >> >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080709/6d613a9d/attachment.htm From robin.cornelius at gmail.com Wed Jul 9 02:59:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jul 9 02:59:40 2008 Subject: [sldev] [VWR] export scripts of viewer source, very minor issues Message-ID: Hi Everyone, Probably directed to Soft -> Any chance of modifying the export scripts so that indra/newview/app_settings/windlight/clouds2.tga is not exported to both the artwork and the viewer source. I would say keep it in just the artwork, as its artwork :-) Also the shaders are getting random execute permissions set in linux, i'm running a filter on the source to fix this ;- chmod -x debian/omvviewer-data/usr/share/omvviewer/app_settings/shaders -R chmod +X debian/omvviewer-data/usr/share/omvviewer/app_settings/shaders -R But if this could be fixed in the export scripts that would be great! I know its only trivial and to most is not even important but it makes packaging for linux distros slightly easier. Many thanks Robin From alissa_sabre at yahoo.co.jp Wed Jul 9 07:29:21 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Jul 9 07:29:36 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STL compatibility issue Message-ID: <1dsnkw3ds4ds4ds4ef4ds9kz.alissa_sabre@yahoo.co.jp> Developers, I'm having a trouble building/running recent 1.20 series of SL viewer on Windows using VS2005. I believe it is related to the compatibility issues on Microsoft implementation of STL, in particular, that related to "safe iterator", although I'm not exactly sure... I put two essential questions on the bottom of this mail. Any comments are appreciated. --- I downloaded and built SL viewer 1.20.12 on my Windows using Visual C++ Express 2005. I converted solution/project files by myself following the instructions on: http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 The compile seemed successful. However, When executed alone, it does not show any window, consuming 100% CPU until I terminate the process. When executed under debugger, it stopped before showing any window with the following message: Unhandled exception at 0xXXXXXXXX in newview_noopt.exe: 0xC0000005: Access violation reading location 0xXXXXXXXX. and the top entries of the stack trace shows something like: std::list::begin() boost::signals::detail::named_slot_map_iterator::init_next_group() boost::signals::detail::named_slot_map::end() and I found the code for boost::signals::detail::named_slot_map::end() is taken from the boost library file libboost_signals-vc80-mt-s-1_34_1.lib contained in the SL library bundle. After examined the issue with debugger, I had a feeling that the size (as in sizeof()) of some variable is understood incorrectly. And I remembered the _SECURE_SCL=0 issue regarding Microsoft VS2005 STL's iterator issues: https://lists.secondlife.com/pipermail/sldev/2007-June/002791.html My compiler options included the define for _SECURE_SCL=0 because the wiki page says so... I removed the define for _SECURE_SCL=0 from the compiler options, and buildt again. The resulting executable worked fine. The mail by Matt Kimmel says, however, this _SECURE_SCL=0 define is essential for VS2005 build, and the viewer frequently crashes without it. (Although I have not experienced any crash of my own build of 1.20.12 viewer without _SECURE_SCL=1 for about three or four hours.) On the other hand, it is apparent that the *.lib files of pre-compiled boost package is build without _SECURE_SCL=0 settings, so the application that use boost library needs to use the same settings. That's what I believe caused my initial problem. I'm not sure what I should do. In particular, I want to know answers to the following two questions: (1) I believe Lindens are using VS2005 for their own viewer development. What settings are you using when compiling the viewer, regarding _SECURE_SCL? (2) Matt Kimmel's mail above says the (viewer side) problem is in LLSD::impl class, although he is not specific enough... Is the problem in LLSD::impl corrected after June 2007? # I'm not sure why this issue is not discussed on JIRA or SLDev... I was off from SL development for a while. Nobody is working on Windows anymore? Thanks in advance, Alissa Sabre -------------------------------------- Stop! Global Warming ~ Yahoo! JAPAN Earth Project http://pr.mail.yahoo.co.jp/earthproject/ From soft at lindenlab.com Wed Jul 9 07:38:42 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 9 07:38:45 2008 Subject: [sldev] [VWR] export scripts of viewer source, very minor issues In-Reply-To: References: Message-ID: On Wed, Jul 9, 2008 at 4:59 AM, Robin Cornelius wrote: > Hi Everyone, > > Probably directed to Soft -> > > Any chance of modifying the export scripts so that > indra/newview/app_settings/windlight/clouds2.tga is not exported to > both the artwork and the viewer source. I would say keep it in just > the artwork, as its artwork :-) > > Also the shaders are getting random execute permissions set in linux, > i'm running a filter on the source to fix this ;- > > chmod -x debian/omvviewer-data/usr/share/omvviewer/app_settings/shaders -R > chmod +X debian/omvviewer-data/usr/share/omvviewer/app_settings/shaders -R > > But if this could be fixed in the export scripts that would be great! > I know its only trivial and to most is not even important but it makes > packaging for linux distros slightly easier. No script needed, actually. Those shouldn't have been propset svn:executable in the first place - clearing that property clears the execute flag. That, the missing UI files and the tga will be fixed by the next drop. From seg at haxxed.com Wed Jul 9 09:00:11 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jul 9 09:00:14 2008 Subject: [sldev] about openjpeg In-Reply-To: <487303F5.9050306@gmail.com> References: <487303F5.9050306@gmail.com> Message-ID: <1218b5bc0807090900p4189057cy99919392d72611d8@mail.gmail.com> On Tue, Jul 8, 2008 at 1:06 AM, Jason Giglio wrote: > Jordi Polo wrote: >> I've just downloaded and trying to compile the viewer source. >> I have noticed that it uses the openjpeg library version 1.1 It exists a >> 1.3 version what supposedly is much faster. I just wanted to point it out >> just in case you don't keep track of outside libraries (viewer is big enough >> to be very busy coding!) > > > Jordi, > > I think I hear you volunteering to do some benchmarks :P > > The way I understand it 1.3 is mainly improved for GIS uses, with a few > speedups that would affect SL too. You're thinking of 2.0, which has a bunch of improvements for the GIS people. I believe it changes the API a bit too, so I don't think it will work with SL as is right now anyway. 1.3 is the one that got Dzonatas' DWT and the bulk of my changes, thus is the one you want. AFAIK SL was shipping with at least 1.2. From chaosstar at gmail.com Wed Jul 9 09:30:38 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Jul 9 09:30:42 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STL compatibility issue In-Reply-To: <1dsnkw3ds4ds4ds4ef4ds9kz.alissa_sabre@yahoo.co.jp> References: <1dsnkw3ds4ds4ds4ef4ds9kz.alissa_sabre@yahoo.co.jp> Message-ID: <9bb32d430807090930x3e217730ta95bc4dd86832c21@mail.gmail.com> I had that issue described below when compiling 1.20 RC12 with VS2008 Express. What surprises me here is that you are having the same issue with VS2005..it compiled (well, ran) fine for me there. Tho I must note, I did compile ReleaseForDownload, in both cases. Try compiling again with the ReleaseForDownload setup in your VS2005...I'd be interested to hear if you still get this issue. Also, LL use VS2003 .net for the compilation of the official viewer, to my knowledge. --Chalice Yao On Wed, Jul 9, 2008 at 16:29, Alissa Sabre wrote: > Developers, > > I'm having a trouble building/running recent 1.20 series of SL viewer > on Windows using VS2005. I believe it is related to the compatibility > issues on Microsoft implementation of STL, in particular, that related > to "safe iterator", although I'm not exactly sure... > > I put two essential questions on the bottom of this mail. Any > comments are appreciated. > > --- > > I downloaded and built SL viewer 1.20.12 on my Windows using Visual > C++ Express 2005. I converted solution/project files by myself > following the instructions on: > > http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > > The compile seemed successful. However, When executed alone, it does > not show any window, consuming 100% CPU until I terminate the process. > When executed under debugger, it stopped before showing any window > with the following message: > > Unhandled exception at 0xXXXXXXXX in newview_noopt.exe: 0xC0000005: > Access violation reading location 0xXXXXXXXX. > > and the top entries of the stack trace shows something like: > > std::list::begin() > boost::signals::detail::named_slot_map_iterator::init_next_group() > boost::signals::detail::named_slot_map::end() > > and I found the code for boost::signals::detail::named_slot_map::end() > is taken from the boost library file > libboost_signals-vc80-mt-s-1_34_1.lib contained in the SL library > bundle. > > After examined the issue with debugger, I had a feeling that the size > (as in sizeof()) of some variable is understood incorrectly. And I > remembered the _SECURE_SCL=0 issue regarding Microsoft VS2005 STL's > iterator issues: > > https://lists.secondlife.com/pipermail/sldev/2007-June/002791.html > > My compiler options included the define for _SECURE_SCL=0 because the > wiki page says so... I removed the define for _SECURE_SCL=0 from the > compiler options, and buildt again. > > The resulting executable worked fine. > > The mail by Matt Kimmel says, however, this _SECURE_SCL=0 define is > essential for VS2005 build, and the viewer frequently crashes without > it. (Although I have not experienced any crash of my own build of > 1.20.12 viewer without _SECURE_SCL=1 for about three or four hours.) > > On the other hand, it is apparent that the *.lib files of pre-compiled > boost package is build without _SECURE_SCL=0 settings, so the > application that use boost library needs to use the same settings. > That's what I believe caused my initial problem. > > I'm not sure what I should do. In particular, I want to know answers > to the following two questions: > > (1) I believe Lindens are using VS2005 for their own viewer > development. What settings are you using when compiling the > viewer, regarding _SECURE_SCL? > > (2) Matt Kimmel's mail above says the (viewer side) problem is in > LLSD::impl class, although he is not specific enough... Is the > problem in LLSD::impl corrected after June 2007? > > # I'm not sure why this issue is not discussed on JIRA or SLDev... I > was off from SL development for a while. Nobody is working on > Windows anymore? > > Thanks in advance, > > Alissa Sabre > -------------------------------------- > Stop! Global Warming ~ Yahoo! JAPAN Earth Project > http://pr.mail.yahoo.co.jp/earthproject/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From phoenix at secondlife.com Wed Jul 9 09:39:09 2008 From: phoenix at secondlife.com (Phoenix) Date: Wed Jul 9 09:39:22 2008 Subject: [sldev] cmake weirdness In-Reply-To: <48744B78.1020807@gmail.com> References: <48733DB6.7010601@gmail.com> <4873D6F6.40505@gmail.com> <48744B78.1020807@gmail.com> Message-ID: <0079BF72-9239-4FD0-80E6-AA357D8069B7@secondlife.com> On 2008-07-08, at 22:24, Jason Giglio wrote: > Soft wrote: >>> So this means it will be impossible to make a portable build with >>> cmake >>> from here on out, because it'll assume you have the system level >>> libraries of the system you built it on? >> >> I'm not clear on where you see that. >> > > Maybe I misunderstood. > >> brought up here. Hopefully we can make it more clear and friendly >> before 1.21 forks off of release/. >> I apologize for this hitting release/ without a preview branch for us >> to iterate over the changes and get them more polished. This should >> have been handled more like the first wave of cmake changes. > > No that part is actually OK with me. I think LL keeps too many > branches > and I'm actually ok with trunk being a wild and crazy place. > > Just need to understand what the intent of this is and how it works. I don't understand your original question. What do you mean by a portable build? What is it that you want to do? Cross compilation? -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080709/47b37614/PGP.pgp From soft at lindenlab.com Wed Jul 9 09:43:18 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 9 09:43:20 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STLcompatibility issue In-Reply-To: <9bb32d430807090930x3e217730ta95bc4dd86832c21@mail.gmail.com> References: <1dsnkw3ds4ds4ds4ef4ds9kz.alissa_sabre@yahoo.co.jp> <9bb32d430807090930x3e217730ta95bc4dd86832c21@mail.gmail.com> Message-ID: Yes, 1.20 is still VS2003-based. That said, I know others have gotten VS2005 to work with the 1.20 drop, so don't be dissuaded >From 1.21 going forward, VS2005 will be the standard. VS2008 will generally work, though from my experience VS2008 still has enough bugs that I would advise sticking with VS2005 if you're able. On Wed, Jul 9, 2008 at 11:30 AM, Ambrosia wrote: > I had that issue described below when compiling 1.20 RC12 with VS2008 Express. > > What surprises me here is that you are having the same issue with > VS2005..it compiled (well, ran) > fine for me there. Tho I must note, I did compile ReleaseForDownload, > in both cases. > > Try compiling again with the ReleaseForDownload setup in your > VS2005...I'd be interested > to hear if you still get this issue. > > Also, LL use VS2003 .net for the compilation of the official viewer, > to my knowledge. > > --Chalice Yao > > On Wed, Jul 9, 2008 at 16:29, Alissa Sabre wrote: >> Developers, >> >> I'm having a trouble building/running recent 1.20 series of SL viewer >> on Windows using VS2005. I believe it is related to the compatibility >> issues on Microsoft implementation of STL, in particular, that related >> to "safe iterator", although I'm not exactly sure... >> >> I put two essential questions on the bottom of this mail. Any >> comments are appreciated. >> >> --- >> >> I downloaded and built SL viewer 1.20.12 on my Windows using Visual >> C++ Express 2005. I converted solution/project files by myself >> following the instructions on: >> >> http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 >> >> The compile seemed successful. However, When executed alone, it does >> not show any window, consuming 100% CPU until I terminate the process. >> When executed under debugger, it stopped before showing any window >> with the following message: >> >> Unhandled exception at 0xXXXXXXXX in newview_noopt.exe: 0xC0000005: >> Access violation reading location 0xXXXXXXXX. >> >> and the top entries of the stack trace shows something like: >> >> std::list::begin() >> boost::signals::detail::named_slot_map_iterator::init_next_group() >> boost::signals::detail::named_slot_map::end() >> >> and I found the code for boost::signals::detail::named_slot_map::end() >> is taken from the boost library file >> libboost_signals-vc80-mt-s-1_34_1.lib contained in the SL library >> bundle. >> >> After examined the issue with debugger, I had a feeling that the size >> (as in sizeof()) of some variable is understood incorrectly. And I >> remembered the _SECURE_SCL=0 issue regarding Microsoft VS2005 STL's >> iterator issues: >> >> https://lists.secondlife.com/pipermail/sldev/2007-June/002791.html >> >> My compiler options included the define for _SECURE_SCL=0 because the >> wiki page says so... I removed the define for _SECURE_SCL=0 from the >> compiler options, and buildt again. >> >> The resulting executable worked fine. >> >> The mail by Matt Kimmel says, however, this _SECURE_SCL=0 define is >> essential for VS2005 build, and the viewer frequently crashes without >> it. (Although I have not experienced any crash of my own build of >> 1.20.12 viewer without _SECURE_SCL=1 for about three or four hours.) >> >> On the other hand, it is apparent that the *.lib files of pre-compiled >> boost package is build without _SECURE_SCL=0 settings, so the >> application that use boost library needs to use the same settings. >> That's what I believe caused my initial problem. >> >> I'm not sure what I should do. In particular, I want to know answers >> to the following two questions: >> >> (1) I believe Lindens are using VS2005 for their own viewer >> development. What settings are you using when compiling the >> viewer, regarding _SECURE_SCL? >> >> (2) Matt Kimmel's mail above says the (viewer side) problem is in >> LLSD::impl class, although he is not specific enough... Is the >> problem in LLSD::impl corrected after June 2007? >> >> # I'm not sure why this issue is not discussed on JIRA or SLDev... I >> was off from SL development for a while. Nobody is working on >> Windows anymore? >> >> Thanks in advance, >> >> Alissa Sabre >> -------------------------------------- >> Stop! Global Warming ~ Yahoo! JAPAN Earth Project >> http://pr.mail.yahoo.co.jp/earthproject/ >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From missannotoole at yahoo.com Wed Jul 9 09:43:44 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed Jul 9 09:43:47 2008 Subject: [sldev] Google data exchange format Message-ID: <685317.77246.qm@web59103.mail.re1.yahoo.com> This is important. This is about metadata and how proper use of metadata can facilitate massive system architecture properly. WTG Google! Now how to get people to give up what they learned to love (or hate and now are tired of learning) and use something much better? ----- Original Message ---- From: Argent Sent: Tuesday, July 8, 2008 4:32:06 PM Just announced on slashdot: http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html A fast, compact IDL that's got a well-tested open-source implementation and is an order of magnitude faster than XML? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080709/d7969f0e/attachment.htm From jhurliman at jhurliman.org Wed Jul 9 10:06:50 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Wed Jul 9 10:06:53 2008 Subject: [sldev] Google data exchange format In-Reply-To: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> Message-ID: Thanks for the link. I'm in the process of adding C# support, and if I have time I might reimplement a few SL packets as protobufs to do comparisons. If a few tweaks were made to allow mostly empty byte arrays to pack down (I'm thinking LayerData), zerocoding would become unnecessary and you remove one of the most complex* parts of a high performance implementation of the network layer. The only change I would probably make would be adding native support for important datatypes (vector2/3/4, quaternion, uuid). Being able to throw away the message template and the three different serialization formats of LLSD and replace them with a single fast and terse implementation would be very nice. Still can't figure out why the release build of libprotobuf.dll is over 700KB though. More digging required. * Allocating a new ~2KB block of memory every time a zerocoded packet comes in or goes out is going to fragment memory really quickly. To get around this you need a dynamic pool of buffers to pack/unpack messages, and handle checking in and checking out buffers to the pool (like a threadpool for memory chunks). John On Tue, Jul 8, 2008 at 1:32 PM, Argent wrote: > Just announced on slashdot: > > > http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html > > A fast, compact IDL that's got a well-tested open-source implementation and > is an order of magnitude faster than XML? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080709/2b62f4c7/attachment.htm From gigstaggart at gmail.com Wed Jul 9 10:41:12 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 9 10:41:27 2008 Subject: [sldev] cmake weirdness In-Reply-To: <0079BF72-9239-4FD0-80E6-AA357D8069B7@secondlife.com> References: <48733DB6.7010601@gmail.com> <4873D6F6.40505@gmail.com> <48744B78.1020807@gmail.com> <0079BF72-9239-4FD0-80E6-AA357D8069B7@secondlife.com> Message-ID: <4874F838.4030709@gmail.com> Phoenix wrote: > I don't understand your original question. What do you mean by a > portable build? What is it that you want to do? Cross compilation? I meant linking with the system libs vs linking with a lib bundled in the eventual deployment package. When soft said it would only fetch the "necessary" libs, I took that to mean it would only package libs that did not exist on your system elsewhere, which would make the package pretty system specific. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080709/af17975e/smime.bin From phoenix at secondlife.com Wed Jul 9 11:04:51 2008 From: phoenix at secondlife.com (Phoenix) Date: Wed Jul 9 11:04:59 2008 Subject: [sldev] cmake weirdness In-Reply-To: <4874F838.4030709@gmail.com> References: <48733DB6.7010601@gmail.com> <4873D6F6.40505@gmail.com> <48744B78.1020807@gmail.com> <0079BF72-9239-4FD0-80E6-AA357D8069B7@secondlife.com> <4874F838.4030709@gmail.com> Message-ID: <1440907C-49F9-4C9B-B4B2-021C2636E23B@secondlife.com> On 2008-07-09, at 10:41, Jason Giglio wrote: > Phoenix wrote: >> I don't understand your original question. What do you mean by a >> portable build? What is it that you want to do? Cross compilation? > > I meant linking with the system libs vs linking with a lib bundled in > the eventual deployment package. You should pass in the --standalone flag and the build system will assume you have all necessary libraries installed. ./build.py --standalone configure should do what you want. If it still fetches a library from S3 or unpacks a library into the tree, then it is a bug. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080709/d45319e2/PGP-0001.pgp From tao.takashi at googlemail.com Wed Jul 9 16:29:35 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Wed Jul 9 16:29:38 2008 Subject: [sldev] Google data exchange format In-Reply-To: References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> Message-ID: <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> Indeed, thanks for the link! I just tried out the Python version and tried to got it running inside a buildout. Works now but could be packaged better IMHO. I might test this with pyogp by implementing a new serializer with it. As what serialization to use is still a question though as all have their advantages and disadvantages. e.g. JSON would have the advantage of being known to many developers. But Google has some weight so protobuf might also be somewhat known very soon while LLSD probably not so much. As for efficiency it will probably also come down to protobuf. But as OGP hopefully allows not only one serialization it should be fine. We just need a way to let components find out what serializations are supported. -- Tao On Wed, Jul 9, 2008 at 8:06 PM, John Hurliman wrote: > Thanks for the link. I'm in the process of adding C# support, and if I have > time I might reimplement a few SL packets as protobufs to do comparisons. If > a few tweaks were made to allow mostly empty byte arrays to pack down (I'm > thinking LayerData), zerocoding would become unnecessary and you remove one > of the most complex* parts of a high performance implementation of the > network layer. The only change I would probably make would be adding native > support for important datatypes (vector2/3/4, quaternion, uuid). Being able > to throw away the message template and the three different serialization > formats of LLSD and replace them with a single fast and terse implementation > would be very nice. > > Still can't figure out why the release build of libprotobuf.dll is over > 700KB though. More digging required. > > * Allocating a new ~2KB block of memory every time a zerocoded packet comes > in or goes out is going to fragment memory really quickly. To get around > this you need a dynamic pool of buffers to pack/unpack messages, and handle > checking in and checking out buffers to the pool (like a threadpool for > memory chunks). > > > John > > On Tue, Jul 8, 2008 at 1:32 PM, Argent wrote: >> >> Just announced on slashdot: >> >> >> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html >> >> A fast, compact IDL that's got a well-tested open-source implementation >> and is an order of magnitude faster than XML? >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From lenglish5 at cox.net Wed Jul 9 17:51:53 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jul 9 17:51:56 2008 Subject: [sldev] Google data exchange format In-Reply-To: <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> Message-ID: <48755D29.9000903@cox.net> Christian Scholz / Tao Takashi (SL) wrote: > Indeed, thanks for the link! > I just tried out the Python version and tried to got it running inside > a buildout. Works now but could be packaged better IMHO. > I might test this with pyogp by implementing a new serializer with it. > > As what serialization to use is still a question though as all have > their advantages and disadvantages. e.g. JSON would have the advantage > of being known to many developers. But Google has some weight so > protobuf might also be somewhat known very soon while LLSD probably > not so much. As for efficiency it will probably also come down to > protobuf. > > But as OGP hopefully allows not only one serialization it should be > fine. We just need a way to let components find out what > serializations are supported. > Seems to me that LLSD would be a single format file in this system. If it is robust enough, could replace the LLSD XML format without any code changes save the one function. Would allow for gradual switchover since a new viewer could request caps to use the new format, while the default would be the current format. Lawson From lenglish5 at cox.net Wed Jul 9 18:32:38 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jul 9 18:32:40 2008 Subject: [sldev] Google data exchange format In-Reply-To: <48755D29.9000903@cox.net> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> <48755D29.9000903@cox.net> Message-ID: <487566B6.20405@cox.net> Lawson English wrote: > > Seems to me that LLSD would be a single format file in this system. If > it is robust enough, could replace the LLSD XML format without any > code changes save the one function. Would allow for gradual switchover > since a new viewer could request caps to use the new format, while > the default would be the current format. > Also, seems to me that pyogp would be a great test for comparing throughput using LLSD-XML vs LLSD-GDE. Lawson From lenglish5 at cox.net Wed Jul 9 19:02:02 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jul 9 19:02:07 2008 Subject: [sldev] [AWG] Zero Linden office hours discussion on ineroperability Message-ID: <48756D9A.3070502@cox.net> Tess Linden, Director of Studio Icehouse, will be guest-hosting Zero's office hours Thursday, 8:30 AM SLT. http://slurl.com/secondlife/Grasmere/163/111/27/?title=Linden%20Village The topic will be: '"The Interoperable Experience" and how that will change as we move forward with the Beta.' For those that missed it, Linden Lab and IBM did a successful demo of a TP from the SL beta grid to OpenSim. Zha Ewry told me she did 20 round trips (10?) to make sure it worked both ways. http://blog.secondlife.com/2008/07/08/ibm-linden-lab-interoperability-announcement/ So, I'd expect tomorrow's office hours to be in the context of that demo. Lawson From rdw at lindenlab.com Wed Jul 9 19:50:53 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Jul 9 19:50:56 2008 Subject: [sldev] Google data exchange format In-Reply-To: <487566B6.20405@cox.net> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com><48755D29.9000903@cox.net> <487566B6.20405@cox.net> Message-ID: <4875790D.5080105@lindenlab.com> Lawson English wrote: > Lawson English wrote: >> >> Seems to me that LLSD would be a single format file in this system. >> If it is robust enough, could replace the LLSD XML format without any >> code changes save the one function. Would allow for gradual >> switchover since a new viewer could request caps to use the new >> format, while the default would be the current format. >> > > Also, seems to me that pyogp would be a great test for comparing > throughput using LLSD-XML vs LLSD-GDE. There is, you know, llsd-binary, which probably delivers very nearly the speed and efficiency that protocol buffers do. I'd actually love to see someone do a performance comparison of the two, to confirm or deny my "probably" in the previous sentence. -RYaN From mumismo at gmail.com Wed Jul 9 19:56:51 2008 From: mumismo at gmail.com (Jordi Polo) Date: Wed Jul 9 19:56:54 2008 Subject: [sldev] Google data exchange format In-Reply-To: <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> Message-ID: Protocol buffers compared with JSON should be much faster and much compact. I guess the closest thing is ASN1, but the Google proposal seem much simpler (or may I say more ad-hoc). What I am not sure how it compares with is Thrift ( http://developers.facebook.com/thrift/ ). It seems mostly the same. On Thu, Jul 10, 2008 at 8:29 AM, Christian Scholz / Tao Takashi (SL) < tao.takashi@googlemail.com> wrote: > Indeed, thanks for the link! > I just tried out the Python version and tried to got it running inside > a buildout. Works now but could be packaged better IMHO. > I might test this with pyogp by implementing a new serializer with it. > > As what serialization to use is still a question though as all have > their advantages and disadvantages. e.g. JSON would have the advantage > of being known to many developers. But Google has some weight so > protobuf might also be somewhat known very soon while LLSD probably > not so much. As for efficiency it will probably also come down to > protobuf. > > But as OGP hopefully allows not only one serialization it should be > fine. We just need a way to let components find out what > serializations are supported. > > -- Tao > > On Wed, Jul 9, 2008 at 8:06 PM, John Hurliman > wrote: > > Thanks for the link. I'm in the process of adding C# support, and if I > have > > time I might reimplement a few SL packets as protobufs to do comparisons. > If > > a few tweaks were made to allow mostly empty byte arrays to pack down > (I'm > > thinking LayerData), zerocoding would become unnecessary and you remove > one > > of the most complex* parts of a high performance implementation of the > > network layer. The only change I would probably make would be adding > native > > support for important datatypes (vector2/3/4, quaternion, uuid). Being > able > > to throw away the message template and the three different serialization > > formats of LLSD and replace them with a single fast and terse > implementation > > would be very nice. > > > > Still can't figure out why the release build of libprotobuf.dll is over > > 700KB though. More digging required. > > > > * Allocating a new ~2KB block of memory every time a zerocoded packet > comes > > in or goes out is going to fragment memory really quickly. To get around > > this you need a dynamic pool of buffers to pack/unpack messages, and > handle > > checking in and checking out buffers to the pool (like a threadpool for > > memory chunks). > > > > > > John > > > > On Tue, Jul 8, 2008 at 1:32 PM, Argent wrote: > >> > >> Just announced on slashdot: > >> > >> > >> > http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html > >> > >> A fast, compact IDL that's got a well-tested open-source implementation > >> and is an order of magnitude faster than XML? > >> > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > > > > -- > Christian Scholz > Tao Takashi (Second Life name) > taotakashi@gmail.com > Blog/Podcast: http://mrtopf.de/blog > Planet: http://worldofsl.com > > Company: http://comlounge.net > Tech Video Blog: http://comlounge.tv > IRC: MrTopf/Tao_T > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080710/f1519689/attachment.htm From jhurliman at jhurliman.org Wed Jul 9 19:57:18 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Wed Jul 9 19:57:20 2008 Subject: [sldev] Google data exchange format In-Reply-To: <487566B6.20405@cox.net> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> <48755D29.9000903@cox.net> <487566B6.20405@cox.net> Message-ID: I'm not sure LLSD-GDE (protobuf) carries any meaning. LLSD (in the abstract sense, not one of the three serializations) defines how objects (and arrays and key value pairs and so on) are set/accessed in code, and protobuf generates a series of classes that define how you set/access objects in code. libprotobuf also provides methods to hook in new serialization/deserialization methods. LLSD, LL's message template system, and protobuf all do the exact same thing in slightly different ways. You can implement message_template in protobuf or make an LLSD-Binary serializer for protobuf for fun and profiling/comparison (the SL protocol already implements message_template in LLSD-XML to complete the circle), but I don't think it would make sense to use a mashup of two or three of the systems as a standard. John On Wed, Jul 9, 2008 at 6:32 PM, Lawson English wrote: > Lawson English wrote: > >> >> Seems to me that LLSD would be a single format file in this system. If it >> is robust enough, could replace the LLSD XML format without any code changes >> save the one function. Would allow for gradual switchover since a new viewer >> could request caps to use the new format, while the default would be the >> current format. >> >> > Also, seems to me that pyogp would be a great test for comparing throughput > using LLSD-XML vs LLSD-GDE. > > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080709/d1951885/attachment-0001.htm From rdw at lindenlab.com Wed Jul 9 21:15:28 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Jul 9 21:15:31 2008 Subject: [sldev] Google data exchange format In-Reply-To: <4875790D.5080105@lindenlab.com> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com><23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com><48755D29.9000903@cox.net><487566B6.20405@cox.net> <4875790D.5080105@lindenlab.com> Message-ID: <48758CE0.6080803@lindenlab.com> Ryan Williams (Which) wrote: > Lawson English wrote: >> Lawson English wrote: >>> >>> Seems to me that LLSD would be a single format file in this system. >>> If it is robust enough, could replace the LLSD XML format without >>> any code changes save the one function. Would allow for gradual >>> switchover since a new viewer could request caps to use the new >>> format, while the default would be the current format. >>> >> >> Also, seems to me that pyogp would be a great test for comparing >> throughput using LLSD-XML vs LLSD-GDE. > There is, you know, llsd-binary, Described here : http://wiki.secondlife.com/wiki/LLSD#Binary_Serialization -RYaN From lenglish5 at cox.net Wed Jul 9 21:59:03 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Jul 9 21:59:05 2008 Subject: [sldev] Google data exchange format In-Reply-To: <48758CE0.6080803@lindenlab.com> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com><23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com><48755D29.9000903@cox.net><487566B6.20405@cox.net> <4875790D.5080105@lindenlab.com> <48758CE0.6080803@lindenlab.com> Message-ID: <48759717.80009@cox.net> Ryan Williams (Which) wrote: > Ryan Williams (Which) wrote: >> Lawson English wrote: >>> Lawson English wrote: >>>> >>>> Seems to me that LLSD would be a single format file in this system. >>>> If it is robust enough, could replace the LLSD XML format without >>>> any code changes save the one function. Would allow for gradual >>>> switchover since a new viewer could request caps to use the new >>>> format, while the default would be the current format. >>>> >>> >>> Also, seems to me that pyogp would be a great test for comparing >>> throughput using LLSD-XML vs LLSD-GDE. >> There is, you know, llsd-binary, > Described here : > http://wiki.secondlife.com/wiki/LLSD#Binary_Serialization > Thanks. I seem to recall that Zero announced that LLSD binary would be deprecated because he couldn't' find anyone who was using it. Of course, with http and r-http (PTTH) it might be worth looking at again. Always something. L. From chaosstar at gmail.com Thu Jul 10 00:06:21 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Jul 10 00:06:25 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STL compatibility issue In-Reply-To: References: <1dsnkw3ds4ds4ds4ef4ds9kz.alissa_sabre@yahoo.co.jp> <9bb32d430807090930x3e217730ta95bc4dd86832c21@mail.gmail.com> Message-ID: <9bb32d430807100006t543e24f2g7ade9d57bf790998@mail.gmail.com> Indeed. The steps for building 1.20RC on VS2005 successfully on my system were: (some here are system and preference-specific, I included them for completeness) 1. unpack src, lib, artwork into the same folder 2. copy pre-prepared 3rd party library 'linden' folder in (built as described on the OSS wiki) 3. copy the llimagej2coj.vcproj to llimagej2coj_vc8.vcproj 4. copy EZ_LCD_wrapper.lib to EZ_LCD_wrapper_vc8.lib 5. switching to ReleaseForDownload 6. deactivating the test project 7. compile optional/system-specific before compile: 1.edit lscript/lscript_compile/lscript_compile_fb_vc8.vcproj and add absolute paths to the exes, due to a weird cygwin install (included in case others have that issue) 2. to remove quicktime support: setting quicktime support to 0 in llmediabase.h and removing qtmllib in the newview project linker settings 3. deactivating crashlogger and updater projects (I merely copy the compiled secondlife.exe into a properly installed viewer. Seems easiest to me.) 4. very optional: mass-select all projects except the lscript_compile_vc8 -> preferences, change optimization/c++ preference settings. A note to Soft: llimagej2coj_vc8.vcproj and _vc9 are missing. As described above, I merely copy the plain one with the new filename, but it requires an unnecessary step. The same goes for the EZ_LCD_wrapper.lib, which should exist in _vc8.lib format as well per default. On Wed, Jul 9, 2008 at 23:59, David Matovich wrote: > On Wed, Jul 9, 2008 at 12:30 PM, Ambrosia wrote: >> >> What surprises me here is that you are having the same issue with >> VS2005..it compiled (well, ran) >> fine for me there. Tho I must note, I did compile ReleaseForDownload, >> in both cases. > > I agree, 1.20 built for me with minimal issues. Off the top of my head, I > had to rename the EZ LCD wrapper, unload the "Test" project, and import the > llimage2coj (or whatever it is) project. Other than that, i used the stock > indra_complete_vc8 solution. > > From alissa_sabre at yahoo.co.jp Thu Jul 10 04:17:57 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Jul 10 04:18:13 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STL compatibility issue In-Reply-To: References: <1dsnkw3ds4ds4ds4ef4ds9kz.alissa_sabre@yahoo.co.jp> <9bb32d430807090930x3e217730ta95bc4dd86832c21@mail.gmail.com> Message-ID: <7adtae04fL8ePudY4L4mfbah.alissa_sabre@yahoo.co.jp> Thank you, Chalice and Soft, for comments. > Yes, 1.20 is still VS2003-based. > From 1.21 going forward, VS2005 will be the standard. Yes, I know it. What I don't know is how those Linden devs working on 1.21 with VS2005 internally overcame the Microsoft STL compatibility issue. > I know others have gotten > VS2005 to work with the 1.20 drop, so don't be dissuaded It's a good news. > I had that issue described below when compiling 1.20 RC12 with VS2008 Express. > Try compiling again with the ReleaseForDownload setup in your > VS2005...I'd be interested > to hear if you still get this issue. Well, I have already tried both builds, and there are no differences. More precisely, * A ReleaseNoOpt build run under debugger ... access violation, * A ReleaseForDownload build run under debugger ... access violation, * A ReleaseNoOpt build run without debugger ... 100% CPU before opening window, and * A ReleaseForDownload build run without debugger ... 100% CPU before opening window. When removed _SECURE_SCL=0, executables both from ReleaseNoOpt build and from ReleaseForDownload build run fine. I'm almost sure _SECURE_SCL=0 is causing problem in 1.20.12. What I'm not sure is whether the _problem_ that were observed before June 2007 and _solved_ by adding _SECURE_SCL=0 is still there. If it is, simply removing _SECURE_SCL=0 is not a real solution. I guess I can avoid both issues by rebuilding boost *.lib with _SECURE_SCL=0, but I'm too lazy to even think of doing it by myself. (boost has its own custom build system, BoostJam, that seems unordinary enough to make me off from it.) Alissa Sabre -------------------------------------- Stop! Global Warming ~ Yahoo! JAPAN Earth Project http://pr.mail.yahoo.co.jp/earthproject/ From suzhanna.rossini at balsaestates.com Thu Jul 10 05:30:30 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Thu Jul 10 05:30:43 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: <00a101c8e064$69278c10$3b76a430$@rossini@balsaestates.com> References: <00a101c8e064$69278c10$3b76a430$@rossini@balsaestates.com> Message-ID: <001001c8e288$bdffd9b0$39ff8d10$@rossini@balsaestates.com> Really noone that have any ideas on how to solve this? > > I'm trying to build the client with VS2008, and everything works smooth > and > fine up to linking, I get this no matter how I try: > > 3>Linking... > 3>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void > __thiscall LLFloaterCompileQueue::compile(class > std::basic_string,class > std::allocator > const &,class LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@ > D@std > @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) > 3>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > > Anyone with ideas please? Currently I'm using a svn pull of "Release", > r732. From robin.cornelius at gmail.com Thu Jul 10 05:44:55 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jul 10 05:44:58 2008 Subject: [sldev] Open source meeting, call for items, Thursday 2PM In-Reply-To: References: Message-ID: Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda See you in Hippotropolis later. Robin From soft at lindenlab.com Thu Jul 10 06:14:42 2008 From: soft at lindenlab.com (Soft) Date: Thu Jul 10 06:14:44 2008 Subject: [sldev] Unresolved externals In-Reply-To: <-5008687841307650898@unknownmsgid> References: <-5008687841307650898@unknownmsgid> Message-ID: I would start by looking at lscript_compile to see whether the parameters, return type and calling convention match between the header and the function body. It's possible VS2008 is stricter about some attribute than VS2003 and VS2005 are - so far as I know, there isn't any type checking at all on "C" (cdecl) symbols in either. On Thu, Jul 10, 2008 at 7:30 AM, Suzhanna Rossini wrote: > Really noone that have any ideas on how to solve this? > > >> >> I'm trying to build the client with VS2008, and everything works smooth >> and >> fine up to linking, I get this no matter how I try: >> >> 3>Linking... >> 3>llcompilequeue.obj : error LNK2019: unresolved external symbol "int >> __cdecl lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void >> __thiscall LLFloaterCompileQueue::compile(class >> std::basic_string,class >> std::allocator > const &,class LLUUID const &)" >> (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@ >> D@std >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) >> 3>llpreviewscript.obj : error LNK2001: unresolved external symbol "int >> __cdecl lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) >> >> Anyone with ideas please? Currently I'm using a svn pull of "Release", >> r732. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From phoenix at secondlife.com Thu Jul 10 08:41:22 2008 From: phoenix at secondlife.com (Phoenix) Date: Thu Jul 10 08:41:24 2008 Subject: [sldev] Google data exchange format In-Reply-To: <48759717.80009@cox.net> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com><23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com><48755D29.9000903@cox.net><487566B6.20405@cox.net> <4875790D.5080105@lindenlab.com><48758CE0.6080803@lindenlab.com> <48759717.80009@cox.net> Message-ID: On 2008-07-09, at 21:59 , Lawson English wrote: >>> There is, you know, llsd-binary, >> Described here : http://wiki.secondlife.com/wiki/LLSD#Binary_Serialization >> > Thanks. I seem to recall that Zero announced that LLSD binary would > be deprecated because he couldn't' find anyone who was using it. Of > course, with http and r-http (PTTH) it might be worth looking at > again. Zero did not look very hard. We use llsd+binary for at least 2 different major internal systems which have greater performance requirements than llsd+xml can provide. The serialization format may never be part of the open grid, but we will continue to support and use it in multiple platforms and languages for a long time. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080710/9b71043b/PGP.pgp From lenglish5 at cox.net Thu Jul 10 13:34:12 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jul 10 13:34:14 2008 Subject: [sldev] Open source meeting, call for items, Thursday 2PM In-Reply-To: References: Message-ID: <48767244.6020403@cox.net> Robin Cornelius wrote: > Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis > http://slurl.com/secondlife/Hippotropolis/239/28/24 > > As usual, any items for discussion please add to :- > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > See you in Hippotropolis later. > > OGP/PYOGP/Open Grid Beta? Not saying that I'm going to talk about all of these just thinking there should be a time to present what is going on regarding these projects to the rest of the open source folk. Lawson From lenglish5 at cox.net Thu Jul 10 13:35:36 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jul 10 13:35:38 2008 Subject: [sldev] Google data exchange format In-Reply-To: References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com><23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com><48755D29.9000903@cox.net><487566B6.20405@cox.net> <4875790D.5080105@lindenlab.com><48758CE0.6080803@lindenlab.com> <48759717.80009@cox.net> Message-ID: <48767298.8070206@cox.net> Phoenix wrote: > On 2008-07-09, at 21:59 , Lawson English wrote: > >>>> There is, you know, llsd-binary, >>> Described here : >>> http://wiki.secondlife.com/wiki/LLSD#Binary_Serialization >>> >> Thanks. I seem to recall that Zero announced that LLSD binary would >> be deprecated because he couldn't' find anyone who was using it. Of >> course, with http and r-http (PTTH) it might be worth looking at again. > > Zero did not look very hard. We use llsd+binary for at least 2 > different major internal systems which have greater performance > requirements than llsd+xml can provide. The serialization format may > never be part of the open grid, but we will continue to support and > use it in multiple platforms and languages for a long time. > Well II may have misunderstood him or misremembered anyway. Blame the messenger on this one... Lawson From markl at lindenlab.com Thu Jul 10 13:55:14 2008 From: markl at lindenlab.com (Mark Lentczner) Date: Thu Jul 10 13:55:16 2008 Subject: [sldev] Google data exchange format In-Reply-To: References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com><23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com><48755D29.9000903@cox.net><487566B6.20405@cox.net><4875790D.50 80105@lindenlab.com><48758CE0.6080803@lindenlab.com><48759717.80009@cox.net> Message-ID: <0057F930-EFE6-4099-AB76-5213EE5BABC8@lindenlab.com> Intriguing as Google Protocol Buffers are, they do not look like a reasonable replacement or serialization for LLSD. GPB requires a single, central line of "truth" for evolution. For example, it isn't possible for Alice and Bob to both work on extensions to a given message: The field numbers will collide. At some point, if both extensions are to be used, they must be merged and one or the other renumbered. At that point, all data in the wild for the renumbered extension now must be carefully eradicated, lest being confused for the other extension's data. In contrast, Alice and Bob can both work on extensions in LLSD with far less of this problem. Either they can just choose names for their extended fields and assume they won't collide (most common), or they and prefix their field names for uniqueness. While not perfect, LLSD's full self-description of field names better enables simultaneous development. Of course, it extracts a price for that in bytes over the wire and in memory. GPB is much more like the Message Template system, though somewhat more flexible than the current Message Template in several ways. Nonetheless, doesn't seem much of a huge win to convert at this point. As for the implementation of Message Templates - I'm SURE that it can be improved upon with far less work than converting to GPB would entail. As their announcement guessed, I'm thinking "Yet another IDL?" I recognize that most existing systems have grown complicated (though will GPB go this route too?), but several of them are well-supported standards. Since GPB doesn't seem to improve any particular aspect of them (only simplify and sub-set), I'm not sure why they didn't just use one. LLSD goes in a distinctly different direction. It is a different sort of IDL, describing a much looser coupling, expressly trading compactness and strictness for long term deployment and evolution. I still think we should be using LLSD for all OGP interaction. (Serialization, whether XML, JSON, or binary is a separate matter.) > Thanks. I seem to recall that Zero announced that LLSD binary would > be deprecated because he couldn't' find anyone who was using it. > Zero did not look very hard. We use llsd+binary for at least 2 > different major internal systems ... I believe I was looking for places where LL's use of LLSD binary is exposed between sim and viewer. - Zero Mark Lentczner Engineering Director API & Architecture Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From qarl at lindenlab.com Thu Jul 10 14:50:49 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Thu Jul 10 14:50:51 2008 Subject: [sldev] GSoC - mesostructures Message-ID: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> hey everyone - i'd like to give an update about our mesostructure google summer of code project. Ravish Mehra is the principle implementer for the project - and he's making good headway. he's created a wiki page to discuss the work and show some preliminary snapshots: https://wiki.secondlife.com/wiki/Mesostructures_GSoC_2008 he hasn't yet release the code to his library - but if you ask him nicely, perhaps you can convince him to do so. :) K. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080710/b0e36ad8/attachment.htm From lenglish5 at cox.net Thu Jul 10 15:54:15 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jul 10 16:09:40 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> Message-ID: <48769317.8090406@cox.net> Karl Stiefvater wrote: > hey everyone - > > i'd like to give an update about our mesostructure google summer of > code project. > > Ravish Mehra is the principle implementer for the project - and he's > making good headway. he's created a wiki page to discuss the work and > show some preliminary snapshots: > > https://wiki.secondlife.com/wiki/Mesostructures_GSoC_2008 > > he hasn't yet release the code to his library - but if you ask him > nicely, perhaps you can convince him to do so. :) > Would this be used in specific textures, or what it modify the existing "materials" options or what? It looks very kool, but I'm trying to figure out where it would apply specifically in the SL building architecture. Lawson From qarl at lindenlab.com Thu Jul 10 16:33:46 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Thu Jul 10 16:33:48 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <48769317.8090406@cox.net> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> Message-ID: yeah - that's a good question. nothing has yet been decided about how to use the new technology... right now we'll just make a proof of concept viewer (probably off Dave's shadow branch) and use the existing bump maps as the relief map. someday, we'll want to provide the ability to upload/attach some new height map - but then we'd also like to be able to upload/attach specular, reflection, normal, etc, etc, maps for our materials. perhaps that someday might eventually come. :) K. On Jul 10, 2008, at 3:54 PM, Lawson English wrote: > Karl Stiefvater wrote: >> hey everyone - >> >> i'd like to give an update about our mesostructure google summer of >> code project. >> >> Ravish Mehra is the principle implementer for the project - and >> he's making good headway. he's created a wiki page to discuss the >> work and show some preliminary snapshots: >> >> https://wiki.secondlife.com/wiki/Mesostructures_GSoC_2008 >> >> he hasn't yet release the code to his library - but if you ask him >> nicely, perhaps you can convince him to do so. :) >> > Would this be used in specific textures, or what it modify the > existing "materials" options or what? It looks very kool, but I'm > trying to figure out where it would apply specifically in the SL > building architecture. > > > Lawson From lenglish5 at cox.net Thu Jul 10 16:48:15 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Jul 10 16:48:19 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> Message-ID: <48769FBF.4040206@cox.net> Karl Stiefvater wrote: > yeah - that's a good question. nothing has yet been decided about how > to use the new technology... > > right now we'll just make a proof of concept viewer (probably off > Dave's shadow branch) and use the existing bump maps as the relief map. > > someday, we'll want to provide the ability to upload/attach some new > height map - but then we'd also like to be able to upload/attach > specular, reflection, normal, etc, etc, maps for our materials. > > perhaps that someday might eventually come. :) Ah well, if its off the shaodw viewer, its not for macs of any kind, it seems... ;( Lawson From dahliatrimble at gmail.com Thu Jul 10 17:02:33 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Jul 10 17:02:35 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> Message-ID: Looks interesting, but I bet it would be a challenge to have a matching collision mesh. On Thu, Jul 10, 2008 at 2:50 PM, Karl Stiefvater wrote: > > > hey everyone - > > i'd like to give an update about our mesostructure google summer of code > project. > > Ravish Mehra is the principle implementer for the project - and he's making > good headway. he's created a wiki page to discuss the work and show some > preliminary snapshots: > > https://wiki.secondlife.com/wiki/Mesostructures_GSoC_2008 > he hasn't yet release the code to his library - but if you ask him nicely, > perhaps you can convince him to do so. :) > > > > K. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080710/ff509819/attachment.htm From darien.caldwell at gmail.com Thu Jul 10 20:39:44 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Thu Jul 10 20:39:47 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> Message-ID: <835a5b860807102039v70212b9ek17ac1191025f4789@mail.gmail.com> /me wants badly. :) On 7/10/08, Dahlia Trimble wrote: > Looks interesting, but I bet it would be a challenge to have a matching > collision mesh. > > > On Thu, Jul 10, 2008 at 2:50 PM, Karl Stiefvater wrote: > >> >> >> hey everyone - >> >> i'd like to give an update about our mesostructure google summer of code >> project. >> >> Ravish Mehra is the principle implementer for the project - and he's >> making >> good headway. he's created a wiki page to discuss the work and show some >> preliminary snapshots: >> >> https://wiki.secondlife.com/wiki/Mesostructures_GSoC_2008 >> he hasn't yet release the code to his library - but if you ask him nicely, >> perhaps you can convince him to do so. :) >> >> >> >> K. >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From jacek.antonelli at gmail.com Thu Jul 10 22:12:01 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Thu Jul 10 22:12:04 2008 Subject: [sldev] Re: Req. for peer review: Convert Advanced menu to XUI In-Reply-To: <105c09f0807081350g61a7701o86c998f05b2b7064@mail.gmail.com> References: <105c09f0807081350g61a7701o86c998f05b2b7064@mail.gmail.com> Message-ID: <105c09f0807102212g4ba56eacsff336e142b97f3ec@mail.gmail.com> On Tue, Jul 8, 2008 at 3:50 PM, Jacek Antonelli wrote: > I've spent the past 2 days updating my work on VWR-2896 > (http://jira.secondlife.com/browse/VWR-2896) to apply to the menus on > the latest RCs. > > I've checked it pretty thoroughly, but it's a big change, so some > extra eyes would be appreciated. > > In particular, I want to make sure that the patches apply cleanly for > other people. I did all the development on this with Git, and this is > the first patch I've generated from that, so I want to make sure it's > good. I've updated VWR-2896 and its subtasks (VWR-2947 and VWR-2948) with the new patches. Votes and Linden lovin' appreciated. :-) - Jacek From qarl at lindenlab.com Thu Jul 10 22:13:56 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Thu Jul 10 22:14:15 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <20080711033951.D66D641B2E8@stupor.lindenlab.com> References: <20080711033951.D66D641B2E8@stupor.lindenlab.com> Message-ID: <1EB1B80B-5AC1-4179-A4BB-8E2CD06CA481@lindenlab.com> > Looks interesting, but I bet it would be a challenge to have a > matching > collision mesh. yeah - i don't think we'd even try. the ideal use of a mesostructure is for details - the rocky surface of a wall, rough bark on a tree, an engraved surface, or anytime you want to "break up" that super smooth surface that traditional meshes give you. (see the attached image for a nice example of how well it works: the mesh of the model is very low- rez - all the detail is in a mesostructure-like faux surface.) we're also considering using them to improve the impostor system. K. -------------- next part -------------- A non-text attachment was scrubbed... Name: journey-previs.jpg Type: image/jpeg Size: 1670770 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080710/62fbb3de/journey-previs-0001.jpg -------------- next part -------------- From tao.takashi at googlemail.com Fri Jul 11 01:23:31 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Fri Jul 11 01:23:33 2008 Subject: [sldev] Google data exchange format In-Reply-To: <48767298.8070206@cox.net> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> <48755D29.9000903@cox.net> <487566B6.20405@cox.net> <4875790D.5080105@lindenlab.com> <48758CE0.6080803@lindenlab.com> <48759717.80009@cox.net> <48767298.8070206@cox.net> Message-ID: <23bbb49e0807110123p696fab61gd99ce1ab48de9c0e@mail.gmail.com> Just FYI: Kenton Varda of Google released the Python version now as a Python Egg: http://pypi.python.org/pypi/protobuf Besides that I also created an IRC channel on freenode (#protobuf) and the Google Group seems to be quite active so I would suppose that it will gain quite some traction. All in all it's also a good example of how open sourcing an internal project can work. -- Tao On Thu, Jul 10, 2008 at 11:35 PM, Lawson English wrote: > Phoenix wrote: >> >> On 2008-07-09, at 21:59 , Lawson English wrote: >> >>>>> >>>>> There is, you know, llsd-binary, >>>> >>>> Described here : >>>> http://wiki.secondlife.com/wiki/LLSD#Binary_Serialization >>>> >>> Thanks. I seem to recall that Zero announced that LLSD binary would be >>> deprecated because he couldn't' find anyone who was using it. Of course, >>> with http and r-http (PTTH) it might be worth looking at again. >> >> Zero did not look very hard. We use llsd+binary for at least 2 different >> major internal systems which have greater performance requirements than >> llsd+xml can provide. The serialization format may never be part of the open >> grid, but we will continue to support and use it in multiple platforms and >> languages for a long time. >> > Well II may have misunderstood him or misremembered anyway. Blame the > messenger on this one... > > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From aimee at ama-zing.co.uk Fri Jul 11 05:08:52 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Jul 11 05:08:57 2008 Subject: [sldev] GSoC - mesostructures References: <5D7CF938-A24D-4BEA-8A77-8C2A036B1E1F@ama-zing.co.uk> Message-ID: On Jul 11, 2008, at 06:13, Karl Stiefvater wrote: > we're also considering using them to improve the impostor system. I guess this could avoid things like impostors legs disappearing inside seats, which would be nice :) Aimee. From spot at napalmriot.com Fri Jul 11 08:04:08 2008 From: spot at napalmriot.com (Spot) Date: Fri Jul 11 08:04:13 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: References: <5D7CF938-A24D-4BEA-8A77-8C2A036B1E1F@ama-zing.co.uk> Message-ID: <48777668.1060302@napalmriot.com> Would this process be viable if applied to clothing textures? The possibilities there are quite interesting to contemplate. Spot Aimee Walton wrote: > On Jul 11, 2008, at 06:13, Karl Stiefvater wrote: > >> we're also considering using them to improve the impostor system. > > I guess this could avoid things like impostors legs disappearing > inside seats, which would be nice :) > > Aimee. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From monkowsk at watson.ibm.com Fri Jul 11 08:17:56 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jul 11 08:18:08 2008 Subject: [sldev] IJIRA and PJIRA Message-ID: <487779A4.2070309@watson.ibm.com> After a discussion yesterday at the open source meeting concerning VWR-3943 it occurred to me that the Linden Open Source project is very much unlike most open source projects because of the internal vs. public bug tracking. One of the primary advantages of open source is that you have a lot of people looking at and fixing bugs. Yet the SL viewer has more bugs than the Adirondacks in spring. The reason, I suggest, is the IJIRA/PJIRA divide. I had looked at VWR-3943 back in April, but wasn't able to reproduce the problem on my system. I suggested several possible causes for that. Yet there was no response from Lindens and there is only one Linden who is watching the issue. In fact, the only comments anywhere in the issue are by Torley Linden, who is not a developer. If I were working on the problem, I'd look at the crash logs to find some correlation with the users' configuration. I can't do that because the crash logs, which contain resident information, are understandably kept confidential. And if any Linden has found any correlations, there is now way for me to know that. Since LL started their recent push for viewer stability, I have been less inclined to work on bugs, because I expect someone from Linden, working on it full time, would solve them, and my time would be wasted. If there were a tiny bit of visibility concerning any progress on bugs by Lindens, things might be quite different. For example, when VWR-3943 was changed to "Fixed" in May, did that reflect the real situation inside LL or was that just a mistake? There's no way of knowing. I can understand why LL might want to keep pesky residents from commenting and raising issues on the internal JIRA, but what's the reason for keeping it secret? It's clear that the IJIRA could be made available in read-only mode, since that is what PJIRA looks like without a login. It's also clear that categories of issues can be kept hidden since the NAV issues were hidden on PJIRA when they were first created. So is there a reason for keeping IJIRA secret that outweighs the possible benefit of collaborating with open source developers? Mike Mm Alder From matthew.dowd at hotmail.co.uk Fri Jul 11 09:09:39 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jul 11 09:09:42 2008 Subject: [sldev] Google data exchange format In-Reply-To: <23bbb49e0807110123p696fab61gd99ce1ab48de9c0e@mail.gmail.com> References: <16309a040807081332x6134e74ds74a02d93ca71f236@mail.gmail.com> <23bbb49e0807091629u7bbde7aejabf659255583e6ef@mail.gmail.com> <48755D29.9000903@cox.net> <487566B6.20405@cox.net> <4875790D.5080105@lindenlab.com> <48758CE0.6080803@lindenlab.com> <48759717.80009@cox.net> <48767298.8070206@cox.net> <23bbb49e0807110123p696fab61gd99ce1ab48de9c0e@mail.gmail.com> Message-ID: Maybe I'm missing something but as far as I can tell Google has a) (re)invented yet another data description language of which there are already plentiful (e.g. XML Schema and ASN.1 to name but two) b) (re)invented yet another data serialisation of which there are already plentiful (e.g. XML and BER to name but two). I've separated these out as how you describe data structures and how you serialise are independent (and you can mixed and match) - to illustrate this if I want to serialise a data structure described in XML Schema using the google data exchange format, all I need to do is write something (say in perl) to convert XML Schemas to googles data description language. Likewise a perl script to convert google data language to XML schema would easbily allow serialising google described data in XML. Typically the serilialisation used for interoperable data exchange isn't the same serialisation as used internally by software/system. This is because the exchange format is optimised for description, readability, adaptability (as the interchange format may contain data not used by all the systems it is designed to interchange with), whereas the internal serialisations are optimised for performance - often it isn't possible to optimise for both used simultaneously. Matthew > Date: Fri, 11 Jul 2008 11:23:31 +0300 > From: tao.takashi@googlemail.com > To: lenglish5@cox.net > Subject: Re: [sldev] Google data exchange format > CC: sldev@lists.secondlife.com; rdw@lindenlab.com > > Just FYI: Kenton Varda of Google released the Python version now as a > Python Egg: > > http://pypi.python.org/pypi/protobuf > > Besides that I also created an IRC channel on freenode (#protobuf) and > the Google Group seems to be quite active so I would suppose that it > will gain quite some traction. All in all it's also a good example of > how open sourcing an internal project can work. _________________________________________________________________ 100?s of Nikon cameras to be won with Live Search http://clk.atdmt.com/UKM/go/101719808/direct/01/ From matthew.dowd at hotmail.co.uk Fri Jul 11 09:22:40 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jul 11 09:22:43 2008 Subject: [sldev] IJIRA and PJIRA In-Reply-To: <487779A4.2070309@watson.ibm.com> References: <487779A4.2070309@watson.ibm.com> Message-ID: > After a discussion yesterday at the open source meeting concerning > VWR-3943 it occurred to me that the Linden Open Source project is very > much unlike most open source projects because of the internal vs. public > bug tracking. This is a discussion we have had in the past - it isn't just having two JIRAs but also an internal and external svn repositories, and there have been times when this chinese wall divide colours attitudes and behaviours. To be honest, it isn't uncommon in the early stages of a closed source project moving to an open source development model for it to have an uncomfortable amalgam of close and open source development models. The frustration from many of the contributors outside of LL, is that the SL Viewer project has seemed stuck in this amalgam for over a year with little signs of progress (or motivation) of moving out. To be fair, there has been some promising progress in recent months (more Linden's appearing on this list rather than staying within the LL internal lists, roadmaps being discussed in the open etc.). Re PJIRA/IJIRA, I have been concerned by a) some Linden's admitting that they don't track PJIRA even for their own development areas (i.e. waiting until things get imported) b) a suspicion that if an imported but closed issue is reopened in PJIRA, no indication that the linked PJIRA issue has been repopened is indicated in IJIRA (regardless how valid the reason for reopening) - this suspicion is based on the number of times a Linden has recommended opening a new PJIRA issue rather than reopening an existing one. Matthew _________________________________________________________________ 100?s of Nikon cameras to be won with Live Search http://clk.atdmt.com/UKM/go/101719808/direct/01/ From matthew.dowd at hotmail.co.uk Fri Jul 11 09:27:58 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jul 11 09:28:00 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <48769317.8090406@cox.net> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> Message-ID: Again, I may be missing something - but this is how I originally expected sculpts to work when they were initially described. (And like sculpts, the collision maps could be done on the base prims rather than the relief maps). Matthew > Date: Thu, 10 Jul 2008 15:54:15 -0700 > From: lenglish5@cox.net > To: qarl@lindenlab.com > Subject: Re: [sldev] GSoC - mesostructures > CC: sldev@lists.secondlife.com; ravish.mehra07@gmail.com > > Karl Stiefvater wrote: >> hey everyone - >> >> i'd like to give an update about our mesostructure google summer of >> code project. >> >> Ravish Mehra is the principle implementer for the project - and he's >> making good headway. he's created a wiki page to discuss the work and >> show some preliminary snapshots: >> >> https://wiki.secondlife.com/wiki/Mesostructures_GSoC_2008 >> >> he hasn't yet release the code to his library - but if you ask him >> nicely, perhaps you can convince him to do so. :) >> > Would this be used in specific textures, or what it modify the existing > "materials" options or what? It looks very kool, but I'm trying to > figure out where it would apply specifically in the SL building > architecture. > > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges _________________________________________________________________ The John Lewis Clearance - save up to 50% with FREE delivery http://clk.atdmt.com/UKM/go/101719806/direct/01/ From qarl at lindenlab.com Fri Jul 11 10:27:48 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Fri Jul 11 10:27:51 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> Message-ID: > Again, I may be missing something - but this is how I originally > expected sculpts to work when they were initially described. heh... i think maybe you have too high of expectations. :) this technology is still EXTREMELY young and experimental. remember that when pixar puts this level of detail in a movie - each shot takes days of rendering time. in a realtime engine - these things have never before been possible. but you do raise an interesting idea: perhaps the best way to quickly integrate mesostructure technology into our system is via the sculpt map - the artist provides a high resolution sculpt map - which still creates the standard low resolution mesh - but the details are fleshed- out via mesostructures..... very interesting... K. From lenglish5 at cox.net Fri Jul 11 12:26:53 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jul 11 12:26:56 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> Message-ID: <4877B3FD.5090400@cox.net> Karl Stiefvater wrote: >> Again, I may be missing something - but this is how I originally >> expected sculpts to work when they were initially described. > > heh... i think maybe you have too high of expectations. :) > > this technology is still EXTREMELY young and experimental. remember > that when pixar puts this level of detail in a movie - each shot takes > days of rendering time. in a realtime engine - these things have > never before been possible. > > but you do raise an interesting idea: perhaps the best way to quickly > integrate mesostructure technology into our system is via the sculpt > map - the artist provides a high resolution sculpt map - which still > creates the standard low resolution mesh - but the details are > fleshed-out via mesostructures..... > > very interesting... Of course, sculpt maps only have one collion model right now, anyway. Torus? Sphere? Can't remember. Lawson From kwerks.sl at gmail.com Fri Jul 11 13:26:02 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Fri Jul 11 13:26:06 2008 Subject: [sldev] IJIRA and PJIRA In-Reply-To: References: <487779A4.2070309@watson.ibm.com> Message-ID: <7b61e3970807111326u265b519agece0fce5d62bca9b@mail.gmail.com> > a) some Linden's admitting that they don't track PJIRA even for their own > development areas (i.e. waiting until things get imported) FWIW, this particularly has held me back from spending more time with the code. I have no idea if what I would like to work on makes any sense in the big picture or who to contact about the sense of it and ultimately, why bother working on something if it will just be ignored or is already being done? It would be most excellent to have a view of the inside. Maybe just read-only and for people who have submitted patches? Just a thought. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080711/694aff07/attachment.htm From robla at lindenlab.com Fri Jul 11 13:35:27 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jul 11 13:35:38 2008 Subject: [sldev] Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com> Message-ID: <4877C40F.2050901@lindenlab.com> On 7/11/08 9:22 AM, Matthew Dowd wrote: > To be honest, it isn't uncommon in the early stages of a closed source > project moving to an open source development model for it to have an > uncomfortable amalgam of close and open source development models. The > frustration from many of the contributors outside of LL, is that the > SL Viewer project has seemed stuck in this amalgam for over a year > with little signs of progress (or motivation) of moving out. I'm largely to blame for that. Those of us administering our public JIRA instance have had a tough time making sure it's stable/fast/functional enough to actually migrate to it for production use. Thankfully (er, hopefully) the days of nasty PJIRA instability issues are behind us, so that habitual excuse is dissipating. Not to mention that we're gradually shifting responsibility for PJIRA work to people better at that kind of thing than I am. Brian Aker of MySQL fame pointed out in a blog discussion [1] with Theodore Ts'o of Linux kernel development fame that there's not really a successful blueprint for taking projects open source. It's something we'll be discussing more at OSCON on a panel titled "Does Open Source Need to Be "Organic"?"[2] where "organic" is (arguably) defined as a project which the first release included source, and is generally characterized as by a distributed development team with no single company truly in control, and "inorganic" is generally code that started off life as a proprietary effort. I realize that this makes participating in "organic" open source projects is often more appealing, since they generally start from day one with public tools for everything. It's much more comfortable as a community member to at least have the full visibility of a peer from the first day you take an interest in a project, even if you probably won't be treated as one until you really prove your mettle. There are many companies-driven open source projects that drag their feet at getting that level of transparency, and we're no exception, so many people in the community get rightfully get frustrated, because they imagine how much more they could potentially help with a peer's level access to the tools and information. They are probably correct in thinking that companies that don't do it as quickly as possible are squandering a big opportunity, and get tired of trying to hit companies upside the head with the cluebat. They retreat back to the organic alternatives, because, well, they just aren't getting paid enough for that....stuff. My take on this is that ushering companies into the open source development model is a hard but extremely worthwhile problem to solve. This is why I took this job. I'm not going to argue that I've done the best job at this (in fact, I know I've made several textbook errors), or that Linden Lab has been without fault. However, I think that throwing the doors open on all aspects of a project and working in a highly disruptive way to existing development process is not smart to recommend across the board. For a company that's on its last legs and is failing by every objective measure, sure, but not for a company that is still very healthy. I say this as someone who really, really wants Linden Lab to adopt many more development practices of "organic" open source, and trust me, I'm working very hard to demonstrate the value of this approach to my peers and to make the argument that we need to get more aggressive. But at the end of the day, we are bound by hard business realities, which means that we can't pursue every single opportunity and fix every problem simultaneously. As imperfect as our open source efforts are, we've got a lot of other big opportunities to pursue and big problems to fix, and the opportunities/solutions related to our open source initiative aren't always going to make it above the cut line for every planning cycle. I don't think we're in a unique situation here. It's really difficult when you have to untangle processes and habits that have formed over years. Regardless of whether or not those are the best practices, they are the current practices, and the difficulty of process change is often underestimated by those with the best of intentions. Compound that with the fact that the open source culture is a very email-centric (or at least "text-centric") culture, and how well that works for actually gaging goodwill [3], and you have a situation where too many people probably draw their cluebats too soon. Back on the topic at hand. I forwarded Mike's mail to our internal all-dev list (with a glib "yeah, what's up with that...." added in) and got the conversation rolling again. There's a lot of hard problems to solve in our public JIRA instance work for more than we're using it for today, and those are being surfaced again in our internal dust cloud, but we're not ignoring your feedback. For those of you who would just as soon we have that debate out here, sorry, some of the arguments are going to be for internal consumption only....it's just the nature of the beast. I share your frustration that we're not yet better at keeping our public tracker up-to-date, and agree that the ultimate solution is to start using PJIRA sooner than later, but the better arguments against aggressive action (mainly centered around picking our battles) are arguments I'm not going to be at liberty to ignore, but I'll be pushing to make the case as best I can. That work? Rob Links: [1] Theodore Ts'o: Organic vs. Non-organic Open Source http://thunk.org/tytso/blog/2008/04/24/organic-vs-non-organic-open-source/ [2] OSCON Panel: "Does Open Source Need to Be "Organic"?" http://en.oreilly.com/oscon2008/public/schedule/detail/4400 [3] xkcd: "Internet Argument" http://xkcd.com/438/ From monkowsk at watson.ibm.com Fri Jul 11 15:15:08 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jul 11 15:15:14 2008 Subject: [sldev] Re: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4877C40F.2050901@lindenlab.com> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> Message-ID: <4877DB6B.4080105@watson.ibm.com> Rob, thanks for forwarding my question to the internal list. I wasn't asking out of frustration; I was asking out of curiosity. It seems like you're missing out on a major benefit of being open source, and I can't guess what the reason might be. You don't have to go full PJIRA all at once. Read-only IJIRA would be a big step forward, though (and there'd be a lot of people keeping PJIRA up to date then). My curiosity was sparked by a project within my company that I am participating in as an "outside user" even though I work for the same company. They call it a "community driven commercial development" project. See http://www.projectzero.org/about/zerofaq.php The source is available and the bug tracker is visible, and they accept suggestions, but they do not accept code contributions, so it's not really an open source project, but they do make it easy for people to fix bugs. I'm not suggesting Linden Lab adopt the same model; I'm just wondering why Linden doesn't make the bug fixing more transparent. Mike Mm Alder Rob Lanphier wrote: > Back on the topic at hand. I forwarded Mike's mail to our internal > all-dev list (with a glib "yeah, what's up with that...." added in) and > got the conversation rolling again. There's a lot of hard problems to > solve in our public JIRA instance work for more than we're using it for > today, and those are being surfaced again in our internal dust cloud, > but we're not ignoring your feedback. For those of you who would just > as soon we have that debate out here, sorry, some of the arguments are > going to be for internal consumption only....it's just the nature of the > beast. I share your frustration that we're not yet better at keeping > our public tracker up-to-date, and agree that the ultimate solution is > to start using PJIRA sooner than later, but the better arguments against > aggressive action (mainly centered around picking our battles) are > arguments I'm not going to be at liberty to ignore, but I'll be pushing > to make the case as best I can. > > That work? From tofu.linden at lindenlab.com Fri Jul 11 15:49:51 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Fri Jul 11 15:49:47 2008 Subject: [sldev] Re: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4877DB6B.4080105@watson.ibm.com> References: <487779A4.2070309@watson.ibm.com><4877C40F.2050901@lindenlab.com> <4877DB6B.4080105@watson.ibm.com> Message-ID: <4877E38F.7000106@lindenlab.com> Mike Monkowski wrote: > You don't have to go full > PJIRA all at once. Read-only IJIRA would be a big step forward, though I totally sympathise - we've been discussing the ramifications of an integrated Jira since before the initial open-source release. There's general agreement that an integrated Jira is desirable as a goal, BUT for reasons Rob described - and more - this hasn't happened yet and won't take the form of automatically throwing our old issues public as a rule. We use our internal Jira for way, way more than technical bug-tracking, plus I'm sure you understand that historical attached data and comments written against issues for the context of internal consumption can easily contain sensitive information concerning residents (i.e. contact information, etc) which was never intended to leave Linden Lab. -tofu From robla at lindenlab.com Fri Jul 11 16:56:11 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jul 11 16:56:24 2008 Subject: [sldev] Re: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4877DB6B.4080105@watson.ibm.com> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4877DB6B.4080105@watson.ibm.com> Message-ID: <4877F31B.1010404@lindenlab.com> On 7/11/08 3:15 PM, Mike Monkowski wrote: > Rob, thanks for forwarding my question to the internal list. > > I wasn't asking out of frustration; I was asking out of curiosity. It > seems like you're missing out on a major benefit of being open source, > and I can't guess what the reason might be. You don't have to go full > PJIRA all at once. Read-only IJIRA would be a big step forward, > though (and there'd be a lot of people keeping PJIRA up to date then). Agreed. It's both a big step forward, and really tough to figure out how to do correctly. We have a lot of internal systems that are wired together for our internal toolchain that are tough to untangle. For example, we're doing our reviews today, for which we have a tool which automatically pull statistics from our internal JIRA instance. We've grown dependent on accessing the internals of that database. For reasons that are long and complicated, we can't use the same mechanism for pulling from PJIRA. That's just one example that I'm thinking of. There are lots of others. We intend to get PJIRA integrated into the overall system, but LLJIRA is more tangled into our internal workflow than you might think, and we really can't move the whole mess to one publicly accessible system. > My curiosity was sparked by a project within my company that I am > participating in as an "outside user" even though I work for the same > company. They call it a "community driven commercial development" > project. See http://www.projectzero.org/about/zerofaq.php The source > is available and the bug tracker is visible, and they accept > suggestions, but they do not accept code contributions, so it's not > really an open source project, but they do make it easy for people to > fix bugs. That's very cool. IBM has a pretty sophisticated approach to open source and hybrid models. > I'm not suggesting Linden Lab adopt the same model; I'm just wondering > why Linden doesn't make the bug fixing more transparent. Working on it. Speaking of those reviews, I'm doing my quarterly review right now, and one of the things I'm kicking myself for not getting done was an LLJIRA->PJIRA exporter. (And I'm probably going to abandon it myself in hopes that another group can take it on). The naive approach on something like that is to take the importer and reverse it. The problem is that our importer takes a "suck it in and fix it up" approach to importing, whereas an exporter should probably have a "preview" before going live. None of this is rocket science, but it all takes time, just like writing this email takes time. ;-) Rob From grant at lindenlab.com Fri Jul 11 16:46:37 2008 From: grant at lindenlab.com (Grant Linden) Date: Fri Jul 11 17:11:46 2008 Subject: [sldev] RX Office hours - Jacek Antonelli will be presenting their interface design Message-ID: <907af5560807111646w58dac643r6c2b948f34f0d147@mail.gmail.com> A the next Rx Office Hours Jacek Antonelli will be presenting their entry to Dusan's interface contest. http://dusanwriter.com/?p=603 This is our opportunity for discussion, feedback, and critique. The design document is available online: http://docs.google.com/Doc?id=dgv2jprg_15ffm68rhr Thursday July 17th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080711/8a92ca9a/attachment-0001.htm From darien.caldwell at gmail.com Fri Jul 11 17:56:55 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri Jul 11 17:56:57 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <4877B3FD.5090400@cox.net> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> Message-ID: <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> Looking at the original Wiki link, I see there are examples of Relief Mapping, Sphere Tracing, and Pyramidal Mapping. However looking closely, I can't see any visual differences. What is the main difference between the 3 styles of mapping? On 7/11/08, Lawson English wrote: > Karl Stiefvater wrote: >>> Again, I may be missing something - but this is how I originally >>> expected sculpts to work when they were initially described. >> >> heh... i think maybe you have too high of expectations. :) >> >> this technology is still EXTREMELY young and experimental. remember >> that when pixar puts this level of detail in a movie - each shot takes >> days of rendering time. in a realtime engine - these things have >> never before been possible. >> >> but you do raise an interesting idea: perhaps the best way to quickly >> integrate mesostructure technology into our system is via the sculpt >> map - the artist provides a high resolution sculpt map - which still >> creates the standard low resolution mesh - but the details are >> fleshed-out via mesostructures..... >> >> very interesting... > > Of course, sculpt maps only have one collion model right now, anyway. > Torus? Sphere? Can't remember. > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From matthew.dowd at hotmail.co.uk Sat Jul 12 02:52:36 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 12 02:52:39 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4877C40F.2050901@lindenlab.com> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> Message-ID: > My take on this is that ushering companies into the open source > development model is a hard but extremely worthwhile problem to solve. Don't get me wrong - I realise it is hard, particularly if you have an existing produce to maintain and develop (its like trying to change the engine of a car whilst still driving it etc.). I do feel, however, that in recent months we have seem some subtle but significant movement forward (the number of Lindens posting to this list, internal roadmaps being revealed prior to shipping code, possible due to cmake more frequent syncs from the internal svn to the public one, publication of some experimental internal code branches such as puppetteering and shadows, etc.). Indeed Rob's post is itself a significant step: I think we had a similar discussion around a year ago, and the LL response concentrated on how far they had come etc. My frustration at the time was a concern that they were underestimating how difficult the process is, and how far they still had to go. An open admission that there is still a lot of work to do, is, IMHO, a major step forward! (and that doesn't belittle the progress already made). The easiest (but by no means guaranteed, and still not easy) way to move is to just stop development for a month or three whilst you completely overhaul your entire development platforms, but few projects have that luxury. However, there was talk once of a SL version 2.0, but I think that was shelved in favour of just evolving the existing code? Let's face it, however, building transparent, fully maintainable code in large projects is hard; even if you follow the textbook there comes a point in most projects when the code has been re-architected/re-factored so many times that it needs a clean rewrite, and in reality most projects have some textbook "no-nos" in there somewhere - SL is certainly not an exception to that! So a possible scenario would be for LL to start development of SL 2.0 from scratch as a completely open source project whilst maintaining the existing SL 1.0 code until the new version is ready for production. You already have part of the community for that work in the AWG community (and possibly even the OpenSim community - although there are issues re incompatible licenses there). I'm not saying that this is necessarily a model that LL *must* adopt, but one I think LL should seriously think about. Matthew _________________________________________________________________ The John Lewis Clearance - save up to 50% with FREE delivery http://clk.atdmt.com/UKM/go/101719806/direct/01/ From nik at terminaldischarge.net Sat Jul 12 03:10:11 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Sat Jul 12 03:10:44 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> Message-ID: <48788303.3090804@terminaldischarge.net> Darien Caldwell wrote: > Looking at the original Wiki link, I see there are examples of Relief > Mapping, Sphere Tracing, and Pyramidal Mapping. However looking > closely, I can't see any visual differences. What is the main > difference between the 3 styles of mapping? > If you lok closely, the relief mapping is missing a bit of the top of the pyramid like shape. Sphere mapping has got it perfect however. I didn't really look closely at the Pyramidal Mapping. > On 7/11/08, Lawson English wrote: > >> Karl Stiefvater wrote: >> >>>> Again, I may be missing something - but this is how I originally >>>> expected sculpts to work when they were initially described. >>>> >>> heh... i think maybe you have too high of expectations. :) >>> >>> this technology is still EXTREMELY young and experimental. remember >>> that when pixar puts this level of detail in a movie - each shot takes >>> days of rendering time. in a realtime engine - these things have >>> never before been possible. >>> >>> but you do raise an interesting idea: perhaps the best way to quickly >>> integrate mesostructure technology into our system is via the sculpt >>> map - the artist provides a high resolution sculpt map - which still >>> creates the standard low resolution mesh - but the details are >>> fleshed-out via mesostructures..... >>> >>> very interesting... >>> >> Of course, sculpt maps only have one collion model right now, anyway. >> Torus? Sphere? Can't remember. >> >> Lawson >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080712/2ed9936b/attachment.htm From ravish.mehra07 at gmail.com Sat Jul 12 03:32:52 2008 From: ravish.mehra07 at gmail.com (Ravish Mehra) Date: Sat Jul 12 03:32:58 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> Message-ID: <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: 800px-Sphere_tracing2.jpg Type: image/jpeg Size: 46474 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080712/e46c4e1e/800px-Sphere_tracing2-0001.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: 800px-Relief_mapping_3.jpg Type: image/jpeg Size: 49649 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080712/e46c4e1e/800px-Relief_mapping_3-0001.jpg From ravish.mehra07 at gmail.com Sat Jul 12 03:42:11 2008 From: ravish.mehra07 at gmail.com (Ravish Mehra) Date: Sat Jul 12 03:42:15 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> Message-ID: <63139d800807120342h24703c67qf1ceb1ec88e375e8@mail.gmail.com> i think only my images got through the sldev list. hence mailing the message again. hello guys, my name is Ravish and i am currently implementing this mesostructure rendering library under google summer of code. i know i write long answers :) , so bear with me. regarding the visual difference between the three techniques - 1) sphere tracing uses a 3D texture known as distance map for finding the ray-mesostructure intersection and the quality achieved by this technique is highly dependent on the resolution of this distance map. currently its 128x128x32. since its a 3D texture we cannot go to very high resolutions. hence the images will be at that resolution and certain aliasing effects are visible. i have marked such areas in attached image with yellow circles. 2) Relief mapping's rendering quality on the other hand, depends more on the number of iterations we do ( linear + binary steps ). if we do enough iterations, it gives amazing results. as can be seen that the aliasing effects present in sphere tracing are not present in relief mapping ( height field ). but if we do less number of iterations, we may get certain artifacts due to incorrect intersections(see attached figure of relief mapping). also since it uses a 2D texture we can go to very high resolutions. 3) Pyramidal displacement mapping also tries to give the same quality as relief mapping, but it doesnot require as large number of iterations as relief mapping. here also we can go to very high resolutions as we are using 2D textures. even the performance(fps) given by the 3 techiques is hugely different. i will soon upload a comparison table for comparing their performances. ravish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080712/4fdfe69d/attachment.htm From suzyq at pobox.com Sat Jul 12 06:38:03 2008 From: suzyq at pobox.com (Suzy Deffeyes) Date: Sat Jul 12 06:38:06 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> Message-ID: <2bd5b7f10807120638v39a3f5b3n62aeea1216285f85@mail.gmail.com> Hi Ravish, Thanks for the explanation. This is exciting stuff. Some questions: 1. I wanted to confirm, "3D texture" to me means volumetric texturing using texture slices. Is that what you are using in your sphere tracing? If so I can certainly understand the need to stay at lower resolutions... :). Volume texturing chows on texture memory (and in SL's case network bandwidth) like there is no tomorrow. 2. The mesostructures wiki page says it is creating a C++ library to do these techniques. Wouldn't these be implemented instead as GLSL shaders? I'd also be curious if any of your maps are made up of floating point values. Again, great stuff, I look forward to seeing your work as it progresses. Suzy Deffeyes/Pixel Gausman On Sat, Jul 12, 2008 at 5:32 AM, Ravish Mehra wrote: > hello guys, > my name is Ravish and i am currently implementing this mesostructure > rendering library under google summer of code. > > i know i write long answers :) , so bear with me. regarding the visual > difference between the three techniques - > 1) sphere tracing uses a 3D texture known as distance map for finding the > ray-mesostructure intersection and the quality achieved by this technique is > highly dependent on the resolution of this distance map. currently its > 128x128x32. since its a 3D texture we cannot go to very high resolutions. > hence the images will be at that resolution and certain aliasing effects are > visible. i have marked such areas in attached image with yellow circles. > > 2) Relief mapping's rendering quality on the other hand, depends more on > the number of iterations we do ( linear + binary steps ). if we do enough > iterations, it gives amazing results. as can be seen that the aliasing > effects present in sphere tracing are not present in relief mapping ( height > field ). but if we do less number of iterations, we may get certain > artifacts due to incorrect intersections(see attached figure of relief > mapping). also since it uses a 2D texture we can go to very high > resolutions. > > 3) Pyramidal displacement mapping also tries to give the same quality as > relief mapping, but it doesnot require as large number of iterations as > relief mapping. here also we can go to very high resolutions as we are using > 2D textures. > > even the performance(fps) given by the 3 techiques is hugely different. i > will soon upload a comparison table for comparing their performances. > > ravish > > > > On Sat, Jul 12, 2008 at 6:26 AM, Darien Caldwell < > darien.caldwell@gmail.com> wrote: > >> Looking at the original Wiki link, I see there are examples of Relief >> Mapping, Sphere Tracing, and Pyramidal Mapping. However looking >> closely, I can't see any visual differences. What is the main >> difference between the 3 styles of mapping? >> >> On 7/11/08, Lawson English wrote: >> > Karl Stiefvater wrote: >> >>> Again, I may be missing something - but this is how I originally >> >>> expected sculpts to work when they were initially described. >> >> >> >> heh... i think maybe you have too high of expectations. :) >> >> >> >> this technology is still EXTREMELY young and experimental. remember >> >> that when pixar puts this level of detail in a movie - each shot takes >> >> days of rendering time. in a realtime engine - these things have >> >> never before been possible. >> >> >> >> but you do raise an interesting idea: perhaps the best way to quickly >> >> integrate mesostructure technology into our system is via the sculpt >> >> map - the artist provides a high resolution sculpt map - which still >> >> creates the standard low resolution mesh - but the details are >> >> fleshed-out via mesostructures..... >> >> >> >> very interesting... >> > >> > Of course, sculpt maps only have one collion model right now, anyway. >> > Torus? Sphere? Can't remember. >> > >> > Lawson >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080712/67f31a05/attachment.htm From lenglish5 at cox.net Sat Jul 12 09:07:42 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 12 09:07:44 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> Message-ID: <4878D6CE.6000107@cox.net> Matthew Dowd wrote: > [...] > > So a possible scenario would be for LL to start development of SL 2.0 from scratch as a completely open source project whilst maintaining the existing SL 1.0 code until the new version is ready for production. You already have part of the community for that work in the AWG community (and possibly even the OpenSim community - although there are issues re incompatible licenses there). I'm not saying that this is necessarily a model that LL *must* adopt, but one I think LL should seriously think about. > Yo, what do you think the OGP is? While its going slower than anyone would like, the protocols to be used in OGP consist of entirely new protocols designed to work equally well with legacy code and whatever new protocols get incrementally added in plus the legacy protocols that haven't been addressed yet. One important reason for doing it incrementally is that certain parts of the OGP should, without major tweaking to the existing code, give a [hopefully] huge boost to stability and concurrency for the system. Another reason, of course, is that Linden Lab doesn't have the resources to do two separate projects (if you want fully separate projects I refer you to OpenSim and realXtend, both of which are BSD-licensed). Anyone who is unhappy with the speed at which the OGP is being developed, should join the Pyogp project (Apache v2 licensed). The faster we get a robust test harness designed and implemented, the faster the work on OGP will proceed. A side benefit will be the light-weight client that everyone is asking for since part of the design of Pyogp will be to keep legacy protocols available for regressions testing and simply to make the harness fully functional while the OGP is in such an early stage. We've committed to having daily (or almost) meetings for a while to get the ball rolling. The first should start this Monday at 9:30 AM SLT. Check the IRC for the meeting place and any particulars. Our first office hours with Enus Linden should be at 1 PM SLT this coming Friday. IRC: irc://irc.freenode.com/#pyogp Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp wiki: http://wiki.secondlife.com/wiki/Pyogp Lawson From lenglish5 at cox.net Sat Jul 12 09:35:21 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 12 09:35:23 2008 Subject: [sldev] [AWG][Pyogp] Daily Pyogp meetings Message-ID: <4878DD49.9010600@cox.net> In World Meetings We're going to start having daily meetings at "infinity is full of stars" in Levenhall at 9:30AM SLT each day. These meetings are for the PyOGP coders to meet and discuss design, process and status. In the near term, these are likely to be "somewhat beefy" meetings where design issues are discussed and differences hammered out. In the longer term, these will hopefully be more "Agile Stand-Up" style meetings where we discuss: a. what we've done in the last 24 hours, b. what we're going to do in the next 24 and c. what we're blocked on. what PyOGP Coders Meeting who PyOGP l33t C0d3rZ where "infinity is full of stars" @ http://slurl.com/secondlife/Levenhall/91/208/22 when 9:30AM SLT / 12:30PM Eastern Time / 5:30PM GMT / 6:30PM Central European Time why for PyOGP contributors to hash out architecture, design, test and deploy issues IRC: irc://irc.freenode.com/#pyogp Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp wiki: http://wiki.secondlife.com/wiki/Pyogp Lawson From ravish.mehra07 at gmail.com Sat Jul 12 12:54:16 2008 From: ravish.mehra07 at gmail.com (Ravish Mehra) Date: Sat Jul 12 12:54:20 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <2bd5b7f10807120638v39a3f5b3n62aeea1216285f85@mail.gmail.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> <2bd5b7f10807120638v39a3f5b3n62aeea1216285f85@mail.gmail.com> Message-ID: <63139d800807121254q7cf00edfxfaa0870386f0afd7@mail.gmail.com> hi Suzy, 1) actually I am not using the 3D texture for doing any kind of volumetric texture mapping ( texture slices ). it just stores the distance map( which is actually a data structure - kind of a 3D grid which stores at each location, the distance to the nearest point on the surface). this distance map is accessed at each step of sphere tracing to determine the next point to go to. 2) the central library - functions for creating the data structures used by these various techniques and for binding the shaders will be in C++. the vertex and fragment shaders will be in glsl. the purpose is to provide a complete support for doing per-pixel displacement mapping. at present, none of my texture maps( 2D or 3D ) are floating points as 8 bit accuracy is enough for now. but i have certainly worked with floating point textures and it has some advantages in certain cases. thanks for you interest. best ravish On Sat, Jul 12, 2008 at 7:08 PM, Suzy Deffeyes wrote: > > Hi Ravish, > > Thanks for the explanation. This is exciting stuff. Some questions: > > 1. I wanted to confirm, "3D texture" to me means volumetric texturing using > texture slices. Is that what you are using in your sphere tracing? If so I > can certainly understand the need to stay at lower resolutions... :). Volume > texturing chows on texture memory (and in SL's case network bandwidth) like > there is no tomorrow. > > 2. The mesostructures wiki page says it is creating a C++ library to do > these techniques. Wouldn't these be implemented instead as GLSL shaders? > I'd also be curious if any of your maps are made up of floating point > values. > > Again, great stuff, I look forward to seeing your work as it progresses. > Suzy Deffeyes/Pixel Gausman > > > On Sat, Jul 12, 2008 at 5:32 AM, Ravish Mehra > wrote: > >> hello guys, >> my name is Ravish and i am currently implementing this mesostructure >> rendering library under google summer of code. >> >> i know i write long answers :) , so bear with me. regarding the visual >> difference between the three techniques - >> 1) sphere tracing uses a 3D texture known as distance map for finding the >> ray-mesostructure intersection and the quality achieved by this technique is >> highly dependent on the resolution of this distance map. currently its >> 128x128x32. since its a 3D texture we cannot go to very high resolutions. >> hence the images will be at that resolution and certain aliasing effects are >> visible. i have marked such areas in attached image with yellow circles. >> >> 2) Relief mapping's rendering quality on the other hand, depends more on >> the number of iterations we do ( linear + binary steps ). if we do enough >> iterations, it gives amazing results. as can be seen that the aliasing >> effects present in sphere tracing are not present in relief mapping ( height >> field ). but if we do less number of iterations, we may get certain >> artifacts due to incorrect intersections(see attached figure of relief >> mapping). also since it uses a 2D texture we can go to very high >> resolutions. >> >> 3) Pyramidal displacement mapping also tries to give the same quality as >> relief mapping, but it doesnot require as large number of iterations as >> relief mapping. here also we can go to very high resolutions as we are using >> 2D textures. >> >> even the performance(fps) given by the 3 techiques is hugely different. i >> will soon upload a comparison table for comparing their performances. >> >> ravish >> >> >> >> On Sat, Jul 12, 2008 at 6:26 AM, Darien Caldwell < >> darien.caldwell@gmail.com> wrote: >> >>> Looking at the original Wiki link, I see there are examples of Relief >>> Mapping, Sphere Tracing, and Pyramidal Mapping. However looking >>> closely, I can't see any visual differences. What is the main >>> difference between the 3 styles of mapping? >>> >>> On 7/11/08, Lawson English wrote: >>> > Karl Stiefvater wrote: >>> >>> Again, I may be missing something - but this is how I originally >>> >>> expected sculpts to work when they were initially described. >>> >> >>> >> heh... i think maybe you have too high of expectations. :) >>> >> >>> >> this technology is still EXTREMELY young and experimental. remember >>> >> that when pixar puts this level of detail in a movie - each shot takes >>> >> days of rendering time. in a realtime engine - these things have >>> >> never before been possible. >>> >> >>> >> but you do raise an interesting idea: perhaps the best way to quickly >>> >> integrate mesostructure technology into our system is via the sculpt >>> >> map - the artist provides a high resolution sculpt map - which still >>> >> creates the standard low resolution mesh - but the details are >>> >> fleshed-out via mesostructures..... >>> >> >>> >> very interesting... >>> > >>> > Of course, sculpt maps only have one collion model right now, anyway. >>> > Torus? Sphere? Can't remember. >>> > >>> > Lawson >>> > _______________________________________________ >>> > Policies and (un)subscribe information available here: >>> > http://wiki.secondlife.com/wiki/SLDev >>> > Please read the policies before posting to keep unmoderated posting >>> > privileges >>> > >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080713/31dbd8e6/attachment.htm From matthew.dowd at hotmail.co.uk Sat Jul 12 14:13:05 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 12 14:13:06 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4878D6CE.6000107@cox.net> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> Message-ID: > Yo, what do you think the OGP is? Well to be honest I'm not sure ;-) A question I posed in the very early days of AWG, and to which there didn't seem to be a definitive answer (it rather depended who you ask) was whether it was about a set of protocols to allow multiple virtual worlds to interoperate or about developing a new architecture for a SecondLife 2.0 The same applies to OGP - it seems very much focused on the protocols between VW viewer and server, and possible also betwen VW servers. There is nothing in OGP as far as I can tell about re-engineering the SL server or client architectures from scratch, and I could very well see a scenario where LL adds OGP support on top of the existing codebase or even just develop a protocol bridge between OGP and the current SL protocols. So, my question to you - is OGP about developing some interoperable open protocols for VW grids and adding those protocol to the SL 1.0 codebase or is it about developing a new SL 2.0 from scratch viewing SL 1.0 as a prototype generating a wealth of knowledge and experience? Matthew _________________________________________________________________ Find the best and worst places on the planet http://clk.atdmt.com/UKM/go/101719807/direct/01/ From lenglish5 at cox.net Sat Jul 12 16:53:40 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 12 16:53:42 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> Message-ID: <48794404.7020602@cox.net> Matthew Dowd wrote: > >> Yo, what do you think the OGP is? >> > > Well to be honest I'm not sure ;-) > > A question I posed in the very early days of AWG, and to which there didn't seem to be a definitive answer (it rather depended who you ask) was whether it was about a set of protocols to allow multiple virtual worlds to interoperate or about developing a new architecture for a SecondLife 2.0 > > The same applies to OGP - it seems very much focused on the protocols between VW viewer and server, and possible also betwen VW servers. There is nothing in OGP as far as I can tell about re-engineering the SL server or client architectures from scratch, and I could very well see a scenario where LL adds OGP support on top of the existing codebase or even just develop a protocol bridge between OGP and the current SL protocols. > > So, my question to you - is OGP about developing some interoperable open protocols for VW grids and adding those protocol to the SL 1.0 codebase or is it about developing a new SL 2.0 from scratch viewing SL 1.0 as a prototype generating a wealth of knowledge and experience? > well, yes. ;-) Seriously, its a set of protocols (very limited at the moment) to facilitate grid interop, and it eventually will become the basis for a [more or less] complete redesign of the server architecture (I suspect) and even further off, the client (I hope). Lawson From edward.artaud at gmail.com Sat Jul 12 18:22:42 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sat Jul 12 18:22:46 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <48794404.7020602@cox.net> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> <48794404.7020602@cox.net> Message-ID: On Sat, Jul 12, 2008 at 4:53 PM, Lawson English wrote: > Seriously, its a set of protocols (very limited at the moment) to > facilitate grid interop, and it eventually will become the basis for a [more > or less] complete redesign of the server architecture (I suspect) and even > further off, the client (I hope). That was my concern when I was posting about the need for a plug-in architecture. Is it likely that OGP will yield anything useful for the client until this time next year? Most of the actual coding will go into PyOGP, so by the end of the year, it'll be roughly equivalent in terms of functionality to where libsl (openmv) is today, but using the cleaner protocol and in Python rather than C#. At that point, I suppose it'll need to be ported to C++ and somehow bolted onto the SL viewer, which will take another 6 months, and then we'll be roughly where we are today, but with a new underlying protocol layer. At that point, we'll be able to start refactoring the viewer architecture. I hope I'm wrong and it takes half that time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080712/a351f504/attachment.htm From lenglish5 at cox.net Sat Jul 12 18:25:54 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 12 18:25:57 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <48794404.7020602@cox.net> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> <48794404.7020602@cox.net> Message-ID: <487959A2.7020509@cox.net> Lawson English wrote: > Matthew Dowd wrote: >> [...] >> So, my question to you - is OGP about developing some interoperable >> open protocols for VW grids and adding those protocol to the SL 1.0 >> codebase or is it about developing a new SL 2.0 from scratch viewing >> SL 1.0 as a prototype generating a wealth of knowledge and experience? >> > > well, yes. > > ;-) > > Seriously, its a set of protocols (very limited at the moment) to > facilitate grid interop, and it eventually will become the basis for a > [more or less] complete redesign of the server architecture (I > suspect) and even further off, the client (I hope). > I should say that the most radical change in the server architecture redesign (as far as I know), happens with the first protocol that has been implemented (login). The fact that 99% of the old architecture remains intact behind the scenes is just an implementation detail. Splitting the architecture into Region Domains and Agent Domains is (IMHO) the biggie in the long run, and it happened very first thing. Lawson From lenglish5 at cox.net Sat Jul 12 19:13:00 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 12 19:13:03 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> <48794404.7020602@cox.net> Message-ID: <487964AC.9030104@cox.net> Edward Artaud wrote: > > On Sat, Jul 12, 2008 at 4:53 PM, Lawson English > wrote: > > Seriously, its a set of protocols (very limited at the moment) to > facilitate grid interop, and it eventually will become the basis > for a [more or less] complete redesign of the server architecture > (I suspect) and even further off, the client (I hope). > > > > That was my concern when I was posting about the need for a plug-in > architecture. Is it likely that OGP will yield anything useful for > the client until this time next year? Most of the actual coding will > go into PyOGP, so by the end of the year, it'll be roughly equivalent > in terms of functionality to where libsl (openmv) is today, but using > the cleaner protocol and in Python rather than C#. At that point, I > suppose it'll need to be ported to C++ and somehow bolted onto the SL > viewer, which will take another 6 months, and then we'll be roughly > where we are today, but with a new underlying protocol layer. At that > point, we'll be able to start refactoring the viewer architecture. I > hope I'm wrong and it takes half that time. > ------------------------------------------------------------------------ Actually, right now, the login + TP is only implemented in a modded C++ viewer, so your fears, while not groundless, aren't substantiated either... ;-) Seriously, this is all very new, and Pyogp isn't even having its first meeting til Monday. I personally am sorta hopeful we can have a version of Pyogp ready by the time the Open Grid Public Beta starts in 2 weeks, but I think everyone else considers that wishful thinking. I believe the viewer roadmap doesn't even take OGP into account. Not sure where this leaves a plugin architecture, but you can talk to the guys working on refactoring various aspects of the viewer. http://wiki.secondlife.com/wiki/Viewer_Roadmap L From darien.caldwell at gmail.com Sat Jul 12 19:29:43 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sat Jul 12 19:29:47 2008 Subject: [sldev] GSoC - mesostructures In-Reply-To: <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> References: <0FCF688F-5232-4E39-B41A-EC1721BACDA4@lindenlab.com> <48769317.8090406@cox.net> <4877B3FD.5090400@cox.net> <835a5b860807111756x4dd4869en1074aebb1b163852@mail.gmail.com> <63139d800807120332o3e71c95dq5b5453ef2f3cc454@mail.gmail.com> Message-ID: <835a5b860807121929o1dc71eb4n88362261216aa824@mail.gmail.com> Ah, now that you point it out, the differences are quite plain. Always good to have a trained eye. Thanks for the details, and very nice work. :) On 7/12/08, Ravish Mehra wrote: > hello guys, > my name is Ravish and i am currently implementing this mesostructure > rendering library under google summer of code. > > i know i write long answers :) , so bear with me. regarding the visual > difference between the three techniques - > 1) sphere tracing uses a 3D texture known as distance map for finding the > ray-mesostructure intersection and the quality achieved by this technique is > highly dependent on the resolution of this distance map. currently its > 128x128x32. since its a 3D texture we cannot go to very high resolutions. > hence the images will be at that resolution and certain aliasing effects are > visible. i have marked such areas in attached image with yellow circles. > > 2) Relief mapping's rendering quality on the other hand, depends more on the > number of iterations we do ( linear + binary steps ). if we do enough > iterations, it gives amazing results. as can be seen that the aliasing > effects present in sphere tracing are not present in relief mapping ( height > field ). but if we do less number of iterations, we may get certain > artifacts due to incorrect intersections(see attached figure of relief > mapping). also since it uses a 2D texture we can go to very high > resolutions. > > 3) Pyramidal displacement mapping also tries to give the same quality as > relief mapping, but it doesnot require as large number of iterations as > relief mapping. here also we can go to very high resolutions as we are using > 2D textures. > > even the performance(fps) given by the 3 techiques is hugely different. i > will soon upload a comparison table for comparing their performances. > > ravish > > > On Sat, Jul 12, 2008 at 6:26 AM, Darien Caldwell > wrote: > >> Looking at the original Wiki link, I see there are examples of Relief >> Mapping, Sphere Tracing, and Pyramidal Mapping. However looking >> closely, I can't see any visual differences. What is the main >> difference between the 3 styles of mapping? >> >> On 7/11/08, Lawson English wrote: >> > Karl Stiefvater wrote: >> >>> Again, I may be missing something - but this is how I originally >> >>> expected sculpts to work when they were initially described. >> >> >> >> heh... i think maybe you have too high of expectations. :) >> >> >> >> this technology is still EXTREMELY young and experimental. remember >> >> that when pixar puts this level of detail in a movie - each shot takes >> >> days of rendering time. in a realtime engine - these things have >> >> never before been possible. >> >> >> >> but you do raise an interesting idea: perhaps the best way to quickly >> >> integrate mesostructure technology into our system is via the sculpt >> >> map - the artist provides a high resolution sculpt map - which still >> >> creates the standard low resolution mesh - but the details are >> >> fleshed-out via mesostructures..... >> >> >> >> very interesting... >> > >> > Of course, sculpt maps only have one collion model right now, anyway. >> > Torus? Sphere? Can't remember. >> > >> > Lawson >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> > From blindwanderer at gmail.com Sun Jul 13 08:19:43 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sun Jul 13 08:19:49 2008 Subject: [sldev] New Sculpty Features Message-ID: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> Hey I just saw the featurettes-5 check in on the public SVN, http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F I was wondering, could we get an LSL example for PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is but I want to make sure. llSetPrimitiveParams([ PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | PRIM_SCULPT_FLAG_MIRROR ]) llSetPrimitiveParams([ PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT ]) llSetPrimitiveParams([ PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR ]) From qarl at lindenlab.com Sun Jul 13 11:21:49 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Sun Jul 13 11:21:51 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> Message-ID: <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> exactly so, Strife - the new flags are ORed (or added, i s'pose) the the existing type field. MIRROR mirrors along the x-axis, while INVERT flips the direction of the surface (normals). K. On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: > Hey I just saw the featurettes-5 check in on the public SVN, > http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F > I was wondering, could we get an LSL example for > PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & > PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is but I > want to make sure. > > llSetPrimitiveParams([ > PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", > PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | > PRIM_SCULPT_FLAG_MIRROR > ]) > > llSetPrimitiveParams([ > PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", > PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT > ]) > > llSetPrimitiveParams([ > PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", > PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR > ]) From soft at lindenlab.com Sun Jul 13 11:50:12 2008 From: soft at lindenlab.com (Soft) Date: Sun Jul 13 11:50:14 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> Message-ID: Do scripters need to wait for some minimal viewer version to be required before assuming they can use this and have everyone see the same result? On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater wrote: > exactly so, Strife - the new flags are ORed (or added, i s'pose) the the > existing type field. > > MIRROR mirrors along the x-axis, while INVERT flips the direction of the > surface (normals). > > > K. > > On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: > >> Hey I just saw the featurettes-5 check in on the public SVN, >> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >> I was wondering, could we get an LSL example for >> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >> PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is but I >> want to make sure. >> >> llSetPrimitiveParams([ >> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | >> PRIM_SCULPT_FLAG_MIRROR >> ]) >> >> llSetPrimitiveParams([ >> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT >> ]) >> >> llSetPrimitiveParams([ >> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR >> ]) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From jacek.antonelli at gmail.com Sun Jul 13 11:56:21 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sun Jul 13 11:56:23 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> Message-ID: <105c09f0807131156p9418ca2j605f9c2622ab3188@mail.gmail.com> On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater wrote: > > MIRROR mirrors along the x-axis, while INVERT flips the direction of the > surface (normals). Wow, good stuff! Those should prove really handy. *dances* Cheers! - Jacek From blindwanderer at gmail.com Sun Jul 13 12:45:41 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sun Jul 13 12:45:45 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> Message-ID: <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> The way things appear in featurettes-5, until these changes hit an official release, using either PRIM_SCULPT_FLAG_INVERT or PRIM_SCULPT_FLAG_MIRROR (or the associated checkboxes in the build tools) will result in the prims being rendered as PRIM_SCULPT_TYPE_PLANE On Sun, Jul 13, 2008 at 2:50 PM, Soft wrote: > Do scripters need to wait for some minimal viewer version to be > required before assuming they can use this and have everyone see the > same result? > > On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater wrote: >> exactly so, Strife - the new flags are ORed (or added, i s'pose) the the >> existing type field. >> >> MIRROR mirrors along the x-axis, while INVERT flips the direction of the >> surface (normals). >> >> >> K. >> >> On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: >> >>> Hey I just saw the featurettes-5 check in on the public SVN, >>> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >>> I was wondering, could we get an LSL example for >>> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >>> PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is but I >>> want to make sure. >>> >>> llSetPrimitiveParams([ >>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | >>> PRIM_SCULPT_FLAG_MIRROR >>> ]) >>> >>> llSetPrimitiveParams([ >>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT >>> ]) >>> >>> llSetPrimitiveParams([ >>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR >>> ]) >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From darien.caldwell at gmail.com Sun Jul 13 13:00:06 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sun Jul 13 13:00:11 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> Message-ID: <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> As long as work is being done of this nature, could we get flags to rotate maps too? For instance I have maps where I would flip it around so the Y coordinates of the map alter the Z coordiates of the prim, and vice versa (in this case the X coordiates would stay the same). Or is there some simple thing that would allow this that I'm missing? On 7/13/08, Strife Onizuka wrote: > The way things appear in featurettes-5, until these changes hit an > official release, using either PRIM_SCULPT_FLAG_INVERT or > PRIM_SCULPT_FLAG_MIRROR (or the associated checkboxes in the build > tools) will result in the prims being rendered as > PRIM_SCULPT_TYPE_PLANE > > On Sun, Jul 13, 2008 at 2:50 PM, Soft wrote: >> Do scripters need to wait for some minimal viewer version to be >> required before assuming they can use this and have everyone see the >> same result? >> >> On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater >> wrote: >>> exactly so, Strife - the new flags are ORed (or added, i s'pose) the the >>> existing type field. >>> >>> MIRROR mirrors along the x-axis, while INVERT flips the direction of the >>> surface (normals). >>> >>> >>> K. >>> >>> On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: >>> >>>> Hey I just saw the featurettes-5 check in on the public SVN, >>>> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >>>> I was wondering, could we get an LSL example for >>>> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >>>> PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is but I >>>> want to make sure. >>>> >>>> llSetPrimitiveParams([ >>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | >>>> PRIM_SCULPT_FLAG_MIRROR >>>> ]) >>>> >>>> llSetPrimitiveParams([ >>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT >>>> ]) >>>> >>>> llSetPrimitiveParams([ >>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR >>>> ]) >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From qarl at lindenlab.com Sun Jul 13 14:11:15 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Sun Jul 13 14:11:17 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> Message-ID: <809F71E7-0DC6-47A7-9B24-CDF5AE88AD37@lindenlab.com> as Strife mentioned - all this work is in the viewer. a scripter with an older viewer could use "128" in place of "PRIM_SCULPT_FLAG_MIRROR" if he wanted to - but he won't see the result until he gets the new viewer... K. On Jul 13, 2008, at 11:50 AM, Soft wrote: > Do scripters need to wait for some minimal viewer version to be > required before assuming they can use this and have everyone see the > same result? > > On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater > wrote: >> exactly so, Strife - the new flags are ORed (or added, i s'pose) >> the the >> existing type field. >> >> MIRROR mirrors along the x-axis, while INVERT flips the direction >> of the >> surface (normals). >> >> >> K. >> >> On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: >> >>> Hey I just saw the featurettes-5 check in on the public SVN, >>> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >>> I was wondering, could we get an LSL example for >>> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >>> PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is >>> but I >>> want to make sure. >>> >>> llSetPrimitiveParams([ >>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | >>> PRIM_SCULPT_FLAG_MIRROR >>> ]) >>> >>> llSetPrimitiveParams([ >>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT >>> ]) >>> >>> llSetPrimitiveParams([ >>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR >>> ]) >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> From qarl at lindenlab.com Sun Jul 13 14:16:45 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Sun Jul 13 14:16:48 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> Message-ID: it depends on what end-result you're trying to achieve. if you just want the prim to have the same visual appearance as if the y and z channels were swapped, you can achieve the same thing turning on MIRROR and rotating the prim 90 degrees. the reasoning for these two new flags is that they give a substantial advantage. MIRROR gives you (without the need of a second map) a symmetric shape (e.g. shoes.) INVERT will give you a backside to your planar sculpts. in both cases - the number of necessary sculpt maps is reduced. offhand, i don't see the advantage of swapping two channels. couldn't you just re-generate the sculpt map? K. On Jul 13, 2008, at 1:00 PM, Darien Caldwell wrote: > As long as work is being done of this nature, could we get flags to > rotate maps too? > > For instance I have maps where I would flip it around so the Y > coordinates of the map alter the Z coordiates of the prim, and vice > versa (in this case the X coordiates would stay the same). Or is there > some simple thing that would allow this that I'm missing? > > On 7/13/08, Strife Onizuka wrote: >> The way things appear in featurettes-5, until these changes hit an >> official release, using either PRIM_SCULPT_FLAG_INVERT or >> PRIM_SCULPT_FLAG_MIRROR (or the associated checkboxes in the build >> tools) will result in the prims being rendered as >> PRIM_SCULPT_TYPE_PLANE >> >> On Sun, Jul 13, 2008 at 2:50 PM, Soft wrote: >>> Do scripters need to wait for some minimal viewer version to be >>> required before assuming they can use this and have everyone see the >>> same result? >>> >>> On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater >>> >>> wrote: >>>> exactly so, Strife - the new flags are ORed (or added, i s'pose) >>>> the the >>>> existing type field. >>>> >>>> MIRROR mirrors along the x-axis, while INVERT flips the direction >>>> of the >>>> surface (normals). >>>> >>>> >>>> K. >>>> >>>> On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: >>>> >>>>> Hey I just saw the featurettes-5 check in on the public SVN, >>>>> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >>>>> I was wondering, could we get an LSL example for >>>>> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >>>>> PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is >>>>> but I >>>>> want to make sure. >>>>> >>>>> llSetPrimitiveParams([ >>>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | >>>>> PRIM_SCULPT_FLAG_MIRROR >>>>> ]) >>>>> >>>>> llSetPrimitiveParams([ >>>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT >>>>> ]) >>>>> >>>>> llSetPrimitiveParams([ >>>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR >>>>> ]) >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> From me at signpostmarv.name Sun Jul 13 14:16:57 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Jul 13 14:17:02 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> Message-ID: <487A70C9.40909@signpostmarv.name> What about PRIM_SCULPT_TYPE_MASK ? Can we has screenshots/vid example ? Karl Stiefvater wrote: > exactly so, Strife - the new flags are ORed (or added, i s'pose) the > the existing type field. > > MIRROR mirrors along the x-axis, while INVERT flips the direction of > the surface (normals). > > > K. > > On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: > >> Hey I just saw the featurettes-5 check in on the public SVN, >> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >> I was wondering, could we get an LSL example for >> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >> PRIM_SCULPT_FLAG_MIRROR? > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080713/04649b1a/smime.bin From me at signpostmarv.name Sun Jul 13 14:24:13 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Jul 13 14:24:25 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> Message-ID: <487A727D.7060202@signpostmarv.name> Isn't that a contradiction ? You've said MIRROR is there to have "a symmetric shape"- why bother with that when you could "just re-generate the sculpty map" ? Why not MIRROR_X, MIRROR_Y, MIRROR_Z instead of just MIRROR ? Karl Stiefvater wrote: > it depends on what end-result you're trying to achieve. > > if you just want the prim to have the same visual appearance as if the > y and z channels were swapped, you can achieve the same thing turning > on MIRROR and rotating the prim 90 degrees. > > the reasoning for these two new flags is that they give a substantial > advantage. MIRROR gives you (without the need of a second map) a > symmetric shape (e.g. shoes.) INVERT will give you a backside to > your planar sculpts. in both cases - the number of necessary sculpt > maps is reduced. > > offhand, i don't see the advantage of swapping two channels. couldn't > you just re-generate the sculpt map? > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080713/ced58495/smime-0001.bin From secret.argent at gmail.com Sun Jul 13 14:59:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jul 13 14:59:52 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> Message-ID: On 2008-07-13, at 13:21, Karl Stiefvater wrote: > exactly so, Strife - the new flags are ORed (or added, i s'pose) > the the existing type field. > > MIRROR mirrors along the x-axis, while INVERT flips the direction > of the surface (normals). All right! That will cut down the number of unique sculpt textures required for symmetrical objects. From secret.argent at gmail.com Sun Jul 13 15:02:15 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jul 13 15:02:23 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> Message-ID: On 2008-07-13, at 16:16, Karl Stiefvater wrote: > the reasoning for these two new flags is that they give a > substantial advantage. MIRROR gives you (without the need of a > second map) a symmetric shape (e.g. shoes.) INVERT will give you > a backside to your planar sculpts. in both cases - the number of > necessary sculpt maps is reduced. How about sculpty animation, while you're in there? Up to 8 frames would be plenty! From qarl at lindenlab.com Sun Jul 13 16:31:10 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Sun Jul 13 16:31:12 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <487A727D.7060202@signpostmarv.name> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> <487A727D.7060202@signpostmarv.name> Message-ID: <598575AF-3915-4272-8FF1-95047743885C@lindenlab.com> > Isn't that a contradiction ? i don't think so? > You've said MIRROR is there to have "a symmetric shape"- why bother > with that when you could "just re-generate the sculpty map" ? because you often need BOTH shapes at the same time (both shoes) and this eliminates half of the necessary sculpt maps. i'm not aware of any typical use cases where you need two sculpt maps for exchanging channels. not to mention that (as i said) exchanging two channels is equivalent to one mirror + one rotation. > Why not MIRROR_X, MIRROR_Y, MIRROR_Z instead of just MIRROR ? because algebraically all the other mirrors can be achieved with rotation + mirror + rotation. K. From aimee at ama-zing.co.uk Sun Jul 13 17:06:26 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sun Jul 13 17:06:33 2008 Subject: [sldev] featurettes-5 missing files? Message-ID: llcubemap.cpp llpostprocess.cpp llrendersphere.cpp and llshadermgr.cpp seem to have gone AWOL from llrender in the featurettes-5 branch at rev. 725? Aimee. From sheet.spotter at gmail.com Sun Jul 13 17:19:40 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sun Jul 13 17:22:18 2008 Subject: [SLDEV][VWR] Viewer Memory Manager Message-ID: <000701c8e547$4f864f20$2a02a8c0@kenb> The Viewer Roadmap includes a "Viewer Memory Manager" project with a "Fix Viewer Memory Leaks" deliverable. http://wiki.secondlife.com/wiki/Viewer_Roadmap http://wiki.secondlife.com/wiki/Viewer_Memory_Manager Has there been progress on the Viewer Memory Manager? Is there an opportunity to contribute to this initiative? Sheet Spotter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080713/e374f74a/attachment.htm From secret.argent at gmail.com Sun Jul 13 17:48:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Jul 13 17:48:10 2008 Subject: [SLDEV][VWR] Viewer Memory Manager In-Reply-To: <000701c8e547$4f864f20$2a02a8c0@kenb> References: <000701c8e547$4f864f20$2a02a8c0@kenb> Message-ID: <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> Where is "persistent Windlight customizations" on that roadmap? From robla at lindenlab.com Sun Jul 13 19:19:42 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Jul 13 19:19:45 2008 Subject: [SLDEV][VWR] Viewer Memory Manager In-Reply-To: <000701c8e547$4f864f20$2a02a8c0@kenb> References: <000701c8e547$4f864f20$2a02a8c0@kenb> Message-ID: <1216001982.10470.33.camel@oopsy.hsd1.wa.comcast.net> On Sun, 2008-07-13 at 19:19 -0500, Sheet Spotter wrote: > The Viewer Roadmap includes a ?Viewer Memory Manager? project with a > ?Fix Viewer Memory Leaks? deliverable. > > http://wiki.secondlife.com/wiki/Viewer_Roadmap > > http://wiki.secondlife.com/wiki/Viewer_Memory_Manager > > > Has there been progress on the Viewer Memory Manager? Not that I'm aware of. I think that's on the near-term roadmap (per office hour discussion about ?VWR-3943). > Is there an opportunity to contribute to this initiative? I think it'd be handy to put any suggestions that you have on this page: https://wiki.secondlife.com/wiki/Talk:Viewer_Memory_Manager It may just be that we eliminate Smartheap on Windows and call it a day, but if there's something out there that we should be using, we'd appreciate the pointer. Rob From soft at lindenlab.com Sun Jul 13 20:35:38 2008 From: soft at lindenlab.com (Soft) Date: Sun Jul 13 20:35:40 2008 Subject: [sldev] featurettes-5 missing files? In-Reply-To: References: Message-ID: Looks like featurettes-5 branched off release/ before release was restabilized after a bunch of c-make changes. I'll manually pick the related changes in the morning or see about rebranching. On Sun, Jul 13, 2008 at 7:06 PM, Aimee Walton wrote: > llcubemap.cpp llpostprocess.cpp llrendersphere.cpp and llshadermgr.cpp seem > to have gone AWOL from llrender in the featurettes-5 branch at rev. 725? > > Aimee. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From q at lindenlab.com Sun Jul 13 21:11:38 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Sun Jul 13 21:11:43 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com><4877C40F.2050901@lindenlab.com><4878D6CE.6000107@cox.net><48794404.7020602@c ox.net> Message-ID: On Jul 12, 2008, at 9:22 PM, Edward Artaud wrote: > > On Sat, Jul 12, 2008 at 4:53 PM, Lawson English > wrote: > Seriously, its a set of protocols (very limited at the moment) to > facilitate grid interop, and it eventually will become the basis for > a [more or less] complete redesign of the server architecture (I > suspect) and even further off, the client (I hope). > > > That was my concern when I was posting about the need for a plug-in > architecture. Is it likely that OGP will yield anything useful for > the client until this time next year? Most of the actual coding > will go into PyOGP, so by the end of the year, it'll be roughly > equivalent in terms of functionality to where libsl (openmv) is > today, but using the cleaner protocol and in Python rather than C#. > At that point, I suppose it'll need to be ported to C++ and somehow > bolted onto the SL viewer, which will take another 6 months, and > then we'll be roughly where we are today, but with a new underlying > protocol layer. At that point, we'll be able to start refactoring > the viewer architecture. I hope I'm wrong and it takes half that > time. Please understand that there's no reasonable way to create a redesigned SL 2.0 from scratch that's independent of the current codebase. It's simply not practical to reinvent the wheel. For better or worse, we have to evolve our way to the next level. What that means for things like OGP is that we need to follow the following sequence of events for each element of the protocols: * Identify the protocol in question and define its scope * Write the protocol specification * Publish the spec and get feedback; iterate as necessary. * Build the server side of the specification * Independently build the client side test code from the specification only, to prove that it works and that it's possible to build a working test client from the specs alone * Implement it in viewer code as an alternate path that falls back to the old code if it fails * Deploy the server side in a test grid * Ask people to try it out on the test grid * Deploy server side on the main grid alongside the old path * Run both versions in parallel for a while to make sure that it really works * Obsolete the old version eventually * Remove old code from the viewer Some of these paths can be run in parallel for some parts of the protocol stack -- but the process simply takes a while. Part of the refactoring we're doing on the viewer is designed to make it easier to do some of these things. Part of the refactoring will be a result of moving our APIs behind well-defined protocols. It's gonna take some time. But it's not a binary state -- we're trying to make continuous improvements. We'll never be "done", but hopefully a year from now things will look a lot better. And a year after that, better still. Q -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080714/bd72a78a/attachment-0001.htm From bboomslang at googlemail.com Mon Jul 14 04:49:20 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Mon Jul 14 04:49:23 2008 Subject: [SLDEV][VWR] Viewer Memory Manager In-Reply-To: <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> Message-ID: <347b550f0807140449x68314d7fq2c899e73e27cf093@mail.gmail.com> On 7/14/08, Argent Stonecutter wrote: > Where is "persistent Windlight customizations" on that roadmap? Yes, it's kinda sad that they still don't store the windlight settings users can make in any place that's remotely useful and not overwritten by the next client. I mean, how hard can it be to change the path where you store windlight settings? Doesn't sound like rocket science to me ... bye, Barney From alissa_sabre at yahoo.co.jp Mon Jul 14 05:01:38 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Jul 14 05:01:46 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STL compatibility issue In-Reply-To: <9bb32d430807100006t543e24f2g7ade9d57bf790998@mail.gmail.com> References: <9bb32d430807100006t543e24f2g7ade9d57bf790998@mail.gmail.com> Message-ID: <8ndu40wJ7Y7bk071s6a.alissa_sabre@yahoo.co.jp> Hi, Ambrosia. THank you for an interesting info. > 3. copy the llimagej2coj.vcproj to llimagej2coj_vc8.vcproj > 4. copy EZ_LCD_wrapper.lib to EZ_LCD_wrapper_vc8.lib > 5. switching to ReleaseForDownload I guess you need to open VS solution file between the step 4 and 5 above, and no earlier than that point. Am I right? And I'm not sure why you need to have a file of name EZ_LCD_wrapper_vc8.lib. If EZ_LCD_wrapper is VS version sensitive, and you need a separate libraries for VS7.1 and VS8, simply copying it should not work properly... Alternatively, if EZ_LCD_wrapper is compatible with both VS7.1 and VS8, you can just use the same file without copying. Or, am I missing something? Alissa Sabre -------------------------------------- Stop! Global Warming ~ Yahoo! JAPAN Earth Project http://pr.mail.yahoo.co.jp/earthproject/ From tao.takashi at googlemail.com Mon Jul 14 06:29:27 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Mon Jul 14 06:29:35 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> <48794404.7020602@cox.net> Message-ID: <23bbb49e0807140629l68cb6b53rd01631b662b9ad16@mail.gmail.com> Hi! On Sun, Jul 13, 2008 at 4:22 AM, Edward Artaud wrote: > > On Sat, Jul 12, 2008 at 4:53 PM, Lawson English wrote: >> >> Seriously, its a set of protocols (very limited at the moment) to >> facilitate grid interop, and it eventually will become the basis for a [more >> or less] complete redesign of the server architecture (I suspect) and even >> further off, the client (I hope). > > > That was my concern when I was posting about the need for a plug-in > architecture. Is it likely that OGP will yield anything useful for the > client until this time next year? Most of the actual coding will go into > PyOGP, so by the end of the year, it'll be roughly equivalent in terms of > functionality to where libsl (openmv) is today, but using the cleaner > protocol and in Python rather than C#. At that point, I suppose it'll need > to be ported to C++ and somehow bolted onto the SL viewer, which will take > another 6 months, and then we'll be roughly where we are today, but with a > new underlying protocol layer. At that point, we'll be able to start > refactoring the viewer architecture. I hope I'm wrong and it takes half > that time. I don't think the path will be protocol => Python => C++, it is more likely that it's a parallel thing between Python and C++. Linden Lab already implemented the login part into a branch of their existing viewer. But as Q laid out, it simply takes it's time to build a quality protocol esp. as it's not the simplest one and additionaly has many social issues, too. What it enables on the long run though is I think also many implementations of the client. Right now I wouldn't dare to start a new one because a) the existing protocol is not really documented b) it might change quite often in maybe not documented ways With an official definition which maybe even has gone through a standardization institution it cannot change that often. It can also not change that often given the numbers of servers and different grid running it then. So you are on a safer side to write such a client. And a client can then be of any complexity you like, be it just text, 2D or 3D with more or less features. I think even a browser plugin might then be easier. -- Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From chaosstar at gmail.com Mon Jul 14 06:39:31 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Jul 14 06:39:34 2008 Subject: [sldev] 1.20.12 build problem on Windows regarding STL compatibility issue In-Reply-To: <8ndu40wJ7Y7bk071s6a.alissa_sabre@yahoo.co.jp> References: <9bb32d430807100006t543e24f2g7ade9d57bf790998@mail.gmail.com> <8ndu40wJ7Y7bk071s6a.alissa_sabre@yahoo.co.jp> Message-ID: <9bb32d430807140639l1a5f611ega9e5c9fb64f81a8e@mail.gmail.com> Basically, the linker is looking for EZ_LCD_wrapper_vc8.lib and not EZ_LCD_wrapper.lib in the vc8 solution settings. But, yes, there seems no actual by renaming or copying the lib itself. as for what EZ LCD are, quote 'ezLCD is a line of USB intelligent color TFT LCD modules that can be integrated into any embedded systems via a serial, i2c, USB, SPI or parallel interface.' So mostly not used. You could probably remove the lllcd.cpp from the solution ( I think that was the source part used) but really, just rename the .lib and all will work fine. I have -no- idea why it's looking for a specific _vc8.lib. I also have no idea if those special LCDs will work fine, but I guess they will. And yes, between step 4 and 5, open the solutions file. On Mon, Jul 14, 2008 at 14:01, Alissa Sabre wrote: > Hi, Ambrosia. THank you for an interesting info. > >> 3. copy the llimagej2coj.vcproj to llimagej2coj_vc8.vcproj >> 4. copy EZ_LCD_wrapper.lib to EZ_LCD_wrapper_vc8.lib >> 5. switching to ReleaseForDownload > > I guess you need to open VS solution file between the step 4 and 5 > above, and no earlier than that point. Am I right? > > And I'm not sure why you need to have a file of name > EZ_LCD_wrapper_vc8.lib. If EZ_LCD_wrapper is VS version sensitive, > and you need a separate libraries for VS7.1 and VS8, simply copying it > should not work properly... Alternatively, if EZ_LCD_wrapper is > compatible with both VS7.1 and VS8, you can just use the same file > without copying. > > Or, am I missing something? > > Alissa Sabre > -------------------------------------- > Stop! Global Warming ~ Yahoo! JAPAN Earth Project > http://pr.mail.yahoo.co.jp/earthproject/ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From soft at lindenlab.com Mon Jul 14 07:10:22 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 14 07:10:25 2008 Subject: [SLDEV][VWR] Viewer Memory Manager In-Reply-To: <347b550f0807140449x68314d7fq2c899e73e27cf093@mail.gmail.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> <347b550f0807140449x68314d7fq2c899e73e27cf093@mail.gmail.com> Message-ID: On Mon, Jul 14, 2008 at 6:49 AM, Barney Boomslang wrote: > On 7/14/08, Argent Stonecutter wrote: >> Where is "persistent Windlight customizations" on that roadmap? > > Yes, it's kinda sad that they still don't store the windlight settings > users can make in any place that's remotely useful and not overwritten > by the next client. I mean, how hard can it be to change the path > where you store windlight settings? Doesn't sound like rocket science > to me ... Something's more likely to come of whatever new eyes the discussion adds if you reference your JIRA: https://jira.secondlife.com/browse/VWR-4981 From edward.artaud at gmail.com Mon Jul 14 07:53:00 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Mon Jul 14 07:53:04 2008 Subject: [sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4878D6CE.6000107@cox.net> Message-ID: I'm not in disagreement with any of the points made, I certainly was not trying to criticize the merits or pace of OGP. My original point about plug-ins and the original poster's point about "SL 2.0" were what I would categorize as "viewer refactoring." I was trying to state, and I think you've confirmed, that a viewer refactoring effort is loosely tied to OGP and could take place in parallel. My point was that saying SL 2.0 = OGP does not seem to me to be an accurate statement, OGP is an important part of SL 2.0, but I'd hope we don't have to wait for it to be done before addressing any of the other issues, like viewer refactoring. On Sun, Jul 13, 2008 at 9:11 PM, Kent Quirk (Q Linden) wrote: > Please understand that there's no reasonable way to create a redesigned SL > 2.0 from scratch that's independent of the current codebase. It's simply not > practical to reinvent the wheel. For better or worse, we have to evolve our > way to the next level. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080714/19323254/attachment.htm From palmer at lindenlab.com Mon Jul 14 09:19:41 2008 From: palmer at lindenlab.com (Palmer Truelson (Zen Linden)) Date: Mon Jul 14 09:20:32 2008 Subject: [SLDEV][VWR] Viewer Memory Manager In-Reply-To: <000701c8e547$4f864f20$2a02a8c0@kenb> References: <000701c8e547$4f864f20$2a02a8c0@kenb> Message-ID: <487B7C9D.3060205@lindenlab.com> Sheet Spotter wrote: > > The Viewer Roadmap includes a ?Viewer Memory Manager? project with a > ?Fix Viewer Memory Leaks? deliverable. > > http://wiki.secondlife.com/wiki/Viewer_Roadmap > > http://wiki.secondlife.com/wiki/Viewer_Memory_Manager > > Has there been progress on the Viewer Memory Manager? > > Is there an opportunity to contribute to this initiative? > Figured I could give a quick update. We tried tcmalloc for a bit in windows, but we have not come up with a solution for a bug tcmalloc has when built in release mode in VC8 where it fails its own unit tests. I've left a report of it on the google perf tools' homepage, and I'm hoping Craig or one of the other google folks takes a look. By all means, take a look and see if you can get tcmalloc to run in release mode in VC8. You would have at least my undying gratitude. :) However, I did port (possibly a little hackily... I need to clean it up) their profiler to windows. The client runs at about 5 fps, and there are some image loading problems, but we are investigating a leak we found that appears to be coming from some GL drivers, though it's a little hairy to pin down and we're waiting to hear back from ATI. I'm unfortunately not focused on this project right now as the crash reporter is keeping me busy, but others are, and we'd love to hear if you come up with anything useful. Also, we haven't tried heap layers, nedmalloc, or any of the other memory managers du jour yet, so if you get some promising results, especially backed up by data, we'd love to hear it. Zen > Sheet Spotter > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From palmer at lindenlab.com Mon Jul 14 09:26:23 2008 From: palmer at lindenlab.com (Palmer Truelson (Zen Linden)) Date: Mon Jul 14 09:27:14 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> Message-ID: <487B7E2F.9010407@lindenlab.com> Argent Stonecutter wrote: > Where is "persistent Windlight customizations" on that roadmap? > *Sigh*. I'm one of the folks who wants to work on that, but I just can't justify working on it until the client's crash/freeze rate drops below 10% of all sessions, which is still ridiculously high, but would be a huge improvement. PT > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From labrat.hb at gmail.com Mon Jul 14 09:33:48 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Mon Jul 14 09:33:51 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <487B7E2F.9010407@lindenlab.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> <487B7E2F.9010407@lindenlab.com> Message-ID: I guess that would somewhat depend on what you consider a "session". My last crash happened after having beein in SL active with the latest RC after 14 hours and frankly I thought that was pretty damned stable On Mon, Jul 14, 2008 at 9:26 AM, Palmer Truelson (Zen Linden) wrote: > Argent Stonecutter wrote: >> >> Where is "persistent Windlight customizations" on that roadmap? >> > *Sigh*. I'm one of the folks who wants to work on that, but I just can't > justify working on it until the client's crash/freeze rate drops below 10% > of all sessions, which is still ridiculously high, but would be a huge > improvement. > > PT > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From palmer at lindenlab.com Mon Jul 14 09:44:05 2008 From: palmer at lindenlab.com (Palmer Truelson (Zen Linden)) Date: Mon Jul 14 09:44:56 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <487B7E2F.9010407@lindenlab.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb><770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> <487B7E2F.9010407@lindenlab.com> Message-ID: <487B8255.5000706@lindenlab.com> Palmer Truelson (Zen Linden) wrote: > Argent Stonecutter wrote: >> Where is "persistent Windlight customizations" on that roadmap? >> > *Sigh*. I'm one of the folks who wants to work on that, but I just > can't justify working on it until the client's crash/freeze rate drops > below 10% of all sessions, which is still ridiculously high, but would > be a huge improvement. > > PT Whoops. I was talking about Windlight tradable assets. You mean the save location one that I really need to fix. I'll bump it up on my list. PT >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From labrat.hb at gmail.com Mon Jul 14 09:54:52 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Mon Jul 14 09:54:55 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <487B8255.5000706@lindenlab.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> <487B7E2F.9010407@lindenlab.com> <487B8255.5000706@lindenlab.com> Message-ID: Tradeable assets, Scriptable assets, estate / parcel asset setting... those would be quite nice On Mon, Jul 14, 2008 at 9:44 AM, Palmer Truelson (Zen Linden) wrote: > Palmer Truelson (Zen Linden) wrote: >> >> Argent Stonecutter wrote: >>> >>> Where is "persistent Windlight customizations" on that roadmap? >>> >> *Sigh*. I'm one of the folks who wants to work on that, but I just can't >> justify working on it until the client's crash/freeze rate drops below 10% >> of all sessions, which is still ridiculously high, but would be a huge >> improvement. >> >> PT > > Whoops. I was talking about Windlight tradable assets. You mean the save > location one that I really need to fix. I'll bump it up on my list. > > PT >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From palmer at lindenlab.com Mon Jul 14 09:59:00 2008 From: palmer at lindenlab.com (Palmer Truelson (Zen Linden)) Date: Mon Jul 14 09:59:52 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <487B8255.5000706@lindenlab.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb><770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com><487B7E2F.9010407@lindenlab.com> <487B8255.5000706@lindenlab.com> Message-ID: <487B85D4.7080504@lindenlab.com> Palmer Truelson (Zen Linden) wrote: > Palmer Truelson (Zen Linden) wrote: >> > Whoops. I was talking about Windlight tradable assets. You mean the > save location one that I really need to fix. I'll bump it up on my list. > ... and looking at my list, I'm probably not going to get to it for a little while. I would be more than happy to review and shepherd a patch for it, though. Zen From missannotoole at yahoo.com Mon Jul 14 11:23:43 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon Jul 14 11:23:46 2008 Subject: [SLDEV][VWR] Windlight Assets Message-ID: <60117.27611.qm@web59108.mail.re1.yahoo.com> How about the means for sim managers to control windlight settings in viewers that enter the sim? Will that be part of tradeable assets? ----- Original Message ---- From: Palmer Truelson (Zen Linden) To: sldev@lists.secondlife.com Sent: Monday, July 14, 2008 12:59:00 PM Subject: Re: [SLDEV][VWR] Windlight Assets Palmer Truelson (Zen Linden) wrote: > Palmer Truelson (Zen Linden) wrote: >> > Whoops. I was talking about Windlight tradable assets. You mean the > save location one that I really need to fix. I'll bump it up on my list. > ... and looking at my list, I'm probably not going to get to it for a little while. I would be more than happy to review and shepherd a patch for it, though. Zen _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080714/f587c1d4/attachment.htm From palmer at lindenlab.com Mon Jul 14 11:46:36 2008 From: palmer at lindenlab.com (Palmer Truelson (Zen Linden)) Date: Mon Jul 14 11:47:28 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <60117.27611.qm@web59108.mail.re1.yahoo.com> References: <60117.27611.qm@web59108.mail.re1.yahoo.com> Message-ID: <487B9F0C.6050500@lindenlab.com> Ann Otoole wrote: > How about the means for sim managers to control windlight settings in > viewers that enter the sim? Will that be part of tradeable assets? > Sim management of settings will be part of it. That's arguably the most important requirement, and if the project is broken into deliverables, that will probably be one of the first. PT > ----- Original Message ---- > From: Palmer Truelson (Zen Linden) > To: sldev@lists.secondlife.com > Sent: Monday, July 14, 2008 12:59:00 PM > Subject: Re: [SLDEV][VWR] Windlight Assets > > Palmer Truelson (Zen Linden) wrote: > > Palmer Truelson (Zen Linden) wrote: > >> > > Whoops. I was talking about Windlight tradable assets. You mean the > > save location one that I really need to fix. I'll bump it up on my > list. > > > ... and looking at my list, I'm probably not going to get to it for a > little while. I would be more than happy to review and shepherd a patch > for it, though. > > Zen > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Mon Jul 14 18:01:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 14 18:01:05 2008 Subject: [SLDEV][VWR] Windlight Assets In-Reply-To: <487B7E2F.9010407@lindenlab.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <770E89F1-4335-474A-82CC-6B6DC97C283E@gmail.com> <487B7E2F.9010407@lindenlab.com> Message-ID: <534E0AFA-9DCF-443D-A7A9-EACB074C804E@gmail.com> On 2008-07-14, at 11:26, Palmer Truelson (Zen Linden) wrote: > *Sigh*. I'm one of the folks who wants to work on that, but I just > can't justify working on it until the client's crash/freeze rate > drops below 10% of all sessions, which is still ridiculously high, > but would be a huge improvement. Whoa. I'm nowhere NEAR having 10% of my sessions crashing out. Are you sure of that figure? From jacek.antonelli at gmail.com Mon Jul 14 20:04:50 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Mon Jul 14 20:04:52 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> Message-ID: <105c09f0807142004s19657a4r968b94775d3dd094@mail.gmail.com> On Sun, Jul 13, 2008 at 5:02 PM, Argent Stonecutter wrote: > On 2008-07-13, at 16:16, Karl Stiefvater wrote: >> >> the reasoning for these two new flags is that they give a substantial >> advantage. MIRROR gives you (without the need of a second map) a symmetric >> shape (e.g. shoes.) INVERT will give you a backside to your planar >> sculpts. in both cases - the number of necessary sculpt maps is reduced. > > How about sculpty animation, while you're in there? Up to 8 frames would be > plenty! I want a pony! Can we have a pony, too? Can we, Qarl? Pleeease? ~_^ Ungratefully yours, - Jacek P.S. Is it human nature that when given a gift, we ask for more instead of giving thanks? From tateru.nino at gmail.com Mon Jul 14 22:02:48 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jul 14 22:04:18 2008 Subject: [SLDEV][VWR] Viewer Memory Manager In-Reply-To: <487B7C9D.3060205@lindenlab.com> References: <000701c8e547$4f864f20$2a02a8c0@kenb> <487B7C9D.3060205@lindenlab.com> Message-ID: <487C2F78.3000907@weblogsinc.com> Palmer Truelson (Zen Linden) wrote: > Sheet Spotter wrote: >> >> The Viewer Roadmap includes a ?Viewer Memory Manager? project with a >> ?Fix Viewer Memory Leaks? deliverable. >> >> http://wiki.secondlife.com/wiki/Viewer_Roadmap >> >> http://wiki.secondlife.com/wiki/Viewer_Memory_Manager >> >> Has there been progress on the Viewer Memory Manager? >> >> Is there an opportunity to contribute to this initiative? >> > Figured I could give a quick update. > > We tried tcmalloc for a bit in windows, but we have not come up with a > solution for a bug tcmalloc has when built in release mode in VC8 > where it fails its own unit tests. I've left a report of it on the > google perf tools' homepage, and I'm hoping Craig or one of the other > google folks takes a look. By all means, take a look and see if you > can get tcmalloc to run in release mode in VC8. You would have at > least my undying gratitude. :) > > However, I did port (possibly a little hackily... I need to clean it > up) their profiler to windows. The client runs at about 5 fps, and > there are some image loading problems, but we are investigating a leak > we found that appears to be coming from some GL drivers, though it's a > little hairy to pin down and we're waiting to hear back from ATI. > > I'm unfortunately not focused on this project right now as the crash > reporter is keeping me busy, but others are, and we'd love to hear if > you come up with anything useful. > > Also, we haven't tried heap layers, nedmalloc, or any of the other > memory managers du jour yet, so if you get some promising results, > especially backed up by data, we'd love to hear it. We used dlmalloc for our linux-based multi-million-user grid system a few years ago. Well worth the effort for us. It was a big win. One of the key things that made it a winner for us was that it's performance was no _worse_ than most other allocators, and that it could return unused heap back to the system pool -- a feature which no other allocator at the time seemed to do, and which turned out to be a critical win for controlling memory growth on our servers. The conditions of that release are fairly specific - there must be contiguous unused memory at the end of the heap for a release to function (a heap shrink via sbrk) but when we put it into practice, by golly, it worked extremely well! It certainly allowed us to compete favorably with operating systems that couldn't shrink the heap (almost all of them), and with operating systems that _could_ but applications that _couldn't_. We ended up relinking _everything_ with it, and enjoying the reduced memory pressure overall and better peak availability of memory to processes. -- Tateru Nino http://www.massively.com/ From webmaster at ligosworld.com Tue Jul 15 05:54:19 2008 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Tue Jul 15 05:53:40 2008 Subject: [sldev] Problems with the cams matrix! Message-ID: <487C9DFB.2050602@ligosworld.com> Hi, i'm trying to render some primitives on an own rendering engine. i use the camera classes from lindens source code. Now the axis seems to be wrong. E.g. objects are standing on the head, and the gl translations are not going in the correct direction. So can anybody tell me what i'm doing wrong? Is this a mistake in initializing the cam? or do i have to modify the modelview matrix before rendering the prims? From lenglish5 at cox.net Tue Jul 15 06:04:51 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Jul 15 06:04:53 2008 Subject: [sldev] [ANN][AWG} Daily pyogp meetings continue Message-ID: <487CA073.4090709@cox.net> Our first daily meeting went well: http://wiki.secondlife.com/wiki/Pyogp/Chat_Logs/Daily_Meeting/14_jul_2008 And we are continuing today. Our irc channel became 10-20x as active after the first meeting. Was pretty cool to lurk and watch. what PyOGP Coders Meeting who PyOGP l33t C0d3rZ where "infinity is full of stars" @ http://slurl.com/secondlife/Levenhall/91/208/22 when 9:30AM SLT / 12:30PM Eastern Time / 5:30PM GMT / 6:30PM Central European Time why for PyOGP contributors to hash out architecture, design, test and deploy issues IRC: irc://irc.freenode.com/#pyogp Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp wiki: http://wiki.secondlife.com/wiki/Pyogp Lawson From webmaster at ligosworld.com Tue Jul 15 06:57:26 2008 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Tue Jul 15 06:56:49 2008 Subject: [sldev] Problems with the cams matrix! Message-ID: <487CACC6.9000009@ligosworld.com> The problems seems to be, that the modelview matrix is represented in Cory's favourite reference frame. Can anyone explain a bit more about this Matrix, and about the way, how i am able to render Volumes with this modelview? From mumismo at gmail.com Tue Jul 15 09:49:23 2008 From: mumismo at gmail.com (Jordi Polo) Date: Tue Jul 15 09:49:25 2008 Subject: [sldev] Qt for the viewer Message-ID: I want to point to this article: http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ I personally love Qt and I am sure that all the on-screen widgets and menues would be far easier to program using it. Along with integrated XML library, webkit (dont know how this mix with the webkit on opengl project), styles, phonon and other goodies. But I guess that would be too big of a change. -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080716/786e95be/attachment.htm From kwerks.sl at gmail.com Tue Jul 15 13:54:49 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jul 15 13:54:53 2008 Subject: [sldev] Qt for the viewer In-Reply-To: References: Message-ID: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> Qt is ok, but personally I find WxWidgets much easier to deal with. MOC is a strange creature. That said, I rather like the current ui tools. If as much time were put into a good refactoring and decoupling, making the current ui tools into an independant library as it would take to port to Qt or Wx, I think that would be a very useful toolkit for cross-plat GL work. Perhaps that's generous though ;) regards JB On Tue, Jul 15, 2008 at 12:49 PM, Jordi Polo wrote: > > I want to point to this article: > > http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ > > > I personally love Qt and I am sure that all the on-screen widgets and > menues would be far easier to program using it. Along with integrated XML > library, webkit (dont know how this mix with the webkit on opengl project), > styles, phonon and other goodies. > But I guess that would be too big of a change. > > -- > Jordi Polo Carres > NLP laboratory - NAIST > http://www.bahasara.org > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080715/ff356c91/attachment.htm From soft at lindenlab.com Tue Jul 15 14:02:25 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 15 14:02:28 2008 Subject: [sldev] Qt for the viewer In-Reply-To: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> References: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> Message-ID: If anyone spends time evaluating or experimenting with either, be sure to look into i18n support. I believe it was Alissa, contributor of more than a dozen Asian language support viewer patches, who said that Asian language support was problematic under Qt. On Tue, Jul 15, 2008 at 3:54 PM, JB Kraft wrote: > Qt is ok, but personally I find WxWidgets much easier to deal with. MOC is a > strange creature. That said, I rather like the current ui tools. If as much > time were put into a good refactoring and decoupling, making the current ui > tools into an independant library as it would take to port to Qt or Wx, I > think that would be a very useful toolkit for cross-plat GL work. Perhaps > that's generous though ;) > > regards > JB > > On Tue, Jul 15, 2008 at 12:49 PM, Jordi Polo wrote: >> >> I want to point to this article: >> >> http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ >> >> >> I personally love Qt and I am sure that all the on-screen widgets and >> menues would be far easier to program using it. Along with integrated XML >> library, webkit (dont know how this mix with the webkit on opengl project), >> styles, phonon and other goodies. >> But I guess that would be too big of a change. >> >> -- >> Jordi Polo Carres >> NLP laboratory - NAIST >> http://www.bahasara.org >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From robla at lindenlab.com Tue Jul 15 14:06:49 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 15 14:06:54 2008 Subject: [sldev] Decoupling UI widget set from rest of viewer (Re: Qt for the viewer) In-Reply-To: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> References: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> Message-ID: <487D1169.4090704@lindenlab.com> On 7/15/08 1:54 PM, JB Kraft wrote: > Qt is ok, but personally I find WxWidgets much easier to deal with. > MOC is a strange creature. That said, I rather like the current ui > tools. If as much time were put into a good refactoring and > decoupling, making the current ui tools into an independant library as > it would take to port to Qt or Wx, I think that would be a very useful > toolkit for cross-plat GL work. Perhaps that's generous though ;) Last I remembered, Alissa Sabre had done some early work for using Gtk for text input, out of frustration with the current UI's lack of support for things that matter greatly for non-Latin character sets. I don't know what the status of that work is (or remember the issue number in JIRA), or if the current UI has improved to enough to make it less of an issue, but I think she may have some well-informed thoughts and suggestions about decoupling. Rob From kwerks.sl at gmail.com Tue Jul 15 14:38:11 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Tue Jul 15 14:38:16 2008 Subject: [sldev] Re: Decoupling UI widget set from rest of viewer (Re: Qt for the viewer) In-Reply-To: <487D1169.4090704@lindenlab.com> References: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> <487D1169.4090704@lindenlab.com> Message-ID: <7b61e3970807151438v10af765bm5ae9f37179431374@mail.gmail.com> Thanks Rob. FWIW, investigating this is quite high on my hit list if I could just find the time (or a sponsor ;) for it. At this point, I think it would be a worthy pursuit. There is nothing like it out there as a toolkit that I am aware of. JB On Tue, Jul 15, 2008 at 5:06 PM, Rob Lanphier wrote: > > On 7/15/08 1:54 PM, JB Kraft wrote: > >> Qt is ok, but personally I find WxWidgets much easier to deal with. MOC is >> a strange creature. That said, I rather like the current ui tools. If as >> much time were put into a good refactoring and decoupling, making the >> current ui tools into an independant library as it would take to port to Qt >> or Wx, I think that would be a very useful toolkit for cross-plat GL work. >> Perhaps that's generous though ;) >> > > Last I remembered, Alissa Sabre had done some early work for using Gtk for > text input, out of frustration with the current UI's lack of support for > things that matter greatly for non-Latin character sets. I don't know what > the status of that work is (or remember the issue number in JIRA), or if the > current UI has improved to enough to make it less of an issue, but I think > she may have some well-informed thoughts and suggestions about decoupling. > > Rob > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080715/e8435a22/attachment.htm From blindwanderer at gmail.com Tue Jul 15 19:29:10 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Tue Jul 15 19:29:14 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> Message-ID: <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER. Strife On Sun, Jul 13, 2008 at 4:00 PM, Darien Caldwell wrote: > As long as work is being done of this nature, could we get flags to > rotate maps too? > > For instance I have maps where I would flip it around so the Y > coordinates of the map alter the Z coordiates of the prim, and vice > versa (in this case the X coordiates would stay the same). Or is there > some simple thing that would allow this that I'm missing? > > On 7/13/08, Strife Onizuka wrote: >> The way things appear in featurettes-5, until these changes hit an >> official release, using either PRIM_SCULPT_FLAG_INVERT or >> PRIM_SCULPT_FLAG_MIRROR (or the associated checkboxes in the build >> tools) will result in the prims being rendered as >> PRIM_SCULPT_TYPE_PLANE >> >> On Sun, Jul 13, 2008 at 2:50 PM, Soft wrote: >>> Do scripters need to wait for some minimal viewer version to be >>> required before assuming they can use this and have everyone see the >>> same result? >>> >>> On Sun, Jul 13, 2008 at 1:21 PM, Karl Stiefvater >>> wrote: >>>> exactly so, Strife - the new flags are ORed (or added, i s'pose) the the >>>> existing type field. >>>> >>>> MIRROR mirrors along the x-axis, while INVERT flips the direction of the >>>> surface (normals). >>>> >>>> >>>> K. >>>> >>>> On Jul 13, 2008, at 8:19 AM, Strife Onizuka wrote: >>>> >>>>> Hey I just saw the featurettes-5 check in on the public SVN, >>>>> http://svn.secondlife.com/trac/linden/changeset/758?new_path=%2F >>>>> I was wondering, could we get an LSL example for >>>>> PRIM_SCULPT_TYPE_MASK, PRIM_SCULPT_FLAG_INVERT & >>>>> PRIM_SCULPT_FLAG_MIRROR? I have an idea about what the usage is but I >>>>> want to make sure. >>>>> >>>>> llSetPrimitiveParams([ >>>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT | >>>>> PRIM_SCULPT_FLAG_MIRROR >>>>> ]) >>>>> >>>>> llSetPrimitiveParams([ >>>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_INVERT >>>>> ]) >>>>> >>>>> llSetPrimitiveParams([ >>>>> PRIM_TYPE, PRIM_TYPE_SCULPT, "texture", >>>>> PRIM_SCULPT_TYPE_SPHERE | PRIM_SCULPT_FLAG_MIRROR >>>>> ]) >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From kelly at lindenlab.com Tue Jul 15 20:54:56 2008 From: kelly at lindenlab.com (kelly@lindenlab.com) Date: Tue Jul 15 20:54:58 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com><8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com><89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com><835a5b860 807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> Message-ID: <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> > A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or > PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER. > > Strife > Pardon my naivete (I'm not an expert on sculpties at all) but ... how is rotating a sculpt texture different from rotating the actual prim? - Kelly From secret.argent at gmail.com Wed Jul 16 05:14:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 16 05:14:03 2008 Subject: OpenGL toolkits (Re: [sldev] Qt for the viewer) In-Reply-To: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> References: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> Message-ID: <7A41B69C-FEB2-4E1F-9F0F-3CF747257477@gmail.com> On 2008-07-15, at 15:54, JB Kraft wrote: > Qt is ok, but personally I find WxWidgets much easier to deal with. > MOC is a strange creature. That said, I rather like the current ui > tools. If as much time were put into a good refactoring and > decoupling, making the current ui tools into an independant library > as it would take to port to Qt or Wx, I think that would be a very > useful toolkit for cross-plat GL work. Perhaps that's generous > though ;) I had a similar idea a year or so ago, and started to tear into the toolkit, but decided it was really too specialized to be a good starting point. It could do with a refactoring, but I don't think it would really attract much outside attention: there are already a few OpenGL GUI toolkits it'd be competing against. A couple that look interesting: http://libufo.sourceforge.net/ - OpenGL UI toolkit that uses CSS and XUL forms, and it can be dropped into an existing openGL context. http://www.fltk.org/ - This one's been around longer, and may be more mature. Both are LGPL and thus compatible with Second Life's licensing ... both the open source and commercial versions. From suzhanna.rossini at balsaestates.com Wed Jul 16 06:13:01 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Wed Jul 16 06:13:19 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> Message-ID: <00d701c8e745$adc6dd70$09549850$@rossini@balsaestates.com> I also get this error when trying at a friend who has VS2003.. We tried with svn release 772.. Here're the error messages produced at link time: Linking... llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(class std::basic_string,class std::allocator > const &,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) Alexandra > I would start by looking at lscript_compile to see whether the > parameters, return type and calling convention match between the > header and the function body. It's possible VS2008 is stricter about > some attribute than VS2003 and VS2005 are - so far as I know, there > isn't any type checking at all on "C" (cdecl) symbols in either. > > On Thu, Jul 10, 2008 at 7:30 AM, Suzhanna Rossini > wrote: > > Really noone that have any ideas on how to solve this? > > > > > >> > >> I'm trying to build the client with VS2008, and everything works > smooth > >> and > >> fine up to linking, I get this no matter how I try: > >> > >> 3>Linking... > >> 3>llcompilequeue.obj : error LNK2019: unresolved external symbol > "int > >> __cdecl lscript_compile(char const *,char const *,char const *,int)" > >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > void > >> __thiscall LLFloaterCompileQueue::compile(class > >> std::basic_string,class > >> std::allocator > const &,class LLUUID const &)" > >> > (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@ > >> D@std > >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) > >> 3>llpreviewscript.obj : error LNK2001: unresolved external symbol > "int > >> __cdecl lscript_compile(char const *,char const *,char const *,int)" > >> (?lscript_compile@@YAHPBD00H@Z) > >> > >> Anyone with ideas please? Currently I'm using a svn pull of > "Release", > >> r732. > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > From qarl at lindenlab.com Wed Jul 16 08:42:52 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Wed Jul 16 08:42:54 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com><8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com><89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com><835a5b860 807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> Message-ID: <97F48F24-8BAD-4E93-A76A-7887EBE426C1@lindenlab.com> > Pardon my naivete (I'm not an expert on sculpties at all) but ... > how is > rotating a sculpt texture different from rotating the actual prim? it's sorta "complicated". by rotating the sculpt image, you effectively change the order in which the samples are read, so you: 1) invert the normals (because it alters the "handedness" of the orientation.) 2) change the layout of the texture coordinates. but both of these can now be done by toggling the INVERT flag and applying a rotation to the texture coordinates. so Strife will really need to explain why this is a "big win". again, let me emphasize - the motivation of the new options is to improve efficiency. i'm failing to see how these extra options are any more efficient. K. From jacek.antonelli at gmail.com Wed Jul 16 11:05:05 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Wed Jul 16 11:05:08 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <598575AF-3915-4272-8FF1-95047743885C@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> <487A727D.7060202@signpostmarv.name> <598575AF-3915-4272-8FF1-95047743885C@lindenlab.com> Message-ID: <105c09f0807161105y35dcc0f3l57a3681368398369@mail.gmail.com> On Sun, Jul 13, 2008 at 6:31 PM, Karl Stiefvater wrote: >> Why not MIRROR_X, MIRROR_Y, MIRROR_Z instead of just MIRROR ? > > because algebraically all the other mirrors can be achieved with rotation + > mirror + rotation. I do think that Y and Z would be good to have -- even if the effect can be achieved through other, less approachable methods. The majority of sculpty users are _artists and designers_, not mathematicians or comp sci geeks. They don't know (and aren't interested in learning) the mathematical voodoo behind all this, they just want to get the effect they're looking for. So, adding Y and Z would be a big win in usability and user-friendliness. :-) Even if Y and Z aren't added (yet), I think it would be a good plan to use MIRROR_X instead of MIRROR. It's only 2 characters longer, it's more descriptive, and it leaves open the possibility of future additions of the Y and Z axes. The only down side is that people might wonder why there's no Y and Z yet. :-D Regards, - Jacek From gigstaggart at gmail.com Wed Jul 16 11:44:04 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 16 11:44:08 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <105c09f0807161105y35dcc0f3l57a3681368398369@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <835a5b860807131300v1a3d109ej9c94d6e494ab9a03@mail.gmail.com> <487A727D.7060202@signpostmarv.name> <598575AF-3915-4272-8FF1-95047743885C@lindenlab.com> <105c09f0807161105y35dcc0f3l57a3681368398369@mail.gmail.com> Message-ID: <487E4174.8080606@gmail.com> Jacek Antonelli wrote: > I do think that Y and Z would be good to have -- even if the effect > can be achieved through other, less approachable methods. The majority > of sculpty users are _artists and designers_, not mathematicians or > comp sci geeks. They don't know (and aren't interested in learning) > the mathematical voodoo behind all this, they just want to get the > effect they're looking for. So, adding Y and Z would be a big win in > usability and user-friendliness. :-) That seems like a total non-sequitur to me. Adding seemingly redundant operations with technical differences that matter little to the average artist/designer will just confuse them. I'm with Karl, I'm not seeing a compelling case for anything other than the invert. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080716/27ceeb61/smime.bin From aimee at ama-zing.co.uk Wed Jul 16 11:55:54 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Jul 16 11:56:06 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: <00d701c8e745$adc6dd70$09549850$@rossini@balsaestates.com> References: <-5008687841307650898@unknownmsgid> <00d701c8e745$adc6dd70$09549850$@rossini@balsaestates.com> Message-ID: On Jul 16, 2008, at 14:13, Suzhanna Rossini wrote: > I also get this error when trying at a friend who has VS2003.. > We tried with svn release 772.. > Here're the error messages produced at link time: > > Linking... > llcompilequeue.obj : error LNK2019: unresolved external symbol "int > __cdecl > lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > void > __thiscall LLFloaterCompileQueue::compile(class > std::basic_string,class > std::allocator > const &,class LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU? > $char_traits@D@std > @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) > > llpreviewscript.obj : error LNK2001: unresolved external symbol > "int __cdecl > lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) I've also been getting the equivalent error message during linking building with Xcode on the Mac. indra.l.cpp and indra.y.cpp seem to be being pulled into the project incorrectly as indra.l.cpp.rule and indra.y.cpp.rule, manually pointing it to the proper files fixed the problem. Aimee. From soft at lindenlab.com Wed Jul 16 11:58:29 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 16 11:58:32 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> Message-ID: On Wed, Jul 16, 2008 at 1:55 PM, Aimee Walton wrote: > > On Jul 16, 2008, at 14:13, Suzhanna Rossini wrote: > >> I also get this error when trying at a friend who has VS2003.. >> We tried with svn release 772.. >> Here're the error messages produced at link time: >> >> Linking... >> llcompilequeue.obj : error LNK2019: unresolved external symbol "int >> __cdecl >> lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void >> __thiscall LLFloaterCompileQueue::compile(class >> std::basic_string,class >> std::allocator > const &,class LLUUID const &)" >> >> (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) >> >> llpreviewscript.obj : error LNK2001: unresolved external symbol "int >> __cdecl >> lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) > > I've also been getting the equivalent error message during linking building > with Xcode on the Mac. > > indra.l.cpp and indra.y.cpp seem to be being pulled into the project > incorrectly as indra.l.cpp.rule and indra.y.cpp.rule, manually pointing it > to the proper files fixed the problem. I'm checking this out. The fix to the featurettes branch drops shortly as well. From qarl at lindenlab.com Wed Jul 16 12:16:54 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Wed Jul 16 12:16:57 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <20080716190030.0976C41B2FC@stupor.lindenlab.com> References: <20080716190030.0976C41B2FC@stupor.lindenlab.com> Message-ID: <2CE7890A-97CF-4CB6-8553-9BEA611332CA@lindenlab.com> > I do think that Y and Z would be good to have -- even if the effect > can be achieved through other, less approachable methods. The majority > of sculpty users are _artists and designers_, not mathematicians or > comp sci geeks. They don't know (and aren't interested in learning) > the mathematical voodoo behind all this, they just want to get the > effect they're looking for. So, adding Y and Z would be a big win in > usability and user-friendliness. :-) yeah, i get that. (trust me, i'm a big fan of artists and designers.) but: 1) this isn't really the right "level" to support that sort of feature. it's more of a UI sort of thing, not a low-level sort of thing. similar to how you wouldn't want your filesystem to need to worry about text formatting (bold/italic/etc.) 2) in the grand scheme of things, LL gives MUCH higher priority to stability over features. as i said, the new options improve sculpt- map efficiency - so they win. 3) most practically - by simply rotating the model first before you generate the sculpt map, you can effectively mirror along ANY plane (not just the X, Y, and Z planes.) this is the preferred method since it gives you more freedom. (and as such, you can see how a single mirror option is more "fundamental" than the other ones.) it really has nothing to do with the extra two characters "_X". :) K. From aimee at ama-zing.co.uk Wed Jul 16 12:50:42 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Jul 16 12:50:53 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> Message-ID: <6A913EF3-9199-42A5-9024-1C6E869777F4@ama-zing.co.uk> On Jul 16, 2008, at 19:58, Soft wrote: > I'm checking this out. The fix to the featurettes branch drops > shortly as well. Thanks Soft :) Aimee. From blindwanderer at gmail.com Wed Jul 16 18:08:09 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Wed Jul 16 18:08:13 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> Message-ID: <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> I seem not have been understood by anyone. Time for a second crack at it. It has to do with the stitching for cylinder and sphere types. On the cylinder it stitches the left to the right, and on the sphere it also pinches the top and bottom edges. What I'm advocating is a way to have it instead stitch the top and bottom to each other, and do the pinch on the left and right. For the other two sculpty types it doesn't matter if they are rotated because the edges are all handled the same. There are two ways of dealing with this, either implement a ROTATE flag or add new sculpty types that have that stitching, the results will be the same. Strife On Tue, Jul 15, 2008 at 11:54 PM, wrote: >> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or >> PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER. >> >> Strife >> > > Pardon my naivete (I'm not an expert on sculpties at all) but ... how is > rotating a sculpt texture different from rotating the actual prim? > > - Kelly > > From qarl at lindenlab.com Wed Jul 16 18:16:18 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Wed Jul 16 18:16:21 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> Message-ID: <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> ok - but i still feel like this falls under the category of "convenience" and not "efficiency", right? all the rotate buys you is a quick fix for when your sculpt exporter isn't smart enough to generate the right map. i'd argue that you merely fix the exporter, and leave the low-level interface as minimal as possible. K. On Jul 16, 2008, at 6:08 PM, Strife Onizuka wrote: > I seem not have been understood by anyone. Time for a second crack > at it. > > It has to do with the stitching for cylinder and sphere types. On the > cylinder it stitches the left to the right, and on the sphere it also > pinches the top and bottom edges. What I'm advocating is a way to have > it instead stitch the top and bottom to each other, and do the pinch > on the left and right. For the other two sculpty types it doesn't > matter if they are rotated because the edges are all handled the same. > There are two ways of dealing with this, either implement a ROTATE > flag or add new sculpty types that have that stitching, the results > will be the same. > > Strife > > On Tue, Jul 15, 2008 at 11:54 PM, wrote: >>> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or >>> PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER. >>> >>> Strife >>> >> >> Pardon my naivete (I'm not an expert on sculpties at all) but ... >> how is >> rotating a sculpt texture different from rotating the actual prim? >> >> - Kelly >> >> From mumismo at gmail.com Wed Jul 16 20:30:06 2008 From: mumismo at gmail.com (Jordi Polo) Date: Wed Jul 16 20:30:10 2008 Subject: OpenGL toolkits (Re: [sldev] Qt for the viewer) In-Reply-To: <7A41B69C-FEB2-4E1F-9F0F-3CF747257477@gmail.com> References: <7b61e3970807151354v1109d84br9426ad42643655d2@mail.gmail.com> <7A41B69C-FEB2-4E1F-9F0F-3CF747257477@gmail.com> Message-ID: IMHO, Qt is more than an OpenGL toolkit. It is almost accidentally also able to render widgets on OpenGL. I see the following interesting features on Qt: - Running on win, mac, linux (I guess other options also achieve this) - Styles engine (at least libufo should be able to do this) - Integrated HTML rendering engine webkit (I guess ligufo has Gecko) - Model/ view programming for widgets - Containers (ala libstdc++), classes to access the filesystem, sockets, etc. - Multithread and parallel programming helper classes - XML and Phonon modules that may be used instead of other current dependences - Big community (KDE, thats it) - In development for a number of years now, Ive been said it is pretty optimized. Qt can substitute (in the code, Qt itself may depend on those libraries) : - Apache portable runtime (sockets and networking classes) - Glib - GTK+ - Multimedia related libraries (Phonon) I am not very sure how powerful is Phonon though, never used it. It may not be enough for viewers needs. - Freetype? (not sure) - SDL - mozlib (when the embedded webkit is ready) Qt would provide one API, signals between components and easy threading for all these. On Wed, Jul 16, 2008 at 9:14 PM, Argent Stonecutter wrote: > On 2008-07-15, at 15:54, JB Kraft wrote: > >> Qt is ok, but personally I find WxWidgets much easier to deal with. MOC is >> a strange creature. That said, I rather like the current ui tools. If as >> much time were put into a good refactoring and decoupling, making the >> current ui tools into an independant library as it would take to port to Qt >> or Wx, I think that would be a very useful toolkit for cross-plat GL work. >> Perhaps that's generous though ;) >> > > I had a similar idea a year or so ago, and started to tear into the > toolkit, but decided it was really too specialized to be a good starting > point. It could do with a refactoring, but I don't think it would really > attract much outside attention: there are already a few OpenGL GUI toolkits > it'd be competing against. > > A couple that look interesting: > > http://libufo.sourceforge.net/ - OpenGL UI toolkit that uses CSS and XUL > forms, and it can be dropped into an existing openGL context. > http://www.fltk.org/ - This one's been around longer, and may be more > mature. > > Both are LGPL and thus compatible with Second Life's licensing ... both the > open source and commercial versions. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080717/0a954952/attachment.htm From robin.cornelius at gmail.com Thu Jul 17 05:17:07 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jul 17 05:17:11 2008 Subject: [sldev] Open source meeting - Thursday, 2pm PT, call for items Message-ID: Hi everyone, The usual Thursday routine, Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda See you in Hippotropolis later. Robin From alissa_sabre at yahoo.co.jp Thu Jul 17 07:45:04 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Jul 17 07:45:14 2008 Subject: [sldev] Decoupling UI widget set from rest of viewer (Re: Qt for the viewer) In-Reply-To: <487D1169.4090704@lindenlab.com> References: <487D1169.4090704@lindenlab.com> Message-ID: <1ds4dsdds4kYbebaerb6Pwwk.alissa_sabre@yahoo.co.jp> > If anyone spends time evaluating or experimenting with either, be sure > to look into i18n support. I believe it was Alissa, contributor of > more than a dozen Asian language support viewer patches, who said that > Asian language support was problematic under Qt. Well, my understainding is that Qt is very poor in handling input methods on Windows and MacOS. I think Qt handles input methods well on Linux. I see no big problem in international text drawing on Qt's standard widgets. I don't remember that, but if I said Asian language support was problematic under Qt, I meant input method handling was problematic on Qt running on Windows or MacOS. Note that _input_method_ is a generic name for mechanisms that allows a users to use his/her standard keyboard to type characters more than those labeled on the key tops. In particular, some East Asian languages including Japanese and Chinese require thousands of characters, so it is essential to use a good input method to type texts in those languages. I believe Gtk is almost same case as Qt; it is poor handling input methods on Windows and MacOS. It's OK on Linux, and intermational text drawing is OK on all three platforms. I have no experience on wxWidgets, but a quick googling showed a lot of complains on Japanese input features on wxWidgets, even on Linux. > Last I remembered, Alissa Sabre had done some early work for using Gtk > for text input, out of frustration with the current UI's lack of support > for things that matter greatly for non-Latin character sets. Yes, but it is for Linux only. I believe that the current SL viewer's input method handling on Windows and Linux is OK. The reason the current SL viewer on Linux lack good support for input methods is that SDL is very poor in handling input methods. So, I tried to adapt SL viewer to Gtk based input handling, primarily suggested by Tofu Linden. (See VWR-2261 on Public JIRA.) Well, I was very busy in my RL in June, and the Tofu's offer (as the last comment to the above PJIRA issue) is currently pending. I don't support, however, an idea to rewrite SL viewer to use Gtk widget natively. The work VWR-2261 does is use Gtk to create a big main window, and run SL viewer in the window using current LLUI framework. It is in Linux specific code. I had no intention to use Gtk native widget to create SL viewer UI or to use Gtk on Windows/MacOS. Alissa Sabre -------------------------------------- Stop! Global Warming ~ Yahoo! JAPAN Earth Project http://pr.mail.yahoo.co.jp/earthproject/ From soft at lindenlab.com Thu Jul 17 11:19:12 2008 From: soft at lindenlab.com (Soft) Date: Thu Jul 17 11:19:17 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> Message-ID: On Wed, Jul 16, 2008 at 1:55 PM, Aimee Walton wrote: > > On Jul 16, 2008, at 14:13, Suzhanna Rossini wrote: > >> I also get this error when trying at a friend who has VS2003.. >> We tried with svn release 772.. >> Here're the error messages produced at link time: >> >> Linking... >> llcompilequeue.obj : error LNK2019: unresolved external symbol "int >> __cdecl >> lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void >> __thiscall LLFloaterCompileQueue::compile(class >> std::basic_string,class >> std::allocator > const &,class LLUUID const &)" >> >> (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) >> >> llpreviewscript.obj : error LNK2001: unresolved external symbol "int >> __cdecl >> lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) > > I've also been getting the equivalent error message during linking building > with Xcode on the Mac. > > indra.l.cpp and indra.y.cpp seem to be being pulled into the project > incorrectly as indra.l.cpp.rule and indra.y.cpp.rule, manually pointing it > to the proper files fixed the problem. This is strange. I've tried with VS2005 and XCode and I'm not having any problem with either. Aimee, Suzhanna - Would you please walk through the steps you're using to unpack and build? It's possible there's a bogus step in our instructions that wants fixing. From neil30328 at hotmail.com Thu Jul 17 12:21:34 2008 From: neil30328 at hotmail.com (neil roger) Date: Thu Jul 17 12:21:36 2008 Subject: [sldev] RE: SLDev Digest, Vol 19, Issue 35 In-Reply-To: <20080717181917.ED58541B19C@stupor.lindenlab.com> References: <20080717181917.ED58541B19C@stupor.lindenlab.com> Message-ID: I would like to bring back the opinion that people being phantom using lsl scripts should be removed.> From: sldev-request@lists.secondlife.com> Subject: SLDev Digest, Vol 19, Issue 35> To: sldev@lists.secondlife.com> Date: Thu, 17 Jul 2008 11:19:17 -0700> > Send SLDev mailing list submissions to> sldev@lists.secondlife.com> > To subscribe or unsubscribe via the World Wide Web, visit> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> or, via email, send a message with subject or body 'help' to> sldev-request@lists.secondlife.com> > You can reach the person managing the list at> sldev-owner@lists.secondlife.com> > When replying, please edit your Subject line so it is more specific> than "Re: Contents of SLDev digest..."> > > Today's Topics:> > 1. Re: Re: New Sculpty Features (Karl Stiefvater)> 2. Re: SV: [sldev] Unresolved externals (Aimee Walton)> 3. Re: Re: New Sculpty Features (Strife Onizuka)> 4. Re: Re: New Sculpty Features (Karl Stiefvater)> 5. Re: OpenGL toolkits (Re: [sldev] Qt for the viewer) (Jordi Polo)> 6. Open source meeting - Thursday, 2pm PT, call for items> (Robin Cornelius)> 7. Re: Decoupling UI widget set from rest of viewer (Re: Qt for> the viewer) (Alissa Sabre)> 8. Re: SV: [sldev] Unresolved externals (Soft)> > > ----------------------------------------------------------------------> > Message: 1> Date: Wed, 16 Jul 2008 12:16:54 -0700> From: Karl Stiefvater > Subject: Re: [sldev] Re: New Sculpty Features> To: sldev@lists.secondlife.com> Message-ID: <2CE7890A-97CF-4CB6-8553-9BEA611332CA@lindenlab.com>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes> > > I do think that Y and Z would be good to have -- even if the effect> > can be achieved through other, less approachable methods. The majority> > of sculpty users are _artists and designers_, not mathematicians or> > comp sci geeks. They don't know (and aren't interested in learning)> > the mathematical voodoo behind all this, they just want to get the> > effect they're looking for. So, adding Y and Z would be a big win in> > usability and user-friendliness. :-)> > yeah, i get that. (trust me, i'm a big fan of artists and designers.)> > but:> > 1) this isn't really the right "level" to support that sort of > feature. it's more of a UI sort of thing, not a low-level sort of > thing. similar to how you wouldn't want your filesystem to need to > worry about text formatting (bold/italic/etc.)> > 2) in the grand scheme of things, LL gives MUCH higher priority to > stability over features. as i said, the new options improve sculpt- > map efficiency - so they win.> > 3) most practically - by simply rotating the model first before you > generate the sculpt map, you can effectively mirror along ANY plane > (not just the X, Y, and Z planes.) this is the preferred method since > it gives you more freedom. (and as such, you can see how a single > mirror option is more "fundamental" than the other ones.)> > it really has nothing to do with the extra two characters "_X". :)> > > > K.> > > > ------------------------------> > Message: 2> Date: Wed, 16 Jul 2008 20:50:42 +0100> From: Aimee Walton > Subject: Re: SV: [sldev] Unresolved externals> To: Second Life Developer Mailing List > Message-ID: <6A913EF3-9199-42A5-9024-1C6E869777F4@ama-zing.co.uk>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed> > > On Jul 16, 2008, at 19:58, Soft wrote:> > > I'm checking this out. The fix to the featurettes branch drops > > shortly as well.> > Thanks Soft :)> > Aimee.> > > ------------------------------> > Message: 3> Date: Wed, 16 Jul 2008 21:08:09 -0400> From: "Strife Onizuka" > Subject: Re: [sldev] Re: New Sculpty Features> To: kelly@lindenlab.com> Cc: Karl Stiefvater , Second Life Developer> Mailing List > Message-ID:> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com>> Content-Type: text/plain; charset=UTF-8> > I seem not have been understood by anyone. Time for a second crack at it.> > It has to do with the stitching for cylinder and sphere types. On the> cylinder it stitches the left to the right, and on the sphere it also> pinches the top and bottom edges. What I'm advocating is a way to have> it instead stitch the top and bottom to each other, and do the pinch> on the left and right. For the other two sculpty types it doesn't> matter if they are rotated because the edges are all handled the same.> There are two ways of dealing with this, either implement a ROTATE> flag or add new sculpty types that have that stitching, the results> will be the same.> > Strife> > On Tue, Jul 15, 2008 at 11:54 PM, wrote:> >> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or> >> PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER.> >>> >> Strife> >>> >> > Pardon my naivete (I'm not an expert on sculpties at all) but ... how is> > rotating a sculpt texture different from rotating the actual prim?> >> > - Kelly> >> >> > > ------------------------------> > Message: 4> Date: Wed, 16 Jul 2008 18:16:18 -0700> From: Karl Stiefvater > Subject: Re: [sldev] Re: New Sculpty Features> To: "Strife Onizuka" > Cc: Second Life Developer Mailing List > Message-ID: <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes> > ok - but i still feel like this falls under the category of > "convenience" and not "efficiency", right?> > all the rotate buys you is a quick fix for when your sculpt exporter > isn't smart enough to generate the right map. i'd argue that you > merely fix the exporter, and leave the low-level interface as minimal > as possible.> > K.> > On Jul 16, 2008, at 6:08 PM, Strife Onizuka wrote:> > > I seem not have been understood by anyone. Time for a second crack > > at it.> >> > It has to do with the stitching for cylinder and sphere types. On the> > cylinder it stitches the left to the right, and on the sphere it also> > pinches the top and bottom edges. What I'm advocating is a way to have> > it instead stitch the top and bottom to each other, and do the pinch> > on the left and right. For the other two sculpty types it doesn't> > matter if they are rotated because the edges are all handled the same.> > There are two ways of dealing with this, either implement a ROTATE> > flag or add new sculpty types that have that stitching, the results> > will be the same.> >> > Strife> >> > On Tue, Jul 15, 2008 at 11:54 PM, wrote:> >>> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or> >>> PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER.> >>>> >>> Strife> >>>> >>> >> Pardon my naivete (I'm not an expert on sculpties at all) but ... > >> how is> >> rotating a sculpt texture different from rotating the actual prim?> >>> >> - Kelly> >>> >>> > > > ------------------------------> > Message: 5> Date: Thu, 17 Jul 2008 12:30:06 +0900> From: "Jordi Polo" > Subject: Re: OpenGL toolkits (Re: [sldev] Qt for the viewer)> To: "Argent Stonecutter" > Cc: Second Life Developer Mailing List > Message-ID:> > Content-Type: text/plain; charset="iso-8859-1"> > IMHO, Qt is more than an OpenGL toolkit. It is almost accidentally also able> to render widgets on OpenGL.> I see the following interesting features on Qt:> > - Running on win, mac, linux (I guess other options also achieve this)> - Styles engine (at least libufo should be able to do this)> - Integrated HTML rendering engine webkit (I guess ligufo has Gecko)> - Model/ view programming for widgets> - Containers (ala libstdc++), classes to access the filesystem, sockets,> etc.> - Multithread and parallel programming helper classes> - XML and Phonon modules that may be used instead of other current> dependences> - Big community (KDE, thats it)> - In development for a number of years now, Ive been said it is pretty> optimized.> > Qt can substitute (in the code, Qt itself may depend on those libraries) :> - Apache portable runtime (sockets and networking classes)> - Glib> - GTK+> - Multimedia related libraries (Phonon) I am not very sure how powerful is> Phonon though, never used it. It may not be enough for viewers needs.> - Freetype? (not sure)> - SDL> - mozlib (when the embedded webkit is ready)> > Qt would provide one API, signals between components and easy threading for> all these.> > > On Wed, Jul 16, 2008 at 9:14 PM, Argent Stonecutter > wrote:> > > On 2008-07-15, at 15:54, JB Kraft wrote:> >> >> Qt is ok, but personally I find WxWidgets much easier to deal with. MOC is> >> a strange creature. That said, I rather like the current ui tools. If as> >> much time were put into a good refactoring and decoupling, making the> >> current ui tools into an independant library as it would take to port to Qt> >> or Wx, I think that would be a very useful toolkit for cross-plat GL work.> >> Perhaps that's generous though ;)> >>> >> > I had a similar idea a year or so ago, and started to tear into the> > toolkit, but decided it was really too specialized to be a good starting> > point. It could do with a refactoring, but I don't think it would really> > attract much outside attention: there are already a few OpenGL GUI toolkits> > it'd be competing against.> >> > A couple that look interesting:> >> > http://libufo.sourceforge.net/ - OpenGL UI toolkit that uses CSS and XUL> > forms, and it can be dropped into an existing openGL context.> > http://www.fltk.org/ - This one's been around longer, and may be more> > mature.> >> > Both are LGPL and thus compatible with Second Life's licensing ... both the> > open source and commercial versions.> >> > _______________________________________________> > Policies and (un)subscribe information available here:> > http://wiki.secondlife.com/wiki/SLDev> > Please read the policies before posting to keep unmoderated posting> > privileges> >> > > > -- > Jordi Polo Carres> NLP laboratory - NAIST> http://www.bahasara.org> -------------- next part --------------> An HTML attachment was scrubbed...> URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080717/0a954952/attachment-0001.htm> > ------------------------------> > Message: 6> Date: Thu, 17 Jul 2008 13:17:07 +0100> From: "Robin Cornelius" > Subject: [sldev] Open source meeting - Thursday, 2pm PT, call for> items> To: "Second Life Developer Mailing List" > Message-ID:> > Content-Type: text/plain; charset=ISO-8859-1> > Hi everyone,> > The usual Thursday routine,> > Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis> http://slurl.com/secondlife/Hippotropolis/239/28/24> > As usual, any items for discussion please add to :-> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda> > See you in Hippotropolis later.> > Robin> > > ------------------------------> > Message: 7> Date: Thu, 17 Jul 2008 23:45:04 +0900> From: alissa_sabre@yahoo.co.jp (Alissa Sabre)> Subject: Re: [sldev] Decoupling UI widget set from rest of viewer (Re:> Qt for the viewer)> To: sldev@lists.secondlife.com> Message-ID: <1ds4dsdds4kYbebaerb6Pwwk.alissa_sabre@yahoo.co.jp>> Content-Type: text/plain; charset=US-ASCII> > > > If anyone spends time evaluating or experimenting with either, be sure> > to look into i18n support. I believe it was Alissa, contributor of> > more than a dozen Asian language support viewer patches, who said that> > Asian language support was problematic under Qt.> > Well, my understainding is that Qt is very poor in handling input> methods on Windows and MacOS. I think Qt handles input methods well> on Linux. I see no big problem in international text drawing on Qt's> standard widgets. I don't remember that, but if I said Asian language> support was problematic under Qt, I meant input method handling was> problematic on Qt running on Windows or MacOS.> > Note that _input_method_ is a generic name for mechanisms that allows> a users to use his/her standard keyboard to type characters more than> those labeled on the key tops. In particular, some East Asian> languages including Japanese and Chinese require thousands of> characters, so it is essential to use a good input method to type> texts in those languages.> > I believe Gtk is almost same case as Qt; it is poor handling input> methods on Windows and MacOS. It's OK on Linux, and intermational> text drawing is OK on all three platforms.> > I have no experience on wxWidgets, but a quick googling showed a lot> of complains on Japanese input features on wxWidgets, even on Linux.> > > Last I remembered, Alissa Sabre had done some early work for using Gtk > > for text input, out of frustration with the current UI's lack of support > > for things that matter greatly for non-Latin character sets.> > Yes, but it is for Linux only. I believe that the current SL viewer's> input method handling on Windows and Linux is OK. The reason the> current SL viewer on Linux lack good support for input methods is that> SDL is very poor in handling input methods. So, I tried to adapt SL> viewer to Gtk based input handling, primarily suggested by Tofu> Linden. (See VWR-2261 on Public JIRA.)> > Well, I was very busy in my RL in June, and the Tofu's offer (as the> last comment to the above PJIRA issue) is currently pending.> > I don't support, however, an idea to rewrite SL viewer to use Gtk> widget natively. The work VWR-2261 does is use Gtk to create a big> main window, and run SL viewer in the window using current LLUI> framework. It is in Linux specific code. I had no intention to use> Gtk native widget to create SL viewer UI or to use Gtk on> Windows/MacOS.> > Alissa Sabre> --------------------------------------> Stop! Global Warming ~ Yahoo! JAPAN Earth Project> http://pr.mail.yahoo.co.jp/earthproject/> > > ------------------------------> > Message: 8> Date: Thu, 17 Jul 2008 13:19:12 -0500> From: Soft > Subject: Re: SV: [sldev] Unresolved externals> To: "Aimee Walton" > Cc: Second Life Developer Mailing List > Message-ID:> > Content-Type: text/plain; charset=ISO-8859-1> > On Wed, Jul 16, 2008 at 1:55 PM, Aimee Walton wrote:> >> > On Jul 16, 2008, at 14:13, Suzhanna Rossini wrote:> >> >> I also get this error when trying at a friend who has VS2003..> >> We tried with svn release 772..> >> Here're the error messages produced at link time:> >>> >> Linking...> >> llcompilequeue.obj : error LNK2019: unresolved external symbol "int> >> __cdecl> >> lscript_compile(char const *,char const *,char const *,int)"> >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void> >> __thiscall LLFloaterCompileQueue::compile(class> >> std::basic_string,class> >> std::allocator > const &,class LLUUID const &)"> >>> >> (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std> >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z)> >>> >> llpreviewscript.obj : error LNK2001: unresolved external symbol "int> >> __cdecl> >> lscript_compile(char const *,char const *,char const *,int)"> >> (?lscript_compile@@YAHPBD00H@Z)> >> > I've also been getting the equivalent error message during linking building> > with Xcode on the Mac.> >> > indra.l.cpp and indra.y.cpp seem to be being pulled into the project> > incorrectly as indra.l.cpp.rule and indra.y.cpp.rule, manually pointing it> > to the proper files fixed the problem.> > This is strange. I've tried with VS2005 and XCode and I'm not having> any problem with either.> > Aimee, Suzhanna - Would you please walk through the steps you're using> to unpack and build? It's possible there's a bogus step in our> instructions that wants fixing.> > > ------------------------------> > _______________________________________________> SLDev mailing list> SLDev@lists.secondlife.com> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> > > End of SLDev Digest, Vol 19, Issue 35> ************************************* _________________________________________________________________ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080717/8f244ee9/attachment-0001.htm From gigstaggart at gmail.com Thu Jul 17 13:06:10 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 17 13:06:14 2008 Subject: [sldev] RE: SLDev Digest, Vol 19, Issue 35 In-Reply-To: References: <20080717181917.ED58541B19C@stupor.lindenlab.com> Message-ID: <487FA632.40705@gmail.com> neil roger wrote: > I would like to bring back the opinion that people being phantom using lsl scripts should be removed. What about those using broken mail clients? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080717/ddd236a3/smime.bin From robla at lindenlab.com Thu Jul 17 16:00:56 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 17 16:01:06 2008 Subject: [sldev] Documenting the viewer source Message-ID: <487FCF28.5040407@lindenlab.com> Hi all, Here's the transcript for our open source meeting earlier today: https://wiki.secondlife.com/wiki/Open_Source_Meeting/2008-07-17 In the meeting, there was a request for more documentation. We talked about several things on this front: * The need for better comments - I think that this one can be addressed by you all asking about specific functions and source files, and submitting patches that add comments as you learn about files. We don't want to clutter up the code with statements of the obvious, but the people who are expert in this code base aren't the best judges of "obvious" anymore. * The need for better documentation on the wiki. I'd like to focus your attention on this page: https://wiki.secondlife.com/wiki/Viewer_Architecture The page in-and-of-itself isn't as important as all of the info it links to. The "Viewer Architecture" page itself probably isn't above some reorganization though, but most importantly, adding cross-links to current information is something that anyone here could do. For example, there's also this page: https://wiki.secondlife.com/wiki/Viewer_Roadmap ...and it's subpages. The subpages of each of these could stand to be cross-linked. Also there's this page: https://wiki.secondlife.com/wiki/Viewer_Software_Overview ....which kinda duplicates Viewer Architecture, and the two should probably be merged. A Linden can do this work (and I might just tackle it), but hey, it's a wiki, and you all have the power. So, any volunteers? Rob From aimee at ama-zing.co.uk Thu Jul 17 17:45:30 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Jul 17 17:45:45 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> Message-ID: On Jul 17, 2008, at 19:19, Soft wrote: > > This is strange. I've tried with VS2005 and XCode and I'm not having > any problem with either. > > Aimee, Suzhanna - Would you please walk through the steps you're using > to unpack and build? It's possible there's a bogus step in our > instructions that wants fixing. OK, going back a step and starting over from scratch ... 1) svn co-ed the release branch. 2) Downloaded and extracted artwork and "libs" packages. 3) Copied in fmod bits. 4) Open Xcode (2.4, I'm still using 10.4), indra/build-darwin-i386/ SecondLife.xcodeproj (not indra/newview/build-darwin-universal/ SecondLife.xcodeproj as listed in the instructions). 5) Hit Build (Active target left as ALL_BUILD and config RelWithDebInfo). Result ... Building target ?liblscript_compile.a? of project ?SecondLife? with configuration ?RelWithDebInfo? ? (2 warnings) Checking Dependencies warning: no rule to process file '....../indra/build-darwin-i386/ lscript/lscript_compile/indra.l.cpp.rule' of type file for architecture i386 warning: no rule to process file '....../indra/build-darwin-i386/ lscript/lscript_compile/indra.y.cpp.rule' of type file for architecture i386 Building target ?mac-crash-logger? of project ?SecondLife? with configuration ?RelWithDebInfo? ? (1 error) mkdir ....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo cd ....../indra/build-darwin-i386 /usr/bin/g++-4.0 -o ....../indra/build-darwin-i386/mac_crash_logger/ RelWithDebInfo/mac-crash-logger -L....../indra/build-darwin-i386/ mac_crash_logger/RelWithDebInfo -L....../indra/build-darwin-i386/ llcrashlogger/RelWithDebInfo/RelWithDebInfo -L....../indra/build- darwin-i386/llcrashlogger/RelWithDebInfo -L....../indra/build-darwin- i386/llvfs/RelWithDebInfo/RelWithDebInfo -L....../indra/build-darwin- i386/llvfs/RelWithDebInfo -L....../indra/../libraries/universal- darwin/lib_release/RelWithDebInfo -L....../indra/../libraries/ universal-darwin/lib_release -L....../indra/build-darwin-i386/llxml/ RelWithDebInfo/RelWithDebInfo -L....../indra/build-darwin-i386/llxml/ RelWithDebInfo -L....../indra/build-darwin-i386/llmessage/ RelWithDebInfo/RelWithDebInfo -L....../indra/build-darwin-i386/ llmessage/RelWithDebInfo -L....../indra/build-darwin-i386/llmath/ RelWithDebInfo/RelWithDebInfo -L....../indra/build-darwin-i386/llmath/ RelWithDebInfo -L....../indra/build-darwin-i386/llcommon/ RelWithDebInfo/RelWithDebInfo -L....../indra/build-darwin-i386/ llcommon/RelWithDebInfo -F....../indra/build-darwin-i386/ mac_crash_logger/RelWithDebInfo -filelist ....../indra/build-darwin- i386/mac_crash_logger/SecondLife.build/RelWithDebInfo/mac-crash- logger.build/Objects-normal/i386/mac-crash-logger.LinkFileList -arch i386 -Wl,-Y,1455 -L/opt/local/lib -L/usr/X11R6/lib -Wl,- headerpad_max_install_names,-search_paths_first ....../indra/build- darwin-i386/llcrashlogger/RelWithDebInfo/libllcrashlogger.a ....../ indra/build-darwin-i386/llvfs/RelWithDebInfo/libllvfs.a -framework Carbon -lexpat -lcurl ....../indra/../libraries/universal-darwin/ lib_release/cares -lssl -lllcrypto -lxmlrpc-epi ....../indra/../ libraries/universal-darwin/lib_release/aprutil-1 ....../indra/../ libraries/universal-darwin/lib_release/apr-1 -framework Carbon - lexpat -lcurl ....../indra/../libraries/universal-darwin/lib_release/ cares -lssl -lllcrypto -lxmlrpc-epi ....../indra/../libraries/ universal-darwin/lib_release/aprutil-1 ....../indra/../libraries/ universal-darwin/lib_release/apr-1 ....../indra/build-darwin-i386/ llxml/RelWithDebInfo/libllxml.a ....../indra/build-darwin-i386/ llmessage/RelWithDebInfo/libllmessage.a ....../indra/build-darwin- i386/llmath/RelWithDebInfo/libllmath.a ....../indra/build-darwin-i386/ llcommon/RelWithDebInfo/libllcommon.a -lz -lboost_signals-mt - lexpat ....../indra/build-darwin-i386/llmessage/RelWithDebInfo/ libllmessage.a -lcurl ....../indra/../libraries/universal-darwin/ lib_release/cares -lssl -lllcrypto -lxmlrpc-epi ....../indra/build- darwin-i386/llvfs/RelWithDebInfo/libllvfs.a -framework Carbon ....../ indra/build-darwin-i386/llmath/RelWithDebInfo/libllmath.a ....../ indra/build-darwin-i386/llcommon/RelWithDebInfo/libllcommon.a ....../ indra/../libraries/universal-darwin/lib_release/aprutil-1 ....../ indra/../libraries/universal-darwin/lib_release/apr-1 -lexpat -lz - lboost_signals-mt i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/cares: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/apr-1: No such file or directory Build failed (1 error, 2 warnings) From blindwanderer at gmail.com Thu Jul 17 19:05:26 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Thu Jul 17 19:05:29 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> Message-ID: <89ca6da00807171905p2897e83drb37a7e35b63a0ae4@mail.gmail.com> But you could say the same about _INVERT. When would you need both (normal and inverted) versions in a scene? I do agree, its easier (as a programmer) to just fix the exporter, be it to rotate the texture or flip the normals. *shrug* I don't personally need a _ROTATE flag or the _OTHER types, just looking at it from a completeness standpoint. You are more than welcome to rubber stamp this "PENDING CROQUET BECOMING AN OLYMPIC SPORT AGAIN" and I won't take offense. As always, Strife On Wed, Jul 16, 2008 at 9:16 PM, Karl Stiefvater wrote: > ok - but i still feel like this falls under the category of "convenience" > and not "efficiency", right? > > all the rotate buys you is a quick fix for when your sculpt exporter isn't > smart enough to generate the right map. i'd argue that you merely fix the > exporter, and leave the low-level interface as minimal as possible. > > K. > > On Jul 16, 2008, at 6:08 PM, Strife Onizuka wrote: > >> I seem not have been understood by anyone. Time for a second crack at it. >> >> It has to do with the stitching for cylinder and sphere types. On the >> cylinder it stitches the left to the right, and on the sphere it also >> pinches the top and bottom edges. What I'm advocating is a way to have >> it instead stitch the top and bottom to each other, and do the pinch >> on the left and right. For the other two sculpty types it doesn't >> matter if they are rotated because the edges are all handled the same. >> There are two ways of dealing with this, either implement a ROTATE >> flag or add new sculpty types that have that stitching, the results >> will be the same. >> >> Strife >> >> On Tue, Jul 15, 2008 at 11:54 PM, wrote: >>>> >>>> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or >>>> PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER. >>>> >>>> Strife >>>> >>> >>> Pardon my naivete (I'm not an expert on sculpties at all) but ... how is >>> rotating a sculpt texture different from rotating the actual prim? >>> >>> - Kelly >>> >>> > > From secret.argent at gmail.com Fri Jul 18 03:18:49 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jul 18 03:18:48 2008 Subject: [sldev] Decoupling UI widget set from rest of viewer (Re: Qt for the viewer) In-Reply-To: <1ds4dsdds4kYbebaerb6Pwwk.alissa_sabre@yahoo.co.jp> References: <487D1169.4090704@lindenlab.com> <1ds4dsdds4kYbebaerb6Pwwk.alissa_sabre@yahoo.co.jp> Message-ID: <136D1B7B-016F-481D-87B2-62EBBC397AA1@gmail.com> Are you guys sure Qt is native on Mac OS? I think it's still X11-based. From secret.argent at gmail.com Fri Jul 18 03:24:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jul 18 03:24:44 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <89ca6da00807171905p2897e83drb37a7e35b63a0ae4@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> <89ca6da00807171905p2897e83drb37a7e35b63a0ae4@mail.gmail.com> Message-ID: <881AE46D-E830-412F-A54D-D3264DDF6592@gmail.com> On 2008-07-17, at 21:05, Strife Onizuka wrote: > But you could say the same about _INVERT. When would you need both > (normal and inverted) versions in a scene? When using two nested sculpties as the inside and outside of a hollow object. From suzhanna.rossini at balsaestates.com Fri Jul 18 03:53:10 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 03:53:26 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> Message-ID: <000c01c8e8c4$78a0d760$69e28620$@rossini@balsaestates.com> > On Wed, Jul 16, 2008 at 1:55 PM, Aimee Walton > wrote: > > > > On Jul 16, 2008, at 14:13, Suzhanna Rossini wrote: > > > >> I also get this error when trying at a friend who has VS2003.. > >> We tried with svn release 772.. > >> Here're the error messages produced at link time: > >> > >> Linking... > >> llcompilequeue.obj : error LNK2019: unresolved external symbol "int > >> __cdecl > >> lscript_compile(char const *,char const *,char const *,int)" > >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > void > >> __thiscall LLFloaterCompileQueue::compile(class > >> std::basic_string,class > >> std::allocator > const &,class LLUUID const &)" > >> > >> > (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@ > D@std > >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) > >> > >> llpreviewscript.obj : error LNK2001: unresolved external symbol "int > >> __cdecl > >> lscript_compile(char const *,char const *,char const *,int)" > >> (?lscript_compile@@YAHPBD00H@Z) > > > > I've also been getting the equivalent error message during linking > building > > with Xcode on the Mac. > > > > indra.l.cpp and indra.y.cpp seem to be being pulled into the project > > incorrectly as indra.l.cpp.rule and indra.y.cpp.rule, manually > pointing it > > to the proper files fixed the problem. > > This is strange. I've tried with VS2005 and XCode and I'm not having > any problem with either. > > Aimee, Suzhanna - Would you please walk through the steps you're using > to unpack and build? It's possible there's a bogus step in our > instructions that wants fixing. Absolutely.. ;-) 1. Check out a clean copy of http://svn.secondlife.com/svn/linden/release (now I got r798). 2. Download and unzip the art/lib packages mentioned in release\doc\asset_urls.txt (slviewer-artwork-release-r92064.zip and slviewer-win32-libs-release-r92064.zip) 3. Copy in fmod, GL, llkdu.dll and QuickTime libs etc. 4. Open a Visual Studio .NET 2003 Command Prompt. 5. CD into the .\release\indra directory and run "develop.py -G VS2003 configure" (result, see attached "config_steps.txt") 6. Open indra\build-VS2003\SecondLife.sln in VS2003 7. Hit ctrl-shift-b to start the build. 8. Establish the fact that is still gives the errors.. (See buildlog.txt) /Alexandra -------------- next part -------------- ------ Build started: Project: llwindow, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llwindow/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llwindow.cpp llkeyboardwin32.cpp lldxhardware.cpp llwindowwin32.cpp llwindowheadless.cpp llkeyboard.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llwindow\llwindow.dir\RelWithDebInfo\BuildLog.htm" llwindow - 0 error(s), 0 warning(s) ------ Build started: Project: llcharacter, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llcharacter/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llvisualparam.cpp lltargetingmotion.cpp llstatemachine.cpp llpose.cpp llmultigesture.cpp llmotion.cpp llmotioncontroller.cpp llkeyframewalkmotion.cpp llkeyframestandmotion.cpp llkeyframemotionparam.cpp llkeyframemotion.cpp llkeyframefallmotion.cpp lljointsolverrp3.cpp lljoint.cpp llheadrotmotion.cpp llhandmotion.cpp llgesture.cpp lleditingmotion.cpp llcharacter.cpp llbvhloader.cpp Generating Code... Compiling... llanimationstates.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llcharacter\llcharacter.dir\RelWithDebInfo\BuildLog.htm" llcharacter - 0 error(s), 0 warning(s) ------ Build started: Project: copy_win_libs, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/newview/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Copying llkdu.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying llkdu.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying llkdu.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying wrap_oal.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying ortp.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying vivoxsdk.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying alut.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying srtp.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying SLVoiceAgent.exe C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying ssleay32.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying SLVoice.exe C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying libeay32.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying tntk.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying openjpeg.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying xul.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying xpcom.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying ssl3.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying softokn3.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying smime3.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying plds4.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying plc4.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying nssckbi.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying nss3.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying nspr4.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying js3250.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying gksvggdiplus.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying freebl3.dll C:/SLDev/release/indra/build-VS2003/newview/RelWithDebInfo Copying wrap_oal.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying ortp.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying vivoxsdk.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying alut.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying srtp.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying SLVoiceAgent.exe C:/SLDev/release/indra/build-VS2003/newview/Release Copying ssleay32.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying SLVoice.exe C:/SLDev/release/indra/build-VS2003/newview/Release Copying libeay32.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying tntk.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying openjpeg.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying xul.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying xpcom.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying ssl3.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying softokn3.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying smime3.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying plds4.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying plc4.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying nssckbi.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying nss3.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying nspr4.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying js3250.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying gksvggdiplus.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying freebl3.dll C:/SLDev/release/indra/build-VS2003/newview/Release Copying wrap_oal.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying ortp.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying vivoxsdk.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying alut.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying srtp.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying SLVoiceAgent.exe C:/SLDev/release/indra/build-VS2003/newview/Debug Copying ssleay32.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying SLVoice.exe C:/SLDev/release/indra/build-VS2003/newview/Debug Copying libeay32.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying tntk.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying windbgdlg.exe C:/SLDev/release/indra/build-VS2003/newview/Debug Copying openjpegd.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying xul.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying xpcom.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying ssl3.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying softokn3.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying smime3.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying plds4.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying plc4.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying nssckbi.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying nss3.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying nspr4.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying js3250.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying gksvggdiplus.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Copying freebl3.dll C:/SLDev/release/indra/build-VS2003/newview/Debug Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\newview\copy_win_libs.dir\RelWithDebInfo\BuildLog.htm" copy_win_libs - 0 error(s), 0 warning(s) ------ Build started: Project: llcommon, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llcommon/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... u64.cpp timing.cpp reflective.cpp metaproperty.cpp metaclass.cpp llworkerthread.cpp lluuid.cpp lluri.cpp lltimer.cpp llthread.cpp llsys.cpp llstringtable.cpp llstring.cpp llstreamtools.cpp llstat.cpp llsecondlifeurls.cpp llsdutil.cpp llsdserialize_xml.cpp llsdserialize.cpp llsd.cpp Generating Code... Compiling... llrun.cpp llrand.cpp llqueuedthread.cpp llprocessor.cpp llmortician.cpp llmetrics.cpp llmemorystream.cpp llmemory.cpp llmd5.cpp lllog.cpp lllivefile.cpp llliveappconfig.cpp llindraconfigfile.cpp llheartbeat.cpp llframetimer.cpp llformat.cpp llfixedbuffer.cpp llfindlocale.cpp llfile.cpp llfasttimer.cpp Generating Code... Compiling... llevent.cpp llerrorthread.cpp llerror.cpp lldate.cpp llcriticaldamp.cpp llcrc.cpp llcommon.cpp llbase64.cpp llbase32.cpp llassettype.cpp llapr.cpp llapp.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llcommon\llcommon.dir\RelWithDebInfo\BuildLog.htm" llcommon - 0 error(s), 0 warning(s) ------ Build started: Project: llimage, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llimage/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llpngwrapper.cpp llimageworker.cpp llimagetga.cpp llimagepng.cpp llimagejpeg.cpp llimagej2c.cpp llimagedxt.cpp llimage.cpp llimagebmp.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llimage\llimage.dir\RelWithDebInfo\BuildLog.htm" llimage - 0 error(s), 0 warning(s) ------ Build started: Project: llui, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llui/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llviewquery.cpp llview.cpp llviewborder.cpp llundo.cpp lluistring.cpp lluictrlfactory.cpp lluictrl.cpp llui.cpp lltexteditor.cpp lltextbox.cpp lltabcontainervertical.cpp lltabcontainer.cpp llstyle.cpp llspinctrl.cpp llsliderctrl.cpp llslider.cpp llscrolllistctrl.cpp llscrollingpanellist.cpp llscrollcontainer.cpp llscrollbar.cpp Generating Code... Compiling... llrootview.cpp llresmgr.cpp llresizehandle.cpp llresizebar.cpp llradiogroup.cpp llpanel.cpp llmultisliderctrl.cpp llmultislider.cpp llmodaldialog.cpp llmenugl.cpp lllineeditor.cpp llkeywords.cpp lliconctrl.cpp llfocusmgr.cpp llfloater.cpp lleditmenuhandler.cpp lldraghandle.cpp llctrlselectioninterface.cpp llcombobox.cpp llclipboard.cpp Generating Code... Compiling... llcheckboxctrl.cpp llbutton.cpp llalertdialog.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llui\llui.dir\RelWithDebInfo\BuildLog.htm" llui - 0 error(s), 0 warning(s) ------ Build started: Project: llcrashlogger, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llcrashlogger/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llcrashlogger.cpp Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llcrashlogger\llcrashlogger.dir\RelWithDebInfo\BuildLog.htm" llcrashlogger - 0 error(s), 0 warning(s) ------ Build started: Project: copy_win_scripts, Configuration: RelWithDebInfo Win32 ------ Copying start-client.py C:/SLDev/release/indra/build-VS2003/batch Building Custom Rule C:/SLDev/release/indra/copy_win_scripts/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\copy_win_scripts\copy_win_scripts.dir\RelWithDebInfo\BuildLog.htm" copy_win_scripts - 0 error(s), 0 warning(s) ------ Build started: Project: llimagej2coj, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llimagej2coj/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llimagej2coj.cpp Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llimagej2coj\llimagej2coj.dir\RelWithDebInfo\BuildLog.htm" llimagej2coj - 0 error(s), 0 warning(s) ------ Build started: Project: lscript_library, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/lscript/lscript_library/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... lscript_library.cpp lscript_export.cpp lscript_alloc.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\lscript\lscript_library\lscript_library.dir\RelWithDebInfo\BuildLog.htm" lscript_library - 0 error(s), 0 warning(s) ------ Build started: Project: lscript_execute, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/lscript/lscript_execute/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... lscript_readlso.cpp lscript_heapruntime.cpp lscript_execute.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\lscript\lscript_execute\lscript_execute.dir\RelWithDebInfo\BuildLog.htm" lscript_execute - 0 error(s), 0 warning(s) ------ Build started: Project: lscript_compile, Configuration: RelWithDebInfo Win32 ------ Generating indra.y.cpp, indra.y.hpp C:/SLDev/release/indra/lscript/lscript_compile/indra.y: conflicts: 88 reduce/reduce Generating indra.l.cpp Building Custom Rule C:/SLDev/release/indra/lscript/lscript_compile/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... lscript_typecheck.cpp lscript_tree.cpp lscript_scope.cpp lscript_resource.cpp lscript_heap.cpp lscript_error.cpp lscript_bytecode.cpp lscript_alloc.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\lscript\lscript_compile\lscript_compile.dir\RelWithDebInfo\BuildLog.htm" lscript_compile - 0 error(s), 0 warning(s) ------ Build started: Project: llxml, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llxml/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llxmltree.cpp llxmlparser.cpp llxmlnode.cpp llcontrol.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llxml\llxml.dir\RelWithDebInfo\BuildLog.htm" llxml - 0 error(s), 0 warning(s) ------ Build started: Project: llaudio, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llaudio/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... listener_fmod.cpp audioengine_fmod.cpp vorbisencode.cpp vorbisdecode.cpp llaudiodecodemgr.cpp listener.cpp audioengine.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llaudio\llaudio.dir\RelWithDebInfo\BuildLog.htm" llaudio - 0 error(s), 0 warning(s) ------ Build started: Project: llvfs, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llvfs/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... lldir_win32.cpp llvfsthread.cpp llvfs.cpp llvfile.cpp lllfsthread.cpp lldir.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llvfs\llvfs.dir\RelWithDebInfo\BuildLog.htm" llvfs - 0 error(s), 0 warning(s) ------ Build started: Project: llrender, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llrender/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llgl.cpp llvertexbuffer.cpp llshadermgr.cpp llrendertarget.cpp llrendersphere.cpp llrender.cpp llpostprocess.cpp llimagegl.cpp llglslshader.cpp llgldbg.cpp llfontgl.cpp llfont.cpp llcubemap.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llrender\llrender.dir\RelWithDebInfo\BuildLog.htm" llrender - 0 error(s), 0 warning(s) ------ Build started: Project: llprimitive, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llprimitive/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llvolumexml.cpp llvolumemessage.cpp lltreeparams.cpp lltextureentry.cpp lltextureanim.cpp llprimitive.cpp llmaterialtable.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llprimitive\llprimitive.dir\RelWithDebInfo\BuildLog.htm" llprimitive - 0 error(s), 0 warning(s) ------ Build started: Project: llmessage, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llmessage/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... patch_idct.cpp patch_dct.cpp patch_code.cpp partsyspacket.cpp network.cpp net.cpp message_string_table.cpp message_prehash.cpp message.cpp llxorcipher.cpp llxfer_vfile.cpp llxfer_mem.cpp llxfermanager.cpp llxfer_file.cpp llxfer.cpp lluseroperation.cpp llurlrequest.cpp lltransfertargetvfile.cpp lltransfertargetfile.cpp lltransfersourcefile.cpp Generating Code... Compiling... lltransfersourceasset.cpp lltransfermanager.cpp llthrottle.cpp lltemplatemessagereader.cpp lltemplatemessagebuilder.cpp llservice.cpp llservicebuilder.cpp llsdrpcserver.cpp llsdrpcclient.cpp llsdmessagereader.cpp llsdmessagebuilder.cpp llsdhttpserver.cpp llsdappservices.cpp llpumpio.cpp llpartdata.cpp llpacketring.cpp llpacketbuffer.cpp llpacketack.cpp llnullcipher.cpp llnamevalue.cpp Generating Code... Compiling... llmime.cpp llmessagethrottle.cpp llmessagetemplateparser.cpp llmessagetemplate.cpp llmessagereader.cpp llmessageconfig.cpp llmessagebuilder.cpp llmail.cpp llioutil.cpp lliosocket.cpp lliopipe.cpp lliohttpserver.cpp lliobuffer.cpp llinstantmessage.cpp llhttpsender.cpp llhttpnode.cpp llhttpclient.cpp llhttpassetstorage.cpp llhost.cpp llfiltersd2xmlrpc.cpp Generating Code... Compiling... lldispatcher.cpp lldatapacker.cpp llcurl.cpp llclassifiedflags.cpp llcircuit.cpp llchainio.cpp llcachename.cpp llbufferstream.cpp llbuffer.cpp llblowfishcipher.cpp llassetstorage.cpp llares.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llmessage\llmessage.dir\RelWithDebInfo\BuildLog.htm" llmessage - 0 error(s), 0 warning(s) ------ Build started: Project: llmedia, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llmedia/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llmediaimplquicktime.cpp llmediaimplllmozlib.cpp llmediamanager.cpp llmediaimplfactory.cpp llmediaimplexample2.cpp llmediaimplexample1.cpp llmediaimplcommon.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llmedia\llmedia.dir\RelWithDebInfo\BuildLog.htm" llmedia - 0 error(s), 0 warning(s) ------ Build started: Project: llmath, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llmath/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... xform.cpp v4math.cpp v4coloru.cpp v4color.cpp v3math.cpp v3dmath.cpp v3color.cpp v2math.cpp raytrace.cpp m4math.cpp m3math.cpp llsdutil_math.cpp llvolumemgr.cpp llvolume.cpp llsphere.cpp llrect.cpp llquaternion.cpp llperlin.cpp llline.cpp llcoordframe.cpp Generating Code... Compiling... llcamera.cpp llbboxlocal.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llmath\llmath.dir\RelWithDebInfo\BuildLog.htm" llmath - 0 error(s), 0 warning(s) ------ Build started: Project: llinventory, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/llinventory/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... lluserrelations.cpp lltransactionflags.cpp llsaleinfo.cpp llpermissions.cpp llparcel.cpp llnotecard.cpp lllandmark.cpp llinventorytype.cpp llinventory.cpp lleconomy.cpp llcategory.cpp Generating Code... Creating library... Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\llinventory\llinventory.dir\RelWithDebInfo\BuildLog.htm" llinventory - 0 error(s), 0 warning(s) ------ Build started: Project: windows-crash-logger, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/win_crash_logger/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... llcrashloggerwindows.cpp win_crash_logger.cpp Generating Code... Linking... LINK : LNK6004: C:\SLDev\release\indra\build-VS2003\win_crash_logger\RelWithDebInfo\windows-crash-logger.exe not found or not built by the last incremental link; performing full link Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\win_crash_logger\windows-crash-logger.dir\RelWithDebInfo\BuildLog.htm" windows-crash-logger - 0 error(s), 0 warning(s) ------ Build started: Project: windows-updater, Configuration: RelWithDebInfo Win32 ------ Building Custom Rule C:/SLDev/release/indra/win_updater/CMakeLists.txt CMake does not need to re-run because CMakeFiles/generate.stamp is up-to-date. Compiling... updater.cpp Linking... LINK : LNK6004: C:\SLDev\release\indra\build-VS2003\win_updater\RelWithDebInfo\windows-updater.exe not found or not built by the last incremental link; performing full link Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\win_updater\windows-updater.dir\RelWithDebInfo\BuildLog.htm" windows-updater - 0 error(s), 0 warning(s) ------ Build started: Project: secondlife-bin, Configuration: RelWithDebInfo Win32 ------ Setting the secondlife-bin working directory for debugging. Editing solution: C:/SLDev/release/indra/build-VS2003/SecondLife.sln Looking for existing VisualStudio instance... Looking for project secondlife-bin... Found project: secondlife-bin Setting working directory C:\SLDev\release\indra\build-VS2003\newview\secondlife-bin.vcproj Compiling... llviewerprecompiledheaders.cpp Compiling... llwindebug.cpp llappviewerwin32.cpp pipeline.cpp noise.cpp llxmlrpctransaction.cpp llworldmapview.cpp llworldmap.cpp llworld.cpp llwlparamset.cpp llwlparammanager.cpp llwldaycycle.cpp llwlanimator.cpp llwind.cpp llwebbrowserctrl.cpp llweb.cpp llwearablelist.cpp llwearable.cpp llwaterparamset.cpp llwaterparammanager.cpp llwatchdog.cpp Generating Code... Compiling... llvowlsky.cpp llvowater.cpp llvovolume.cpp llvotree.cpp llvotextbubble.cpp llvosurfacepatch.cpp llvosky.cpp llvopartgroup.cpp llvoinventorylistener.cpp llvoicevisualizer.cpp llvoiceremotectrl.cpp llvoiceclient.cpp llvoground.cpp llvograss.cpp llvoclouds.cpp llvocache.cpp llvoavatar.cpp llvlmanager.cpp llvlcomposition.cpp llviewerwindow.cpp Generating Code... Compiling... llviewervisualparam.cpp llviewerthrottle.cpp llviewertextureanim.cpp llviewertexteditor.cpp llviewerstats.cpp llviewershadermgr.cpp llviewerregion.cpp llviewerpartsource.cpp llviewerpartsim.cpp llviewerparceloverlay.cpp llviewerparcelmgr.cpp llviewerparcelmediaautoplay.cpp llviewerparcelmedia.cpp llviewerobjectlist.cpp llviewerobject.cpp llviewernetwork.cpp llviewermessage.cpp llviewermenufile.cpp llviewermenu.cpp llviewermedia.cpp Generating Code... Compiling... llviewerlayer.cpp llviewerkeyboard.cpp llviewerjoystick.cpp llviewerjointmesh_vec.cpp llviewerjointmesh_sse.cpp llviewerjointmesh_sse2.cpp llviewerjointmesh.cpp llviewerjoint.cpp llviewerjointattachment.cpp llviewerinventory.cpp llviewerimagelist.cpp llviewerimage.cpp llviewergesture.cpp llviewergenericmessage.cpp llviewerdisplay.cpp llviewercontrol.cpp llviewercamera.cpp llvieweraudio.cpp llviewerassetstorage.cpp llviewchildren.cpp Generating Code... Compiling... llvelocitybar.cpp llvectorperfoptions.cpp lluserauth.cpp llurlwhitelist.cpp llurlsimstring.cpp llurlhistory.cpp llurldispatcher.cpp llurl.cpp lluploaddialog.cpp lltrans.cpp lltracker.cpp lltoolview.cpp lltoolselectrect.cpp lltoolselectland.cpp lltoolselect.cpp lltoolplacer.cpp lltoolpipette.cpp lltoolpie.cpp lltoolobjpicker.cpp lltoolmorph.cpp Generating Code... Compiling... lltoolmgr.cpp lltoolindividual.cpp lltoolgun.cpp lltoolgrab.cpp lltoolfocus.cpp lltoolface.cpp lltooldraganddrop.cpp lltool.cpp lltoolcomp.cpp lltoolbrush.cpp lltoolbar.cpp lltextureview.cpp lltexturefetch.cpp lltexturectrl.cpp lltexturecache.cpp lltexlayer.cpp llsurfacepatch.cpp llsurface.cpp llstylemap.cpp llstatview.cpp Generating Code... Compiling... llstatusbar.cpp llstatgraph.cpp llstatbar.cpp llsrv.cpp llsprite.cpp llspatialpartition.cpp llsky.cpp llselectmgr.cpp llsavedsettingsglue.cpp llremoteparcelrequest.cpp llregionposition.cpp llprogressview.cpp llpreviewtexture.cpp llpreviewsound.cpp llpreviewscript.cpp llpreviewnotecard.cpp llpreviewlandmark.cpp llpreviewgesture.cpp llpreview.cpp llpreviewanim.cpp Generating Code... Compiling... llprefsvoice.cpp llprefsim.cpp llprefschat.cpp llpolymorph.cpp llpolymesh.cpp llpatchvertexarray.cpp llparcelselection.cpp llpanelweb.cpp llpanelvolume.cpp llpanelplace.cpp llpanelpick.cpp llpanelpermissions.cpp llpanelobject.cpp llpanelnetwork.cpp llpanelmsgs.cpp llpanelmorph.cpp llpanellogin.cpp llpanellandoptions.cpp llpanellandobjects.cpp llpanellandmedia.cpp Generating Code... Compiling... llpanelland.cpp llpanelinventory.cpp llpanelinput.cpp llpanelgroupvoting.cpp llpanelgrouproles.cpp llpanelgroupnotices.cpp llpanelgrouplandmoney.cpp llpanelgroupinvite.cpp llpanelgroupgeneral.cpp llpanelgroup.cpp llpanelgeneral.cpp llpanelface.cpp llpanelevent.cpp llpaneldisplay.cpp llpaneldirpopular.cpp llpaneldirplaces.cpp llpaneldirpeople.cpp llpaneldirland.cpp llpaneldirgroups.cpp llpaneldirfind.cpp Generating Code... Compiling... llpaneldirevents.cpp llpaneldirclassified.cpp llpaneldirbrowser.cpp llpaneldebug.cpp llpanelcontents.cpp llpanelclassified.cpp llpanelavatar.cpp llpanelaudiovolume.cpp llpanelaudioprefs.cpp lloverlaybar.cpp llnotify.cpp llnetmap.cpp llnamelistctrl.cpp llnameeditor.cpp llnamebox.cpp llmutelist.cpp llmoveview.cpp llmorphview.cpp llmimetypes.cpp llmenucommands.cpp Generating Code... Compiling... llmemoryview.cpp llmediaremotectrl.cpp llmapresponders.cpp llmaniptranslate.cpp llmanipscale.cpp llmaniprotate.cpp llmanip.cpp lllogchat.cpp lllandmarklist.cpp lljoystickbutton.cpp llinventoryview.cpp llinventorymodel.cpp llinventoryclipboard.cpp llinventorybridge.cpp llinventoryactions.cpp llimview.cpp llimpanel.cpp llhudview.cpp llhudtext.cpp llhudrender.cpp Generating Code... Compiling... llhudobject.cpp llhudmanager.cpp llhudicon.cpp llhudeffecttrail.cpp llhudeffectpointat.cpp llhudeffectlookat.cpp llhudeffect.cpp llhudeffectbeam.cpp llhoverview.cpp llgroupnotify.cpp llgroupmgr.cpp llglsandbox.cpp llgivemoney.cpp llgesturemgr.cpp llgenepool.cpp llframestatview.cpp llframestats.cpp llfollowcam.cpp llfolderview.cpp llfloaterworldmap.cpp Generating Code... Compiling... llfloaterwindlight.cpp llfloaterwater.cpp llfloatervoicedevicesettings.cpp llfloaterurlentry.cpp llfloaterurldisplay.cpp llfloatertos.cpp llfloatertopobjects.cpp llfloatertools.cpp llfloatertest.cpp llfloatertelehub.cpp llfloaterstats.cpp llfloatersnapshot.cpp llfloatersettingsdebug.cpp llfloatersellland.cpp llfloaterscriptdebug.cpp llfloaterreporter.cpp llfloaterreleasemsg.cpp llfloaterregioninfo.cpp llfloaterproperties.cpp llfloaterpreference.cpp Generating Code... Compiling... llfloaterpostprocess.cpp llfloaterpostcard.cpp llfloaterpermissionsmgr.cpp llfloaterparcel.cpp llfloateropenobject.cpp llfloaternewim.cpp llfloaternamedesc.cpp llfloatermute.cpp llfloatermap.cpp llfloaterlandmark.cpp llfloaterlandholdings.cpp llfloaterland.cpp llfloaterlagmeter.cpp llfloaterjoystick.cpp llfloaterinspect.cpp llfloaterimagepreview.cpp llfloaterhud.cpp llfloaterhtmlhelp.cpp llfloaterhtml.cpp llfloaterhardwaresettings.cpp Generating Code... Compiling... llfloatergroups.cpp llfloatergroupinvite.cpp llfloatergroupinfo.cpp llfloatergodtools.cpp llfloatergesture.cpp llfloaterfriends.cpp llfloaterevent.cpp llfloaterenvsettings.cpp llfloatereditui.cpp llfloaterdirectory.cpp llfloaterdaycycle.cpp llfloatercustomize.cpp llfloatercolorpicker.cpp llfloaterclothing.cpp llfloaterclassified.cpp llfloaterchatterbox.cpp llfloaterchat.cpp llfloatercamera.cpp llfloaterbuyland.cpp llfloaterbuycurrency.cpp Generating Code... Compiling... llfloaterbuy.cpp llfloaterbuycontents.cpp llfloaterbump.cpp llfloaterbuildoptions.cpp llfloateravatartextures.cpp llfloateravatarpicker.cpp llfloateravatarinfo.cpp llfloaterauction.cpp llfloateranimpreview.cpp llfloateractivespeakers.cpp llfloaterabout.cpp llflexibleobject.cpp llfirstuse.cpp llfilepicker.cpp llfeaturemanager.cpp llfasttimerview.cpp llface.cpp lleventpoll.cpp lleventnotifier.cpp lleventinfo.cpp Generating Code... Compiling... llemote.cpp lldynamictexture.cpp lldriverparam.cpp lldrawpoolwlsky.cpp lldrawpoolwater.cpp lldrawpooltree.cpp lldrawpoolterrain.cpp lldrawpoolsky.cpp lldrawpoolsimple.cpp lldrawpoolground.cpp lldrawpool.cpp lldrawpoolbump.cpp lldrawpoolavatar.cpp lldrawpoolalpha.cpp lldrawable.cpp lldirpicker.cpp lldelayedgestureerror.cpp lldebugview.cpp lldebugmessagebox.cpp llcylinder.cpp Generating Code... Compiling... llcurrencyuimanager.cpp llcontainerview.cpp llconsole.cpp llconfirmationmanager.cpp llcompilequeue.cpp llcompass.cpp llcommandlineparser.cpp llcommandhandler.cpp llcolorswatch.cpp llcolorscheme.cpp llcloud.cpp llclassifiedstatsresponder.cpp llclassifiedinfo.cpp llchatbar.cpp llcaphttpsender.cpp llcallingcard.cpp llcallbacklist.cpp llbox.cpp llbbox.cpp llaudiosourcevo.cpp Generating Code... Compiling... llassetuploadresponders.cpp llappviewer.cpp llanimstatelabels.cpp llagentpilot.cpp llagentlanguage.cpp llagentdata.cpp llagent.cpp Generating Code... Compiling... llstartup.cpp Compiling resources... Verifying message template master: http://secondlife.com/app/message_template/master_message_template.msg current: C:\SLDev\release\scripts\messages\message_template.msg --- PASS --- Same Linking... llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(class std::basic_string,class std::allocator > const &,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) C:\SLDev\release\indra\build-VS2003\newview\RelWithDebInfo\secondlife-bin.exe : fatal error LNK1120: 1 unresolved externals Build log was saved at "file://c:\SLDev\release\indra\build-VS2003\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" secondlife-bin - 3 error(s), 0 warning(s) ------ Skipped Build: Project: ALL_BUILD, Configuration: RelWithDebInfo Win32 ------ Project configuration skipped because it is not selected in this solution configuration ------ Skipped Build: Project: viewer, Configuration: RelWithDebInfo Win32 ------ Project configuration skipped because it is not selected in this solution configuration ---------------------- Done ---------------------- Build: 23 succeeded, 1 failed, 2 skipped -------------- next part -------------- Setting environment for using Microsoft Visual Studio .NET 2003 tools. (If you have another version of Visual Studio or Visual C++ installed and wish to use its tools from the command line, run vcvars32.bat for that version.) C:\Documents and Settings\alexandra>cd \sldev\release\indra C:\SLDev\release\indra>develop.py -G VS2003 configure Running 'cmake -G "Visual Studio 7 .NET 2003" -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" "C:\\SLDev\\release\\indra"' in 'build-VS2003' -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\ogg-vorbis-1.03-1.1.2-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\ogg-vorbis-1.03-1.1.2-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml -- Building with FMOD audio support Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\apr_suite-1.2.8-windows-20080618.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\apr_suite-1.2.8-windows-20080618.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\boost-1.32.0-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\boost-1.32.0-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\expat-1.95.8-windows-20080617.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\expat-1.95.8-windows-20080617.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\zlib-1.1.4-windows-20080618.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\zlib-1.1.4-windows-20080618.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\ares-1.3.0-windows-20080618.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\ares-1.3.0-windows-20080618.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\curl-7.16.0-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\curl-7.16.0-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\openSSL-0.9.7c-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\openSSL-0.9.7c-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\xmlrpc-epi-0.51-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\xmlrpc-epi-0.51-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\jpeglib-6b-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\jpeglib-6b-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\libpng-1.2.18-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\libpng-1.2.18-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\openjpeg-1.2-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\openjpeg-1.2-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\GL-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\GL-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\glh_linear-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\glh_linear-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\SDL-1.2.5-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\SDL-1.2.5-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\mesa-7.0-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\mesa-7.0-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\llmozlib-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\llmozlib-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\freetype-2.1.5-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\freetype-2.1.5-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\gtk-atk-pango-glib-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\gtk-atk-pango-glib-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml -- Building with FMOD audio support Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\ndofdev-windows-20080618.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\ndofdev-windows-20080618.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml Found matching package: c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\vivox-windows-20080613.tar.bz2 Extracting c:\docume~1\alexan~1\locals~1\temp\install.cache.alexandra\vivox-windows-20080613.tar.bz2 to C:\SLDev\release Writing state to C:\SLDev\release\installed.xml -- Version of viewer is 1.20.11.0 -- Configuring done CMake Warning (dev) at win_crash_logger/CMakeLists.txt:45 (add_executable): Policy CMP0003 should be set before this line. Add code such as if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) as early as possible but after the most recent call to cmake_minimum_required or cmake_policy(VERSION). This warning appears because target "windows-crash-logger" links to some libraries for which the linker must search: libexpatMT, libcurld, areslib, ssleay32, libeay32, xmlrpcepi, libexpatMT libcurld, areslib, ssleay32, libeay32, xmlrpcepi, zlib, ws2_32, mswsock psapi, winmm, netapi32, libcurld, areslib, ssleay32, libeay32, xmlrpcepi libexpatMT, zlib, ws2_32, mswsock, psapi, winmm, netapi32 and other libraries with known full path: C:/SLDev/release/indra/build-VS2003/llcrashlogger/Debug/llcrashlogger.lib C:/SLDev/release/indra/build-VS2003/llwindow/Debug/llwindow.lib C:/SLDev/release/indra/build-VS2003/llvfs/Debug/llvfs.lib C:/SLDev/release/indra/build-VS2003/llxml/Debug/llxml.lib C:/SLDev/release/indra/../libraries/i686-win32/lib/debug/aprutil-1.lib C:/SLDev/release/indra/build-VS2003/llmessage/Debug/llmessage.lib C:/SLDev/release/indra/build-VS2003/llmath/Debug/llmath.lib C:/SLDev/release/indra/build-VS2003/llcommon/Debug/llcommon.lib C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Lib/dxguid.lib CMake is adding directories in the second list to the linker search path in case they are needed to find libraries from the first list (for backwards compatibility with CMake 2.4). Set policy CMP0003 to OLD or NEW to enable or disable this behavior explicitly. Run "cmake --help-policy CMP0003" for more information. This warning is for project developers. Use -Wno-dev to suppress it. WARNING: Cannot generate a safe linker search path for target secondlife-bin because there is a cycle in the constraint graph: dir 0 is [C:/SLDev/release/indra/../libraries/i686-win32/lib] dir 1 is [C:/SLDev/release/indra/build-VS2003/llaudio/Debug] dir 2 is [C:/SLDev/release/indra/build-VS2003/llcharacter/Debug] dir 3 is [C:/SLDev/release/indra/build-VS2003/llimage/Debug] dir 4 is [C:/SLDev/release/indra/build-VS2003/llimagej2coj/Debug] dir 5 is [C:/SLDev/release/indra/build-VS2003/llinventory/Debug] dir 6 is [C:/SLDev/release/indra/build-VS2003/llmedia/Debug] dir 7 is [C:/SLDev/release/libraries/i686-win32/lib/release] dir 8 must precede it due to link library [aprutil-1.lib] dir 8 is [C:/SLDev/release/indra/../libraries/i686-win32/lib/debug] dir 7 must precede it due to link library [QTMLClient.lib] dir 9 is [C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/PlatformSDK/Lib] dir 10 is [C:/SLDev/release/indra/build-VS2003/llmessage/Debug] dir 11 is [C:/SLDev/release/indra/build-VS2003/llprimitive/Debug] dir 12 is [C:/SLDev/release/indra/build-VS2003/llrender/Debug] dir 13 is [C:/SLDev/release/indra/build-VS2003/llui/Debug] dir 14 is [C:/SLDev/release/indra/build-VS2003/llvfs/Debug] dir 15 is [C:/SLDev/release/indra/build-VS2003/llwindow/Debug] dir 16 is [C:/SLDev/release/indra/build-VS2003/llxml/Debug] dir 17 is [C:/SLDev/release/indra/build-VS2003/lscript/lscript_compile/Debug] dir 18 is [C:/SLDev/release/indra/build-VS2003/lscript/lscript_execute/Debug] dir 19 is [C:/SLDev/release/indra/build-VS2003/lscript/lscript_library/Debug] dir 20 is [C:/SLDev/release/indra/build-VS2003/llmath/Debug] dir 21 is [C:/SLDev/release/indra/build-VS2003/llcommon/Debug] -- Generating done -- Build files have been written to: C:/SLDev/release/indra/build-VS2003 Running 'tools\\vstool\\VSTool.exe --solution build-VS2003\\SecondLife.sln --config RelWithDebInfo --startup secondlife-bin' in 'C:\\SLDev\\release\\indra' Editing solution: build-VS2003\SecondLife.sln Looking for existing VisualStudio instance... Didn't find open solution, starting new background VisualStudio instance... Reading .sln file version... Using version: VC71... Reading solution: "C:\SLDev\release\indra\build-VS2003\SecondLife.sln" Trying to set active config to "RelWithDebInfo" Success! Trying to set "secondlife-bin" to the startup project Success! C:\SLDev\release\indra> From soft at lindenlab.com Fri Jul 18 05:13:12 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 05:13:15 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: <-8304386138781750816@unknownmsgid> References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> Message-ID: On Fri, Jul 18, 2008 at 5:53 AM, Suzhanna Rossini wrote: >> > >> >> I also get this error when trying at a friend who has VS2003.. >> >> We tried with svn release 772.. >> >> Here're the error messages produced at link time: >> >> >> >> Linking... >> >> llcompilequeue.obj : error LNK2019: unresolved external symbol "int >> >> __cdecl >> >> lscript_compile(char const *,char const *,char const *,int)" >> >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: >> void >> >> __thiscall LLFloaterCompileQueue::compile(class >> >> std::basic_string,class >> >> std::allocator > const &,class LLUUID const &)" >> >> >> >> >> >> llpreviewscript.obj : error LNK2001: unresolved external symbol "int >> >> __cdecl >> >> lscript_compile(char const *,char const *,char const *,int)" >> >> (?lscript_compile@@YAHPBD00H@Z) >> >> Aimee, Suzhanna - Would you please walk through the steps you're using >> to unpack and build? It's possible there's a bogus step in our >> instructions that wants fixing. > > Absolutely.. ;-) > > 1. Check out a clean copy of http://svn.secondlife.com/svn/linden/release > (now I got r798). > > 2. Download and unzip the art/lib packages mentioned in > release\doc\asset_urls.txt (slviewer-artwork-release-r92064.zip and > slviewer-win32-libs-release-r92064.zip) > > 3. Copy in fmod, GL, llkdu.dll and QuickTime libs etc. > > 4. Open a Visual Studio .NET 2003 Command Prompt. > > 5. CD into the .\release\indra directory and run "develop.py -G VS2003 > configure" (result, see attached "config_steps.txt") > > 6. Open indra\build-VS2003\SecondLife.sln in VS2003 > > 7. Hit ctrl-shift-b to start the build. > > 8. Establish the fact that is still gives the errors.. (See buildlog.txt) I don't see anything wrong with the steps you're taking. The GL copy is unnecessary after 1.19 or so, and QuickTime should be found automatically if you've installed the SDK under Program Files, but they shouldn't hurt here. I'm assuming you've installed cygwin and added it to Visual Studio's binary search path, and you haven't provided some other flex and bison. Do me a favor and check 'flex --version' and 'bison --version' in cygwin. Mine are at flex 2.5.35 and bison 2.3. From suzhanna.rossini at balsaestates.com Fri Jul 18 05:17:18 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 05:17:28 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> Message-ID: <002f01c8e8d0$39009440$ab01bcc0$@rossini@balsaestates.com> > On Fri, Jul 18, 2008 at 5:53 AM, Suzhanna Rossini > wrote: > >> > > >> >> I also get this error when trying at a friend who has VS2003.. > >> >> We tried with svn release 772.. > >> >> Here're the error messages produced at link time: > >> >> > >> >> Linking... > >> >> llcompilequeue.obj : error LNK2019: unresolved external symbol > "int > >> >> __cdecl > >> >> lscript_compile(char const *,char const *,char const *,int)" > >> >> (?lscript_compile@@YAHPBD00H@Z) referenced in function > "protected: > >> void > >> >> __thiscall LLFloaterCompileQueue::compile(class > >> >> std::basic_string,class > >> >> std::allocator > const &,class LLUUID const &)" > >> >> > >> >> > >> >> llpreviewscript.obj : error LNK2001: unresolved external symbol > "int > >> >> __cdecl > >> >> lscript_compile(char const *,char const *,char const *,int)" > >> >> (?lscript_compile@@YAHPBD00H@Z) > >> > >> Aimee, Suzhanna - Would you please walk through the steps you're > using > >> to unpack and build? It's possible there's a bogus step in our > >> instructions that wants fixing. > > > > Absolutely.. ;-) > > > > 1. Check out a clean copy of > http://svn.secondlife.com/svn/linden/release > > (now I got r798). > > > > 2. Download and unzip the art/lib packages mentioned in > > release\doc\asset_urls.txt (slviewer-artwork-release-r92064.zip and > > slviewer-win32-libs-release-r92064.zip) > > > > 3. Copy in fmod, GL, llkdu.dll and QuickTime libs etc. > > > > 4. Open a Visual Studio .NET 2003 Command Prompt. > > > > 5. CD into the .\release\indra directory and run "develop.py -G > VS2003 > > configure" (result, see attached "config_steps.txt") > > > > 6. Open indra\build-VS2003\SecondLife.sln in VS2003 > > > > 7. Hit ctrl-shift-b to start the build. > > > > 8. Establish the fact that is still gives the errors.. (See > buildlog.txt) > > I don't see anything wrong with the steps you're taking. The GL copy > is unnecessary after 1.19 or so, and QuickTime should be found > automatically if you've installed the SDK under Program Files, but > they shouldn't hurt here. > > I'm assuming you've installed cygwin and added it to Visual Studio's > binary search path, and you haven't provided some other flex and > bison. Do me a favor and check 'flex --version' and 'bison --version' > in cygwin. Mine are at flex 2.5.35 and bison 2.3. Yes, paths are added both in Windows and in VS specifically. And my versions are the same as you have, I ran a cygwin update last week, and never fiddle manually with it... (I've learned that the hard way...) Alexandra. From soft at lindenlab.com Fri Jul 18 05:26:20 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 05:26:22 2008 Subject: [sldev] Decoupling UI widget set from rest of viewer (Re: Qt forthe viewer) In-Reply-To: <136D1B7B-016F-481D-87B2-62EBBC397AA1@gmail.com> References: <487D1169.4090704@lindenlab.com> <1ds4dsdds4kYbebaerb6Pwwk.alissa_sabre@yahoo.co.jp> <136D1B7B-016F-481D-87B2-62EBBC397AA1@gmail.com> Message-ID: On Fri, Jul 18, 2008 at 5:18 AM, Argent Stonecutter wrote: > Are you guys sure Qt is native on Mac OS? I think it's still X11-based. Sure enough. Cocoa Qt is still alpha. http://trolltech.com/company/newsroom/announcements/press.2008-06-09.7117549806 From kfa at gmx.net Fri Jul 18 05:51:46 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Jul 18 05:51:52 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> Message-ID: <488091E2.3040308@gmx.net> Karl Stiefvater wrote: > ok - but i still feel like this falls under the category of > "convenience" and not "efficiency", right? > > all the rotate buys you is a quick fix for when your sculpt exporter > isn't smart enough to generate the right map. i'd argue that you merely > fix the exporter, and leave the low-level interface as minimal as possible. > > K. Well, one could also argue that it saves the uploader 10L and the downloading client a handful bytes if you wanted to use both versions with only one texture, e.g. in objects with mirrored parts. Seems like a small matter at first sight, but maybe someone could come up with some perspicuous use cases. Felix :) > > On Jul 16, 2008, at 6:08 PM, Strife Onizuka wrote: > >> I seem not have been understood by anyone. Time for a second crack at it. >> >> It has to do with the stitching for cylinder and sphere types. On the >> cylinder it stitches the left to the right, and on the sphere it also >> pinches the top and bottom edges. What I'm advocating is a way to have >> it instead stitch the top and bottom to each other, and do the pinch >> on the left and right. For the other two sculpty types it doesn't >> matter if they are rotated because the edges are all handled the same. >> There are two ways of dealing with this, either implement a ROTATE >> flag or add new sculpty types that have that stitching, the results >> will be the same. >> >> Strife >> >> On Tue, Jul 15, 2008 at 11:54 PM, wrote: >>>> A PRIM_SCULPT_FLAG_ROTATE flag is a really good idea, that or >>>> PRIM_SCULPT_TYPE_SPHERE_OTHER and PRIM_SCULPT_TYPE_CYLINDER_OTHER. >>>> >>>> Strife >>>> >>> >>> Pardon my naivete (I'm not an expert on sculpties at all) but ... how is >>> rotating a sculpt texture different from rotating the actual prim? >>> >>> - Kelly >>> >>> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From suzhanna.rossini at balsaestates.com Fri Jul 18 06:02:01 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 06:02:21 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> Message-ID: <003b01c8e8d6$7994cf20$6cbe6d60$@rossini@balsaestates.com> > On Fri, Jul 18, 2008 at 5:53 AM, Suzhanna Rossini > wrote: > >> > > >> >> I also get this error when trying at a friend who has VS2003.. > >> >> We tried with svn release 772.. > >> >> Here're the error messages produced at link time: > >> >> > >> >> Linking... > >> >> llcompilequeue.obj : error LNK2019: unresolved external symbol > "int > >> >> __cdecl > >> >> lscript_compile(char const *,char const *,char const *,int)" > >> >> (?lscript_compile@@YAHPBD00H@Z) referenced in function > "protected: > >> void > >> >> __thiscall LLFloaterCompileQueue::compile(class > >> >> std::basic_string,class > >> >> std::allocator > const &,class LLUUID const &)" > >> >> > >> >> > >> >> llpreviewscript.obj : error LNK2001: unresolved external symbol > "int > >> >> __cdecl > >> >> lscript_compile(char const *,char const *,char const *,int)" > >> >> (?lscript_compile@@YAHPBD00H@Z) > >> > >> Aimee, Suzhanna - Would you please walk through the steps you're > using > >> to unpack and build? It's possible there's a bogus step in our > >> instructions that wants fixing. > > > > Absolutely.. ;-) > > > > 1. Check out a clean copy of > http://svn.secondlife.com/svn/linden/release > > (now I got r798). > > > > 2. Download and unzip the art/lib packages mentioned in > > release\doc\asset_urls.txt (slviewer-artwork-release-r92064.zip and > > slviewer-win32-libs-release-r92064.zip) > > > > 3. Copy in fmod, GL, llkdu.dll and QuickTime libs etc. > > > > 4. Open a Visual Studio .NET 2003 Command Prompt. > > > > 5. CD into the .\release\indra directory and run "develop.py -G > VS2003 > > configure" (result, see attached "config_steps.txt") > > > > 6. Open indra\build-VS2003\SecondLife.sln in VS2003 > > > > 7. Hit ctrl-shift-b to start the build. > > > > 8. Establish the fact that is still gives the errors.. (See > buildlog.txt) > > I don't see anything wrong with the steps you're taking. The GL copy > is unnecessary after 1.19 or so, and QuickTime should be found > automatically if you've installed the SDK under Program Files, but > they shouldn't hurt here. > > I'm assuming you've installed cygwin and added it to Visual Studio's > binary search path, and you haven't provided some other flex and > bison. Do me a favor and check 'flex --version' and 'bison --version' > in cygwin. Mine are at flex 2.5.35 and bison 2.3. Coming to think of it.. Would there be any point for me to install VS2005? I can use my friends license since he's moved completely to VS2008 and only keeps VS2003 for special occasions. The only package I have myself is VS2008, and that seems to be a lot more "unsafe" judging from discussions here and elsewhere. I also came to think of llkdu.dll, it seems like that isn't copied to the right place by unpacking the libraries and pulling the SVN sources.. Neither does it seem to be built in the process, if I don't copy it manually, I get a copy error from the VS2003 solution. /Alexandra From soft at lindenlab.com Fri Jul 18 06:19:36 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 06:19:39 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: <-150151222741468767@unknownmsgid> References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> Message-ID: On Fri, Jul 18, 2008 at 8:02 AM, Suzhanna Rossini wrote: >> On Fri, Jul 18, 2008 at 5:53 AM, Suzhanna Rossini >> wrote: >> >> > >> >> >> I also get this error when trying at a friend who has VS2003.. >> >> >> We tried with svn release 772.. >> >> >> Here're the error messages produced at link time: >> >> >> >> >> >> Linking... >> >> >> llcompilequeue.obj : error LNK2019: unresolved external symbol >> "int >> >> >> __cdecl >> >> >> lscript_compile(char const *,char const *,char const *,int)" >> >> >> (?lscript_compile@@YAHPBD00H@Z) referenced in function >> "protected: >> >> void >> >> >> __thiscall LLFloaterCompileQueue::compile(class >> >> >> std::basic_string,class >> >> >> std::allocator > const &,class LLUUID const &)" >> >> >> >> >> >> >> >> >> llpreviewscript.obj : error LNK2001: unresolved external symbol >> "int >> >> >> __cdecl >> >> >> lscript_compile(char const *,char const *,char const *,int)" >> >> >> (?lscript_compile@@YAHPBD00H@Z) >> >> >> >> Aimee, Suzhanna - Would you please walk through the steps you're >> using >> >> to unpack and build? It's possible there's a bogus step in our >> >> instructions that wants fixing. >> > >> > Absolutely.. ;-) >> > >> > 1. Check out a clean copy of >> http://svn.secondlife.com/svn/linden/release >> > (now I got r798). >> > >> > 2. Download and unzip the art/lib packages mentioned in >> > release\doc\asset_urls.txt (slviewer-artwork-release-r92064.zip and >> > slviewer-win32-libs-release-r92064.zip) >> > >> > 3. Copy in fmod, GL, llkdu.dll and QuickTime libs etc. >> > >> > 4. Open a Visual Studio .NET 2003 Command Prompt. >> > >> > 5. CD into the .\release\indra directory and run "develop.py -G >> VS2003 >> > configure" (result, see attached "config_steps.txt") >> > >> > 6. Open indra\build-VS2003\SecondLife.sln in VS2003 >> > >> > 7. Hit ctrl-shift-b to start the build. >> > >> > 8. Establish the fact that is still gives the errors.. (See >> buildlog.txt) >> >> I don't see anything wrong with the steps you're taking. The GL copy >> is unnecessary after 1.19 or so, and QuickTime should be found >> automatically if you've installed the SDK under Program Files, but >> they shouldn't hurt here. >> >> I'm assuming you've installed cygwin and added it to Visual Studio's >> binary search path, and you haven't provided some other flex and >> bison. Do me a favor and check 'flex --version' and 'bison --version' >> in cygwin. Mine are at flex 2.5.35 and bison 2.3. > > > Coming to think of it.. Would there be any point for me to install VS2005? I > can use my friends license since he's moved completely to VS2008 and only > keeps VS2003 for special occasions. > The only package I have myself is VS2008, and that seems to be a lot more > "unsafe" judging from discussions here and elsewhere. > > I also came to think of llkdu.dll, it seems like that isn't copied to the > right place by unpacking the libraries and pulling the SVN sources.. Neither > does it seem to be built in the process, if I don't copy it manually, I get > a copy error from the VS2003 solution. I don't think switching to VS2005 will make a difference. I just finished a VS2003 build and I don't have the problem there either. I also ran a cygwin setup update to ensure that nothing bad had crept into cygwin recently. The function that your linker isn't finding is in lex_yy.cpp. Try adding an "#error I got here" before this function in lex_yy.cpp, just to rule out some preprocessor difference that's making the code unreachable. It's possible you're inheriting a strange #define from somewhere: BOOL lscript_compile(const char* src_filename, const char* dst_filename, const char* err_filename, BOOL is_god_like) Regarding llkdu - that's currently provided for release candidate builds only. There are still some sticky issues attached to that. For the time being, you can remove the three llkdu rules from copy_win_libs and the viewer will use openjpeg if llkdu isn't present. Again though, this should have nothing to do with your link error. From suzhanna.rossini at balsaestates.com Fri Jul 18 06:32:15 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 06:32:34 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> Message-ID: <005901c8e8da$b2273e50$1675baf0$@rossini@balsaestates.com> [snip] > > > > Coming to think of it.. Would there be any point for me to install > VS2005? I > > can use my friends license since he's moved completely to VS2008 and > only > > keeps VS2003 for special occasions. > > The only package I have myself is VS2008, and that seems to be a lot > more > > "unsafe" judging from discussions here and elsewhere. > > > > I also came to think of llkdu.dll, it seems like that isn't copied to > the > > right place by unpacking the libraries and pulling the SVN sources.. > Neither > > does it seem to be built in the process, if I don't copy it manually, > I get > > a copy error from the VS2003 solution. > > I don't think switching to VS2005 will make a difference. I just > finished a VS2003 build and I don't have the problem there either. I > also ran a cygwin setup update to ensure that nothing bad had crept > into cygwin recently. > > The function that your linker isn't finding is in lex_yy.cpp. Try > adding an "#error I got here" before this function in lex_yy.cpp, just > to rule out some preprocessor difference that's making the code > unreachable. It's possible you're inheriting a strange #define from > somewhere: > > BOOL lscript_compile(const char* src_filename, const char* > dst_filename, > const char* > err_filename, BOOL is_god_like) > > > Regarding llkdu - that's currently provided for release candidate > builds only. There are still some sticky issues attached to that. For > the time being, you can remove the three llkdu rules from > copy_win_libs and the viewer will use openjpeg if llkdu isn't present. > Again though, this should have nothing to do with your link error. Uh oh... I don't even have a file lex_yy.cpp on disk! From suzhanna.rossini at balsaestates.com Fri Jul 18 06:47:48 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 06:48:18 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: <005901c8e8da$b2273e50$1675baf0$@rossini@balsaestates.com> References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> <005901c8e8da$b2273e50$1675baf0$@rossini@balsaestates.com> Message-ID: <008f01c8e8dc$de0bbee0$9a233ca0$@rossini@balsaestates.com> > [snip] > > > > > > Coming to think of it.. Would there be any point for me to install > > VS2005? I > > > can use my friends license since he's moved completely to VS2008 > and > > only > > > keeps VS2003 for special occasions. > > > The only package I have myself is VS2008, and that seems to be a > lot > > more > > > "unsafe" judging from discussions here and elsewhere. > > > > > > I also came to think of llkdu.dll, it seems like that isn't copied > to > > the > > > right place by unpacking the libraries and pulling the SVN > sources.. > > Neither > > > does it seem to be built in the process, if I don't copy it > manually, > > I get > > > a copy error from the VS2003 solution. > > > > I don't think switching to VS2005 will make a difference. I just > > finished a VS2003 build and I don't have the problem there either. I > > also ran a cygwin setup update to ensure that nothing bad had crept > > into cygwin recently. > > > > The function that your linker isn't finding is in lex_yy.cpp. Try > > adding an "#error I got here" before this function in lex_yy.cpp, > just > > to rule out some preprocessor difference that's making the code > > unreachable. It's possible you're inheriting a strange #define from > > somewhere: > > > > BOOL lscript_compile(const char* src_filename, const char* > > dst_filename, > > const char* > > err_filename, BOOL is_god_like) > > > > > > Regarding llkdu - that's currently provided for release candidate > > builds only. There are still some sticky issues attached to that. For > > the time being, you can remove the three llkdu rules from > > copy_win_libs and the viewer will use openjpeg if llkdu isn't > present. > > Again though, this should have nothing to do with your link error. > > > Uh oh... I don't even have a file lex_yy.cpp on disk! I found the function in C:\SLDev\release\indra\build-VS2003\lscript\lscript_compile\indra.l.cpp though.. I'll add it there to check. From soft at lindenlab.com Fri Jul 18 07:15:06 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 07:15:09 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: <-8959234424617546971@unknownmsgid> References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> <-8959234424617546971@unknownmsgid> Message-ID: On Fri, Jul 18, 2008 at 8:47 AM, Suzhanna Rossini wrote: >> [snip] >> > > >> > > Coming to think of it.. Would there be any point for me to install >> > VS2005? I >> > > can use my friends license since he's moved completely to VS2008 >> and >> > only >> > > keeps VS2003 for special occasions. >> > > The only package I have myself is VS2008, and that seems to be a >> lot >> > more >> > > "unsafe" judging from discussions here and elsewhere. >> > > >> > > I also came to think of llkdu.dll, it seems like that isn't copied >> to >> > the >> > > right place by unpacking the libraries and pulling the SVN >> sources.. >> > Neither >> > > does it seem to be built in the process, if I don't copy it >> manually, >> > I get >> > > a copy error from the VS2003 solution. >> > >> > I don't think switching to VS2005 will make a difference. I just >> > finished a VS2003 build and I don't have the problem there either. I >> > also ran a cygwin setup update to ensure that nothing bad had crept >> > into cygwin recently. >> > >> > The function that your linker isn't finding is in lex_yy.cpp. Try >> > adding an "#error I got here" before this function in lex_yy.cpp, >> just >> > to rule out some preprocessor difference that's making the code >> > unreachable. It's possible you're inheriting a strange #define from >> > somewhere: >> > >> > BOOL lscript_compile(const char* src_filename, const char* >> > dst_filename, >> > const char* >> > err_filename, BOOL is_god_like) >> > >> > >> > Regarding llkdu - that's currently provided for release candidate >> > builds only. There are still some sticky issues attached to that. For >> > the time being, you can remove the three llkdu rules from >> > copy_win_libs and the viewer will use openjpeg if llkdu isn't >> present. >> > Again though, this should have nothing to do with your link error. >> >> >> Uh oh... I don't even have a file lex_yy.cpp on disk! > > I found the function in > C:\SLDev\release\indra\build-VS2003\lscript\lscript_compile\indra.l.cpp > though.. I'll add it there to check. Oops - lex_yy.cpp was the old pre-cmake name. indra.l.cpp is the current name. indra.l.cpp is indeed the file you would check. From lenglish5 at cox.net Fri Jul 18 07:46:13 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jul 18 07:46:17 2008 Subject: [sldev] [AWG] Pyogp + Enus Linden Office Hours on Fridays Message-ID: <4880ACB5.7080700@cox.net> The pyogp meeting on Friday at 9:30AM SLT morphs into Enus Linden's Office Hours at 10AM SLT. It will be held at Enus Linden's Clubhouse instead of Infinity's office. Topics: Pyogp (planning and various discussion), QA related issues, etc http://slurl.com/secondlife/Longfellow/99/97/28 This first week, Tao T (Christian Scholz) will talk about ZCA (Zope Component Architecture) and how it will be used in pyogp. http://wiki.secondlife.com/wiki/Pyogp Lawson From soft at lindenlab.com Fri Jul 18 07:54:36 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 07:54:40 2008 Subject: [sldev] Missing cares, apr in Mac build Message-ID: On Thu, Jul 17, 2008 at 7:45 PM, Aimee Walton wrote: > On Jul 17, 2008, at 19:19, Soft wrote: >> >> This is strange. I've tried with VS2005 and XCode and I'm not having >> any problem with either. >> >> Aimee, Suzhanna - Would you please walk through the steps you're using >> to unpack and build? It's possible there's a bogus step in our >> instructions that wants fixing. > > OK, going back a step and starting over from scratch ... > > 1) svn co-ed the release branch. > > 2) Downloaded and extracted artwork and "libs" packages. > > 3) Copied in fmod bits. > > 4) Open Xcode (2.4, I'm still using 10.4), > indra/build-darwin-i386/SecondLife.xcodeproj (not > indra/newview/build-darwin-universal/SecondLife.xcodeproj as listed in the > instructions). > > 5) Hit Build (Active target left as ALL_BUILD and config RelWithDebInfo). > > Result ... > > Building target "liblscript_compile.a" of project "SecondLife" with > configuration "RelWithDebInfo" ? (2 warnings) > Checking Dependencies > warning: no rule to process file > '....../indra/build-darwin-i386/lscript/lscript_compile/indra.l.cpp.rule' of > type file for architecture i386 > warning: no rule to process file > '....../indra/build-darwin-i386/lscript/lscript_compile/indra.y.cpp.rule' of > type file for architecture i386 > > Building target "mac-crash-logger" of project "SecondLife" with > configuration "RelWithDebInfo" ? (1 error) > mkdir ....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo > cd ....../indra/build-darwin-i386 > /usr/bin/g++-4.0 -o > ....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo/mac-crash-logger > -L....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo > -L....../indra/build-darwin-i386/llcrashlogger/RelWithDebInfo/RelWithDebInfo > -L....../indra/build-darwin-i386/llcrashlogger/RelWithDebInfo > -L....../indra/build-darwin-i386/llvfs/RelWithDebInfo/RelWithDebInfo > -L....../indra/build-darwin-i386/llvfs/RelWithDebInfo > -L....../indra/../libraries/universal-darwin/lib_release/RelWithDebInfo > -L....../indra/../libraries/universal-darwin/lib_release > -L....../indra/build-darwin-i386/llxml/RelWithDebInfo/RelWithDebInfo > -L....../indra/build-darwin-i386/llxml/RelWithDebInfo > -L....../indra/build-darwin-i386/llmessage/RelWithDebInfo/RelWithDebInfo > -L....../indra/build-darwin-i386/llmessage/RelWithDebInfo > -L....../indra/build-darwin-i386/llmath/RelWithDebInfo/RelWithDebInfo > -L....../indra/build-darwin-i386/llmath/RelWithDebInfo > -L....../indra/build-darwin-i386/llcommon/RelWithDebInfo/RelWithDebInfo > -L....../indra/build-darwin-i386/llcommon/RelWithDebInfo > -F....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo -filelist > ....../indra/build-darwin-i386/mac_crash_logger/SecondLife.build/RelWithDebInfo/mac-crash-logger.build/Objects-normal/i386/mac-crash-logger.LinkFileList > -arch i386 -Wl,-Y,1455 -L/opt/local/lib -L/usr/X11R6/lib > -Wl,-headerpad_max_install_names,-search_paths_first > ....../indra/build-darwin-i386/llcrashlogger/RelWithDebInfo/libllcrashlogger.a > ....../indra/build-darwin-i386/llvfs/RelWithDebInfo/libllvfs.a -framework > Carbon -lexpat -lcurl > ....../indra/../libraries/universal-darwin/lib_release/cares -lssl > -lllcrypto -lxmlrpc-epi > ....../indra/../libraries/universal-darwin/lib_release/aprutil-1 > ....../indra/../libraries/universal-darwin/lib_release/apr-1 -framework > Carbon -lexpat -lcurl > ....../indra/../libraries/universal-darwin/lib_release/cares -lssl > -lllcrypto -lxmlrpc-epi > ....../indra/../libraries/universal-darwin/lib_release/aprutil-1 > ....../indra/../libraries/universal-darwin/lib_release/apr-1 > ....../indra/build-darwin-i386/llxml/RelWithDebInfo/libllxml.a > ....../indra/build-darwin-i386/llmessage/RelWithDebInfo/libllmessage.a > ....../indra/build-darwin-i386/llmath/RelWithDebInfo/libllmath.a > ....../indra/build-darwin-i386/llcommon/RelWithDebInfo/libllcommon.a -lz > -lboost_signals-mt -lexpat > ....../indra/build-darwin-i386/llmessage/RelWithDebInfo/libllmessage.a > -lcurl ....../indra/../libraries/universal-darwin/lib_release/cares -lssl > -lllcrypto -lxmlrpc-epi > ....../indra/build-darwin-i386/llvfs/RelWithDebInfo/libllvfs.a -framework > Carbon ....../indra/build-darwin-i386/llmath/RelWithDebInfo/libllmath.a > ....../indra/build-darwin-i386/llcommon/RelWithDebInfo/libllcommon.a > ....../indra/../libraries/universal-darwin/lib_release/aprutil-1 > ....../indra/../libraries/universal-darwin/lib_release/apr-1 -lexpat -lz > -lboost_signals-mt > > i686-apple-darwin8-g++-4.0.1: > ....../indra/../libraries/universal-darwin/lib_release/cares: No such file > or directory > i686-apple-darwin8-g++-4.0.1: > ....../indra/../libraries/universal-darwin/lib_release/aprutil-1: No such > file or directory > i686-apple-darwin8-g++-4.0.1: > ....../indra/../libraries/universal-darwin/lib_release/apr-1: No such file > or directory > > Build failed (1 error, 2 warnings) Yours is a different error. You can safely ignore the two .rule warnings. Between steps 3 and 4, did you run "develop.py configure" ? If you would do that and capture the output, it should help us determine why you're missing cares, aprutil-1, and apr-1 From woltamat at gmail.com Fri Jul 18 07:55:37 2008 From: woltamat at gmail.com (Wolt Amat) Date: Fri Jul 18 07:55:47 2008 Subject: [sldev] Noob Compile Errors Message-ID: <003101c8e8e6$5e770680$1b651380$@com> I didn't see any replies to the earlier email of the subject "SL Startup Errors Message" of March 25, 2007, or discover any new clues anywhere else. If anyone has some breadcrumbs to throw an amateur (I was able to solve the zillions of previous pilot errors with all your earlier comments, THANKS! :-) ). Environment as per Wiki - VC++ Exp 2005 SP1, Win Server 2003 R2 PSDK, DirectX December 2006, CMake 2.4.8, Cygwin 1.5.25-14, ActivePython 2.4.5.14, Fmod 3.75, OpenGL headers, ares and openJPEG files already in Branch, QT SDK. Branch 1-20-13-r91658, "Test" project removed from build list. DEBUG build of indra_complete, report 237 warnings: - "..linked as if no debug info", LNK4099, in libs apr-1, aprutil-1, areslib, freetype, jpeg_lib_6b, libcurld, libexpatMT, llmozlib2d-vc80, ogg_static_mt, png12, vorbis_static_mt, vorbisenc_static_mt, vorbisfile_static_mt, xmlrpcepi, libndofdev. - Files not found in final link: 1. - dlls - freeb13, gksvggdiplus, js3250, nspr4, nss3, nssckbi, plc4, plds4, smime3, softokn3, ssl3, xpcom, xul, openjpegd, tntk, libeay32, ssleay32, srtp, alut, vivoxsdk, ortp, wrap_oal 2. - exes - windbgdlg, SLVoice, SLVoiceAgent. - Execution of debugview failed because most symbols were not loaded. RELEASE build of indra_complete, report 26 errors, 1 warning: - llmath -> LNK4221, llrect.obj, lllogitechlcd.obj, - no public symbols found. - llwindow-> libexpatMT.lib (xmlparse.obj) LNK4075, 'ignoring /EDITANDCONTINUE due to '/OPT:ICF' specification. - win_crash_logger -> libcmtd.lib many LNK2005 errors and final LNK4098 and LNK1169, symbols already defined in libcmt.lib. I see this is a Debug versus Release issue, but I couldn't find where to change settings. I'll just dig thru my paths on this one, since it did not show up in the Debug build. - Stopped before building executable. Thanks! Wolt Amat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080718/57b6c678/attachment-0001.htm From tao.takashi at googlemail.com Fri Jul 18 08:02:10 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Fri Jul 18 08:02:13 2008 Subject: [sldev] [AWG] Pyogp + Enus Linden Office Hours on Fridays In-Reply-To: <4880ACB5.7080700@cox.net> References: <4880ACB5.7080700@cox.net> Message-ID: <23bbb49e0807180802w1087821csc5077bfcb588d254@mail.gmail.com> Hi! On Fri, Jul 18, 2008 at 4:46 PM, Lawson English wrote: > The pyogp meeting on Friday at 9:30AM SLT morphs into Enus Linden's Office > Hours at 10AM SLT. It will be held at Enus Linden's Clubhouse instead of > Infinity's office. > > Topics: Pyogp (planning and various discussion), QA related issues, etc > > http://slurl.com/secondlife/Longfellow/99/97/28 > > This first week, Tao T (Christian Scholz) will talk about ZCA (Zope > Component Architecture) and how it will be used in pyogp. I would like to add that I don't want to do an introduction but more or less answer questions about it. So this is mainly geared towards people who want to contribute to the project, have read my tutorial and have questions about it. I would like to keep this strict in this scope in order to have a useful outcome for those interested. So if you want to join pyogp and haven't read the tutorial on ZCA please do so now: https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/Development/Zope (we need to rename this page later as it's not about Zope and might be confusing as Zope is the whole application server while ZCA is just a small part which was developed by the Zope team but is useful outside it's original context) -- Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From suzhanna.rossini at balsaestates.com Fri Jul 18 08:35:21 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 08:35:35 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> <-8959234424617546971@unknownmsgid> Message-ID: <00b001c8e8eb$e3cf9590$ab6ec0b0$@rossini@balsaestates.com> > On Fri, Jul 18, 2008 at 8:47 AM, Suzhanna Rossini > wrote: > >> [snip] > >> > > > >> > > Coming to think of it.. Would there be any point for me to > install > >> > VS2005? I > >> > > can use my friends license since he's moved completely to VS2008 > >> and > >> > only > >> > > keeps VS2003 for special occasions. > >> > > The only package I have myself is VS2008, and that seems to be a > >> lot > >> > more > >> > > "unsafe" judging from discussions here and elsewhere. > >> > > > >> > > I also came to think of llkdu.dll, it seems like that isn't > copied > >> to > >> > the > >> > > right place by unpacking the libraries and pulling the SVN > >> sources.. > >> > Neither > >> > > does it seem to be built in the process, if I don't copy it > >> manually, > >> > I get > >> > > a copy error from the VS2003 solution. > >> > > >> > I don't think switching to VS2005 will make a difference. I just > >> > finished a VS2003 build and I don't have the problem there either. > I > >> > also ran a cygwin setup update to ensure that nothing bad had > crept > >> > into cygwin recently. > >> > > >> > The function that your linker isn't finding is in lex_yy.cpp. Try > >> > adding an "#error I got here" before this function in lex_yy.cpp, > >> just > >> > to rule out some preprocessor difference that's making the code > >> > unreachable. It's possible you're inheriting a strange #define > from > >> > somewhere: > >> > > >> > BOOL lscript_compile(const char* src_filename, const char* > >> > dst_filename, > >> > const char* > >> > err_filename, BOOL is_god_like) > >> > > >> > > >> > Regarding llkdu - that's currently provided for release candidate > >> > builds only. There are still some sticky issues attached to that. > For > >> > the time being, you can remove the three llkdu rules from > >> > copy_win_libs and the viewer will use openjpeg if llkdu isn't > >> present. > >> > Again though, this should have nothing to do with your link error. > >> > >> > >> Uh oh... I don't even have a file lex_yy.cpp on disk! > > > > I found the function in > > C:\SLDev\release\indra\build- > VS2003\lscript\lscript_compile\indra.l.cpp > > though.. I'll add it there to check. > > Oops - lex_yy.cpp was the old pre-cmake name. indra.l.cpp is the > current name. indra.l.cpp is indeed the file you would check. It never hit the #error stop in the cpp file. However, I found another declaration in indra\lscript\lscript_rt_interface.h (line 35) where I also put in the stop, and that one hit. Alexandra. From enus at lindenlab.com Fri Jul 18 09:17:10 2008 From: enus at lindenlab.com (Enus Linden) Date: Fri Jul 18 09:17:14 2008 Subject: [sldev] Re: [Pyogp] [AWG] Pyogp + Enus Linden Office Hours on Fridays In-Reply-To: <4880ACB5.7080700@cox.net> References: <4880ACB5.7080700@cox.net> Message-ID: <4880C206.9070503@lindenlab.com> the morphing is only of location and duration, not of start time. 9:30 Fridays http://slurl.com/secondlife/Longfellow/99/97/28 see ya in a few... Lawson English wrote: > The pyogp meeting on Friday at 9:30AM SLT morphs into Enus Linden's > Office Hours at 10AM SLT. It will be held at Enus Linden's Clubhouse > instead of Infinity's office. > > Topics: Pyogp (planning and various discussion), QA related issues, etc > > http://slurl.com/secondlife/Longfellow/99/97/28 > > This first week, Tao T (Christian Scholz) will talk about ZCA (Zope > Component Architecture) and how it will be used in pyogp. > > > http://wiki.secondlife.com/wiki/Pyogp > > Lawson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp From soft at lindenlab.com Fri Jul 18 09:48:36 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 09:48:39 2008 Subject: SV: [sldev] Unresolved externals In-Reply-To: <4676534703932080879@unknownmsgid> References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> <-8959234424617546971@unknownmsgid> <4676534703932080879@unknownmsgid> Message-ID: On Fri, Jul 18, 2008 at 10:35 AM, Suzhanna Rossini wrote: >> On Fri, Jul 18, 2008 at 8:47 AM, Suzhanna Rossini >> wrote: >> >> [snip] >> >> > > >> >> > > Coming to think of it.. Would there be any point for me to >> install >> >> > VS2005? I >> >> > > can use my friends license since he's moved completely to VS2008 >> >> and >> >> > only >> >> > > keeps VS2003 for special occasions. >> >> > > The only package I have myself is VS2008, and that seems to be a >> >> lot >> >> > more >> >> > > "unsafe" judging from discussions here and elsewhere. >> >> > > >> >> > > I also came to think of llkdu.dll, it seems like that isn't >> copied >> >> to >> >> > the >> >> > > right place by unpacking the libraries and pulling the SVN >> >> sources.. >> >> > Neither >> >> > > does it seem to be built in the process, if I don't copy it >> >> manually, >> >> > I get >> >> > > a copy error from the VS2003 solution. >> >> > >> >> > I don't think switching to VS2005 will make a difference. I just >> >> > finished a VS2003 build and I don't have the problem there either. >> I >> >> > also ran a cygwin setup update to ensure that nothing bad had >> crept >> >> > into cygwin recently. >> >> > >> >> > The function that your linker isn't finding is in lex_yy.cpp. Try >> >> > adding an "#error I got here" before this function in lex_yy.cpp, >> >> just >> >> > to rule out some preprocessor difference that's making the code >> >> > unreachable. It's possible you're inheriting a strange #define >> from >> >> > somewhere: >> >> > >> >> > BOOL lscript_compile(const char* src_filename, const char* >> >> > dst_filename, >> >> > const char* >> >> > err_filename, BOOL is_god_like) >> >> > >> >> > >> >> > Regarding llkdu - that's currently provided for release candidate >> >> > builds only. There are still some sticky issues attached to that. >> For >> >> > the time being, you can remove the three llkdu rules from >> >> > copy_win_libs and the viewer will use openjpeg if llkdu isn't >> >> present. >> >> > Again though, this should have nothing to do with your link error. >> >> >> >> >> >> Uh oh... I don't even have a file lex_yy.cpp on disk! >> > >> > I found the function in >> > C:\SLDev\release\indra\build- >> VS2003\lscript\lscript_compile\indra.l.cpp >> > though.. I'll add it there to check. >> >> Oops - lex_yy.cpp was the old pre-cmake name. indra.l.cpp is the >> current name. indra.l.cpp is indeed the file you would check. > > > It never hit the #error stop in the cpp file. > However, I found another declaration in indra\lscript\lscript_rt_interface.h > (line 35) where I also put in the stop, and that one hit. If it's not hitting that #error, yours is building differently than mine is. Also, I'm seeing an indra\lscript\lscript_rt_interface.h.cpp which most definitely shouldn't exist - do you have that too? I'm punting that over to the cmake team to look at. I suspect something's getting generated in the wrong place. From grant at lindenlab.com Fri Jul 18 09:57:57 2008 From: grant at lindenlab.com (Grant Linden) Date: Fri Jul 18 09:58:00 2008 Subject: [sldev] The SL-UX Email Discussion List Message-ID: <907af5560807180957l19e159b3l70527620462b1ae0@mail.gmail.com> The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080718/f9865168/attachment.htm From robin.cornelius at gmail.com Fri Jul 18 10:00:59 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jul 18 10:01:02 2008 Subject: [sldev] [VWR][PATCH] Save windlight settings in user R/W area and allow multiple day cycles to be created Message-ID: Following up from last nights meeting at Rob's hours, it was suggested that i ping sldev with info on my patches as well so here goes:- In particular reference to VWR-4981 (Windlight environment settings save in the wrong location) and VWR-5917 (Can not save "day cycles" by name) which are very tightly coupled. I've implemented both features and they seem to work ok, so any further testing and refinements would also be very welcome, as i am sure my coding is not perfect by any means ;-) Another thought is that if we have the ability to have multiple day cycles should we also have the ability to play these in sequence or random? I think this is the next logical step with user defined days as it would make things a lot more interesting if you had a whole bunch of defined days that randomly played as you were in world. I will probably open a new feature JIRA with this too. Regards Robin From qarl at lindenlab.com Fri Jul 18 10:04:34 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Fri Jul 18 10:04:37 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <89ca6da00807171905p2897e83drb37a7e35b63a0ae4@mail.gmail.com> References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> <89ca6da00807171905p2897e83drb37a7e35b63a0ae4@mail.gmail.com> Message-ID: > But you could say the same about _INVERT. When would you need both > normal and inverted) versions in a scene oh oh oh - i understand now. there actually IS a good use case for the INVERT flag: both planar and cylindrical sculpties are "invisible" from the backside. (this is typical of 3d meshes, and desirable, i think.) but when making a sail or a piece of paper, you want a backside too. and now you can - with that INVERT flag. thus far, content creators have been making a second inverted sculpt map to achieve this end - now they can use the same map, and so INVERT is very similar to MIRROR in that it reduces the number of necessary maps. > You are more than welcome to rubber stamp this "PENDING CROQUET > BECOMING AN OLYMPIC SPORT AGAIN" and I won't take offense. HEY! i was on my college croquet team. IT'S A REAL SPORT. :) K. From soft at lindenlab.com Fri Jul 18 10:07:17 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 10:07:22 2008 Subject: [sldev] Noob Compile Errors In-Reply-To: <003101c8e8e6$5e770680$1b651380$@com> References: <003101c8e8e6$5e770680$1b651380$@com> Message-ID: On Fri, Jul 18, 2008 at 9:55 AM, Wolt Amat wrote: > > Branch 1-20-13-r91658, "Test" project removed from build list. > > DEBUG build of indra_complete, report 237 warnings: > > - "..linked as if no debug info", LNK4099, in libs apr-1, aprutil-1, > areslib, freetype, jpeg_lib_6b, libcurld, libexpatMT, llmozlib2d-vc80, > ogg_static_mt, png12, vorbis_static_mt, vorbisenc_static_mt, > vorbisfile_static_mt, xmlrpcepi, libndofdev. > > - Files not found in final link: > > 1. ? dlls ? freeb13, gksvggdiplus, js3250, nspr4, nss3, nssckbi, plc4, > plds4, smime3, softokn3, ssl3, xpcom, xul, openjpegd, tntk, libeay32, > ssleay32, srtp, alut, vivoxsdk, ortp, wrap_oal > > 2. - exes - windbgdlg, SLVoice, SLVoiceAgent. It looks as though you haven't downloaded the matching library bundle. You need to unzip three files in the same location - source, artwork and library. Also, use the ReleaseNoOpt or ReleaseForDownload build. The straight debug and release builds may not work. On that front, things are in better shape once you move off of 1.20. From aimee at ama-zing.co.uk Fri Jul 18 10:11:54 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Jul 18 10:12:10 2008 Subject: [sldev] Re: Missing cares, apr in Mac build In-Reply-To: References: Message-ID: On Jul 18, 2008, at 15:54, Soft wrote: > > Yours is a different error. You can safely ignore the two .rule > warnings. > > > Between steps 3 and 4, did you run "develop.py configure" ? If you > would do that and capture the output, it should help us determine why > you're missing cares, aprutil-1, and apr-1 Ah, yes, I did do that, I just hit send on that email before I'd finished typing it *smacks forehead* What I meant to go on to say was thinking back I'd ended up with the other error after trying to fudge my way round that one, so probably a red-herring. I've tracked this problem down to having version 2.6.0 of CMake installed rather than 2.4.8. I'll put a note on the Wiki to emphasize it must be 2.4.8. Aimee. From suzhanna.rossini at balsaestates.com Fri Jul 18 10:12:44 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 10:12:57 2008 Subject: SV: SV: [sldev] Unresolved externals In-Reply-To: References: <-5008687841307650898@unknownmsgid> <-8304386138781750816@unknownmsgid> <-150151222741468767@unknownmsgid> <-8959234424617546971@unknownmsgid> <4676534703932080879@unknownmsgid> Message-ID: <001201c8e8f9$7e68d780$7b3a8680$@rossini@balsaestates.com> > -----Ursprungligt meddelande----- > Fr?n: brian@brianm.org [mailto:brian@brianm.org] F?r Soft > Skickat: den 18 juli 2008 18:49 > Till: Suzhanna Rossini > Kopia: Second Life Developer Mailing List > ?mne: Re: SV: [sldev] Unresolved externals > > On Fri, Jul 18, 2008 at 10:35 AM, Suzhanna Rossini > wrote: > >> On Fri, Jul 18, 2008 at 8:47 AM, Suzhanna Rossini > >> wrote: > >> >> [snip] > >> >> > > > >> >> > > Coming to think of it.. Would there be any point for me to > >> install > >> >> > VS2005? I > >> >> > > can use my friends license since he's moved completely to > VS2008 > >> >> and > >> >> > only > >> >> > > keeps VS2003 for special occasions. > >> >> > > The only package I have myself is VS2008, and that seems to > be a > >> >> lot > >> >> > more > >> >> > > "unsafe" judging from discussions here and elsewhere. > >> >> > > > >> >> > > I also came to think of llkdu.dll, it seems like that isn't > >> copied > >> >> to > >> >> > the > >> >> > > right place by unpacking the libraries and pulling the SVN > >> >> sources.. > >> >> > Neither > >> >> > > does it seem to be built in the process, if I don't copy it > >> >> manually, > >> >> > I get > >> >> > > a copy error from the VS2003 solution. > >> >> > > >> >> > I don't think switching to VS2005 will make a difference. I > just > >> >> > finished a VS2003 build and I don't have the problem there > either. > >> I > >> >> > also ran a cygwin setup update to ensure that nothing bad had > >> crept > >> >> > into cygwin recently. > >> >> > > >> >> > The function that your linker isn't finding is in lex_yy.cpp. > Try > >> >> > adding an "#error I got here" before this function in > lex_yy.cpp, > >> >> just > >> >> > to rule out some preprocessor difference that's making the code > >> >> > unreachable. It's possible you're inheriting a strange #define > >> from > >> >> > somewhere: > >> >> > > >> >> > BOOL lscript_compile(const char* src_filename, const char* > >> >> > dst_filename, > >> >> > const char* > >> >> > err_filename, BOOL is_god_like) > >> >> > > >> >> > > >> >> > Regarding llkdu - that's currently provided for release > candidate > >> >> > builds only. There are still some sticky issues attached to > that. > >> For > >> >> > the time being, you can remove the three llkdu rules from > >> >> > copy_win_libs and the viewer will use openjpeg if llkdu isn't > >> >> present. > >> >> > Again though, this should have nothing to do with your link > error. > >> >> > >> >> > >> >> Uh oh... I don't even have a file lex_yy.cpp on disk! > >> > > >> > I found the function in > >> > C:\SLDev\release\indra\build- > >> VS2003\lscript\lscript_compile\indra.l.cpp > >> > though.. I'll add it there to check. > >> > >> Oops - lex_yy.cpp was the old pre-cmake name. indra.l.cpp is the > >> current name. indra.l.cpp is indeed the file you would check. > > > > > > It never hit the #error stop in the cpp file. > > However, I found another declaration in > indra\lscript\lscript_rt_interface.h > > (line 35) where I also put in the stop, and that one hit. > > If it's not hitting that #error, yours is building differently than > mine is. > > Also, I'm seeing an indra\lscript\lscript_rt_interface.h.cpp which > most definitely shouldn't exist - do you have that too? I'm punting > that over to the cmake team to look at. I suspect something's getting > generated in the wrong place. Nope, I only have one occurrence of files with "rt_interface" in the name, and it's the indra\lscript\lscript_rt_interface.h file. Nothing else containing "rt_interface" within the file name. Alexandra. From soft at lindenlab.com Fri Jul 18 10:18:30 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 18 10:18:32 2008 Subject: [sldev] Re: Missing cares, apr in Mac build In-Reply-To: References: Message-ID: On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton wrote: > > > I've tracked this problem down to having version 2.6.0 of CMake installed > rather than 2.4.8. I'll put a note on the Wiki to emphasize it must be > 2.4.8. Ah! Suzhanna, could your problem be the same? From suzhanna.rossini at balsaestates.com Fri Jul 18 10:44:23 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Fri Jul 18 10:44:32 2008 Subject: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: References: Message-ID: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> > On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton > wrote: > > > > > > I've tracked this problem down to having version 2.6.0 of CMake > installed > > rather than 2.4.8. I'll put a note on the Wiki to emphasize it must > be > > 2.4.8. > > Ah! > > Suzhanna, could your problem be the same? Could be, it's cmake 2.6-patch 0 installed.. I'll revert to 2.4.8 and make a new round with it later.. It's already 7.45pm here, and I was thinking of some socializing and wine tonight.. ;-) Alexandra From robla at lindenlab.com Fri Jul 18 10:51:46 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jul 18 10:51:53 2008 Subject: [sldev] CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: References: Message-ID: <4880D832.6070205@lindenlab.com> On 7/18/08 10:11 AM, Aimee Walton wrote: > I've tracked this problem down to having version 2.6.0 of CMake > installed rather than 2.4.8. I'll put a note on the Wiki to emphasize > it must be 2.4.8. Does anyone know if there a fundamental incompatibility between CMake 2.4.8 and 2.6, or is CMake 2.6 support something that can be made to work without too much hassle? This seems like a FAQ in the making. Rob From bill.hoffman at kitware.com Fri Jul 18 10:55:31 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Jul 18 10:56:23 2008 Subject: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> References: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> Message-ID: <4880D913.8070500@kitware.com> Suzhanna Rossini wrote: >> On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton >> wrote: >>> >>> I've tracked this problem down to having version 2.6.0 of CMake >> installed >>> rather than 2.4.8. I'll put a note on the Wiki to emphasize it must >> be >>> 2.4.8. >> Ah! >> >> Suzhanna, could your problem be the same? > > > Could be, it's cmake 2.6-patch 0 installed.. I'll revert to 2.4.8 and make a > new round with it later.. It's already 7.45pm here, and I was thinking of > some socializing and wine tonight.. ;-) > Hello, I would like to know where the incompatibility is for 2.6 to 2.4 CMake. Can someone give me that information? They "should" be compatible. I could make sure a fix goes into 2.6.1 if I knew the problem. Thanks. -Bill From aimee at ama-zing.co.uk Fri Jul 18 11:42:45 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Jul 18 11:43:01 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <4880D832.6070205@lindenlab.com> References: <4880D832.6070205@lindenlab.com> Message-ID: On Jul 18, 2008, at 18:51, Rob Lanphier wrote: > > Does anyone know if there a fundamental incompatibility between > CMake 2.4.8 and 2.6, or is CMake 2.6 support something that can be > made to work without too much hassle? This seems like a FAQ in the > making. This is the problem ... aimee$ ./cmake --help-policy CMP0003 cmake version 2.6-patch 0 ------------------------------------------------------------------------ ------ CMP0003 Libraries linked via full path no longer produce linker search paths. This policy affects how libraries whose full paths are NOT known are found at link time, but was created due to a change in how CMake deals with libraries whose full paths are known. Consider the code target_link_libraries(myexe /path/to/libA.so) CMake 2.4 and below implemented linking to libraries whose full paths are known by splitting them on the link line into separate components consisting of the linker search path and the library name. The example code might have produced something like ... -L/path/to -lA ... in order to link to library A. An analysis was performed to order multiple link directories such that the linker would find library A in the desired location, but there are cases in which this does not work. CMake versions 2.6 and above use the more reliable approach of passing the full path to libraries directly to the linker in most cases. The example code now produces something like ... /path/to/libA.so .... Unfortunately this change can break code like target_link_libraries(myexe /path/to/libA.so B) where "B" is meant to find "/path/to/libB.so". This code is wrong because the user is asking the linker to find library B but has not provided a linker search path (which may be added with the link_directories command). However, with the old linking implementation the code would work accidentally because the linker search path added for library A allowed library B to be found. In order to support projects depending on linker search paths added by linking to libraries with known full paths, the OLD behavior for this policy will add the linker search paths even though they are not needed for their own libraries. When this policy is set to OLD, CMake will produce a link line such as ... -L/path/to /path/to/libA.so -lB ... which will allow library B to be found as it was previously. When this policy is set to NEW, CMake will produce a link line such as ... /path/to/libA.so -lB ... which more accurately matches what the project specified. The setting for this policy used when generating the link line is that in effect when the target is created by an add_executable or add_library command. For the example described above, the code cmake_policy(SET CMP0003 OLD) # or cmake_policy(VERSION 2.4) add_executable(myexe myexe.c) target_link_libraries(myexe /path/to/libA.so B) will work and suppress the warning for this policy. It may also be updated to work with the corrected linking approach: cmake_policy(SET CMP0003 NEW) # or cmake_policy(VERSION 2.6) link_directories(/path/to) # needed to find library B add_executable(myexe myexe.c) target_link_libraries(myexe /path/to/libA.so B) Even better, library B may be specified with a full path: add_executable(myexe myexe.c) target_link_libraries(myexe /path/to/libA.so /path/to/libB.so) When all items on the link line have known paths CMake does not check this policy so it has no effect. Note that the warning for this policy will be issued for at most one target. This avoids flooding users with messages for every target when setting the policy once will probably fix all targets. This policy was introduced in CMake version 2.6.0. CMake version 2.6 warns when the policy is not set and uses OLD behavior. Use the cmake_policy command to set it to OLD or NEW explicitly. telstar-airport:/Applications/Development/CMake 2.6-0.app/Contents/ bin aimee$ From bill.hoffman at kitware.com Fri Jul 18 12:21:57 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Jul 18 12:22:49 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: References: <4880D832.6070205@lindenlab.com> Message-ID: <4880ED55.3010705@kitware.com> Aimee Walton wrote: > > On Jul 18, 2008, at 18:51, Rob Lanphier wrote: >> >> Does anyone know if there a fundamental incompatibility between CMake >> 2.4.8 and 2.6, or is CMake 2.6 support something that can be made to >> work without too much hassle? This seems like a FAQ in the making. > > This is the problem ... > > > > aimee$ ./cmake --help-policy CMP0003 > > cmake version 2.6-patch 0 > ------------------------------------------------------------------------------ > > > > CMP0003 > Libraries linked via full path no longer produce linker search Sure, that is a warning, does the build still work? If so, you can do run cmake like this: ./cmake -Wno-dev In the long run, this should be fixed in the SL CMake files. Just add these statements at the top of the CMakeLists.txt for SL, and it should fix the problem for the whole project. if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) The only case that is not true is when there are more than one instance of cmake_minimum_required(VERSION 2.4) in the project. If so, you would need the above three lines after each cmake_minimum_required call. -Bill From bos at lindenlab.com Fri Jul 18 13:35:55 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Jul 18 13:35:58 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <4880ED55.3010705@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> Message-ID: On Fri, Jul 18, 2008 at 12:21 PM, Bill Hoffman wrote: > Sure, that is a warning, does the build still work? No. It assumes that the libraries that it can't find are .obj instead of .lib (on Windows), and so fails at link time. I'd rather fix the problem in a 2.6-compatible way, instead of suppressing some warning, but I've been out for a few weeks and it's not an especially high priority. From sllists at boroon.dasgupta.ch Fri Jul 18 13:56:17 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri Jul 18 13:56:22 2008 Subject: [sldev] [HELP] CMake: Problem with missing directory 'indra/viewer-linux-i686' In-Reply-To: <4873C378.1010802@boroon.dasgupta.ch> References: <4873C378.1010802@boroon.dasgupta.ch> Message-ID: <48810371.6000608@boroon.dasgupta.ch> Boroondas Gupte schrieb: >> ~/slsrc/svn/release/linden/indra $ *./develop.py* >> Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >> -G \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE >> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >> \'/home//slsrc/svn/release/linden/indra\'' in >> 'viewer-linux-i686' >> [...] >> Writing state to >> /home//slsrc/svn/release/linden/installed.xml >> *CMake Error: Cannot find source file >> "/home/**/slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/attentions.xml"* >> >> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >> .hpp .hxx .in .txx >> CMake Error: CMake failed to properly look up cmSourceFile: >> character/attentions.xml >> [...] > The directory indra/viewer-linux-i686 doesn't exist, but I also can't > find any file named attentions.xml anywhere else in the tree. I'm on Linux (i686) and have cmake version 2.4-patch 8, if that should matter. Any help appreciated. Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080718/1c26f1e1/attachment.htm From bill.hoffman at kitware.com Fri Jul 18 13:55:44 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Jul 18 13:56:36 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> Message-ID: <48810350.8070000@kitware.com> Bryan O'Sullivan wrote: > On Fri, Jul 18, 2008 at 12:21 PM, Bill Hoffman wrote: > >> Sure, that is a warning, does the build still work? > > No. It assumes that the libraries that it can't find are .obj instead > of .lib (on Windows), and so fails at link time. > OK, that is a different issue, and is related to policy CMP0003, but can only be fixed by changing the cmake code. I think this happens when you do something like this: target_link_libraries(myexe c:/path/to/foo) In 2.4 that would be: -LIBPATHc:/path/to/ foo.lib (the correct code would be target_link_libraries(myexe c:/path/to/foo.lib) However, if you used nmake or makefiles it would have with 2.4 since it would have put a depend into the makefile like this: c:/path/to/foo which would never exist and cause make to complain. This should only happen if you give cmake a full path to a file that is not actually a library it can link to. Is that the case you have, or is it something different? > I'd rather fix the problem in a 2.6-compatible way, instead of > suppressing some warning, but I've been out for a few weeks and it's > not an especially high priority. > OK, the fix is to set the policy to new. Doing that is not suppressing the warning, it is changing the way cmake behaves. We give the warning because there MIGHT be a problem at link time and we can't tell, so to be on the safe side we add extra -L stuff just to make sure things still work like the used to. So, the 2.6 compatible way to fix this issue is to add this code: if(COMMAND cmake_policy) cmake_policy(SET CMP0003 NEW) endif(COMMAND cmake_policy) By doing that it tells CMake, that you do not want/need the extra -L paths. If a project had cmake_minimum_required(VERSION 2.6) at the top of it, you would not need to set that policy at all, as the default for 2.6 is CMP0003 = NEW. Sorry that this is so confusing, I wish we could have gotten away without this confusing policy. You are not the first to think that the above code is just doing a suppression of a warning message, and I am sure you won't be the last.... :) -Bill From aimee at ama-zing.co.uk Fri Jul 18 18:50:45 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Jul 18 18:51:03 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <4880ED55.3010705@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> Message-ID: On Jul 18, 2008, at 20:21, Bill Hoffman wrote: > Aimee Walton wrote: >> On Jul 18, 2008, at 18:51, Rob Lanphier wrote: >>> >>> Does anyone know if there a fundamental incompatibility between >>> CMake 2.4.8 and 2.6, or is CMake 2.6 support something that can >>> be made to work without too much hassle? This seems like a FAQ >>> in the making. >> This is the problem ... >> aimee$ ./cmake --help-policy CMP0003 >> cmake version 2.6-patch 0 >> --------------------------------------------------------------------- >> --------- CMP0003 >> Libraries linked via full path no longer produce linker search > > > Sure, that is a warning, does the build still work? Sorry, not my most useful reply ever, I'll blame lack of sleep. We have target_link_libraries(myexe /path/to/foo) Which is working on 2.4 as it splits to give -lfoo However on 2.6 it breaks the build, as it uses /path/to/foo when it really needs /path/to/libfoo.a AImee. From bill.hoffman at kitware.com Fri Jul 18 19:20:53 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Jul 18 19:21:39 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> Message-ID: <48814F85.5030600@kitware.com> Aimee Walton wrote: > > On Jul 18, 2008, at 20:21, Bill Hoffman wrote: > >> Aimee Walton wrote: >>> On Jul 18, 2008, at 18:51, Rob Lanphier wrote: >>>> >>>> Does anyone know if there a fundamental incompatibility between >>>> CMake 2.4.8 and 2.6, or is CMake 2.6 support something that can be >>>> made to work without too much hassle? This seems like a FAQ in the >>>> making. >>> This is the problem ... >>> aimee$ ./cmake --help-policy CMP0003 >>> cmake version 2.6-patch 0 >>> ------------------------------------------------------------------------------ >>> CMP0003 >>> Libraries linked via full path no longer produce linker search >> >> >> Sure, that is a warning, does the build still work? > > Sorry, not my most useful reply ever, I'll blame lack of sleep. > > We have > target_link_libraries(myexe /path/to/foo) > > Which is working on 2.4 as it splits to give -lfoo > > However on 2.6 it breaks the build, as it uses /path/to/foo when it > really needs /path/to/libfoo.a > But that would be broken for any makefile build in 2.4. It would only work in Visual Studio IDE projects. If you build with nmake, or any other make it would break in 2.4 as well. But, you are showing foo.a, does that actually work with a makefile in cmake 2.4? -Bill From dmahalko at gmail.com Fri Jul 18 21:16:17 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jul 18 21:16:20 2008 Subject: [sldev] Expunging MS compiler config? (Re: ... builds won't compile) Message-ID: For whatever reason my computer is screwed up beyond compilability. This error keeps happening over and over for each compile attempt for any of the release candidates. It cannot find "llaudio.lib" which makes no sense to me because this library should be a part of the source zipfiles in each RC. ------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ Executing pre-build batch file master: http://secondlife.com/app/message_template/master_message_template.msg current: c:\SL_Viewer_Builds\1_20_11_RC\linden\scripts\messages\message_template.msg Refreshing master cache from http://secondlife.com/app/message_template/master_message_template.msg --- PASS --- Same PREBUILD SUCCESSFUL Linking... LINK : fatal error LNK1181: cannot open input file 'llaudio.lib' Build log was saved at "file://c:\SL_Viewer_Builds\1_20_11_RC\linden\indra\newview\ReleaseForDownload\BuildLog.htm" newview - 1 error(s), 0 warning(s) Since I don't know what went wrong, I'm going to have to go for a fresh start, and I'd like to know what else I might need to do to clean out the system before reinstalling. Here is what I've done so far: Remove python Remove CMake Remove DirectX SDK (June 2008) Remove studio .net 2003 Remove Visual J# redist pack 1.1 Remove Visual C++ 2005 redist Remove 2005 Express Edition Remove MSDN Library for NET 2003 Remove MS Platform SDK R2 Registry cleanout: Remove HKCU\Software\Microsoft\ - MSDN - VCExpress - VisualStudio - VSA - VSCommon Remove HKLM\Software\Microsoft\ - MSDN - VisualStudio - VSA - VSTA - VSTAHost - VSTAHostConfig - VSWCU I had both VS 2005 Express and VS 2003 Standard installed at the same time. I don't know if they can conflict with each other.. From dmahalko at gmail.com Sat Jul 19 00:50:33 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jul 19 00:50:34 2008 Subject: [sldev] Documenting the viewer source In-Reply-To: <487FCF28.5040407@lindenlab.com> References: <487FCF28.5040407@lindenlab.com> Message-ID: This reminds me, is there some way to click on something in the source, and have Visual Studio tell me where that function or type definition is coming from? Half the problem of learning the source is just weaving through the deep web of libraries and typedefs that support the actual code. For example, any source file referencing "llcommon.h" drags along with it a laundry list of 50 or more inter-related source files and it's quite a chore to manually dig through them to find where a function or struct is defined. I waded through this deep web of llcommon includes way back when the client was first open-sourced.. https://wiki.secondlife.com/wiki/VFS_source_relationships#Common_source_elements I'd like to be able to just click on anything in the source like "S32" and have the compiler be able to respond with: 'The definition of "S32" originates in file \linden\indra\common\stdtypes.h, line 38.' And then have it offer to open that source reference in a new window and highlight the referenced line(s). This would permit the code to be more self-documenting. Can this be done? - Scalar Tardis / Dale Mahalko On Thu, Jul 17, 2008 at 6:00 PM, Rob Lanphier wrote: > In the meeting, there was a request for more documentation. We talked about > several things on this front: From danteferret at gmail.com Sat Jul 19 01:00:53 2008 From: danteferret at gmail.com (Dante Tucker) Date: Sat Jul 19 01:00:56 2008 Subject: [sldev] Documenting the viewer source In-Reply-To: References: <487FCF28.5040407@lindenlab.com> Message-ID: <4d211a610807190100x798934f5m2051764bcb89343f@mail.gmail.com> hmm.... Usualy i just right click on it, and it gives you options like that, to follow it through to where it was declared etc. On Sat, Jul 19, 2008 at 3:50 AM, Dale Mahalko wrote: > This reminds me, is there some way to click on something in the > source, and have Visual Studio tell me where that function or type > definition is coming from? Half the problem of learning the source is > just weaving through the deep web of libraries and typedefs that > support the actual code. > > For example, any source file referencing "llcommon.h" drags along with > it a laundry list of 50 or more inter-related source files and it's > quite a chore to manually dig through them to find where a function or > struct is defined. I waded through this deep web of llcommon includes > way back when the client was first open-sourced.. > > > https://wiki.secondlife.com/wiki/VFS_source_relationships#Common_source_elements > > > I'd like to be able to just click on anything in the source like "S32" > and have the compiler be able to respond with: > > 'The definition of "S32" originates in file > \linden\indra\common\stdtypes.h, line 38.' > > And then have it offer to open that source reference in a new window > and highlight the referenced line(s). > > > This would permit the code to be more self-documenting. Can this be done? > > - Scalar Tardis / Dale Mahalko > > > > On Thu, Jul 17, 2008 at 6:00 PM, Rob Lanphier wrote: > > In the meeting, there was a request for more documentation. We talked > about > > several things on this front: > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080719/0baf606b/attachment-0001.htm From suzhanna.rossini at balsaestates.com Sat Jul 19 03:20:14 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sat Jul 19 03:20:43 2008 Subject: SV: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> References: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> Message-ID: <006f01c8e989$09cbed50$1d63c7f0$@rossini@balsaestates.com> > > On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton > > wrote: > > > > > > > > > I've tracked this problem down to having version 2.6.0 of CMake > > installed > > > rather than 2.4.8. I'll put a note on the Wiki to emphasize it must > > be > > > 2.4.8. > > > > Ah! > > > > Suzhanna, could your problem be the same? *sigh* Time to go cry? I uninstalled cmake 2.6, and installed 2.4.8. Then I went to the indra directory and ran "develop.py -G VS2003 configure" (with a clean svn pull, all old deleted). I was met by this: C:\SLDev\linden\indra>develop.py -G VS2003 configure Running 'cmake -G "Visual Studio 7 .NET 2003" -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" "C:\\SLDev\\linden\\indra"' in 'build-VS2003' -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- broken CMake Error: The C compiler "C:/Program Files (x86)/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe" is not able to compile a simple test program. It fails with the following output: Microsoft (R) Development Environment Version 7.10.6030. Copyright (C) Microsoft Corp 1984-2001. All rights reserved. ------ Build started: Project: cmTryCompileExec, Configuration: Debug Win32 ------ Compiling... Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTCs /MDd /GS /Fo"cmTryCompileExec.dir\Debug\\" /Fd"C:/SLDev/linden/indra/build-VS2003/CMakeFiles/CMakeTmp/Debug/cmTryCompil eExec.pdb" /W3 /c /Zi /TC /Zm1000 ".\testCCompiler.c" testCCompiler.c Linking... link: missing operand after `@c:\\SLDev\\linden\\indra\\build-VS2003\\CMakeFiles\\CMakeTmp\\cmTryCompile Exec.dir\\Debug\\RSP000002.rsp' Try `link --help' for more information. cmTryCompileExec : error PRJ0002 : error result returned from 'link.exe'. Build log was saved at "file://c:\SLDev\linden\indra\build-VS2003\CMakeFiles\CMakeTmp\cmTryCompileE xec.dir\Debug\BuildLog.htm" cmTryCompileExec - 1 error(s), 0 warning(s) ---------------------- Done ---------------------- Build: 0 succeeded, 1 failed, 0 skipped CMake will not be able to correctly generate this project. -- Configuring done Cleaning 'build-VS2003' Error: the command 'cmake' exited with -1 Seems like cmake's own tests won't run even. And there are no traces of the "build-2003" since it was cleaned out. I'm starting to wonder if this can be related to the fact that I'm running this all on a 64-bit edition of Windows 2003. I'll make a completely new installation of a 32-bit Windows just to either eliminate or confirm that the problem may be there. Alexandra. From bill.hoffman at kitware.com Sat Jul 19 04:30:41 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Sat Jul 19 04:31:27 2008 Subject: SV: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <006f01c8e989$09cbed50$1d63c7f0$@rossini@balsaestates.com> References: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> <006f01c8e989$09cbed50$1d63c7f0$@rossini@balsaestates.com> Message-ID: <4881D061.5020607@kitware.com> Suzhanna Rossini wrote: > Compiling... > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86 > Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. > cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D > "_MBCS" /FD /RTCs /MDd /GS /Fo"cmTryCompileExec.dir\Debug\\" > /Fd"C:/SLDev/linden/indra/build-VS2003/CMakeFiles/CMakeTmp/Debug/cmTryCompil > eExec.pdb" /W3 /c /Zi /TC /Zm1000 > ".\testCCompiler.c" > testCCompiler.c > Linking... > link: missing operand after > `@c:\\SLDev\\linden\\indra\\build-VS2003\\CMakeFiles\\CMakeTmp\\cmTryCompile > Exec.dir\\Debug\\RSP000002.rsp' > Try `link --help' for more information. > cmTryCompileExec : error PRJ0002 : error result returned from 'link.exe'. > You have link.exe from cygwin in your path. It is not a linker, but rather creates symbolic links. I usually remove this file from my cygwin bin directory or rename it to linkcygwin.exe -Bill From suzhanna.rossini at balsaestates.com Sat Jul 19 04:40:13 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sat Jul 19 04:40:30 2008 Subject: SV: SV: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <4881D061.5020607@kitware.com> References: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> <006f01c8e989$09cbed50$1d63c7f0$@rossini@balsaestates.com> <4881D061.5020607@kitware.com> Message-ID: <007b01c8e994$36a454b0$a3ecfe10$@rossini@balsaestates.com> > Suzhanna Rossini wrote: > > > Compiling... > > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for > 80x86 > > Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. > > cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D > "CMAKE_INTDIR=\"Debug\"" /D > > "_MBCS" /FD /RTCs /MDd /GS /Fo"cmTryCompileExec.dir\Debug\\" > > /Fd"C:/SLDev/linden/indra/build- > VS2003/CMakeFiles/CMakeTmp/Debug/cmTryCompil > > eExec.pdb" /W3 /c /Zi /TC /Zm1000 > > ".\testCCompiler.c" > > testCCompiler.c > > Linking... > > link: missing operand after > > `@c:\\SLDev\\linden\\indra\\build- > VS2003\\CMakeFiles\\CMakeTmp\\cmTryCompile > > Exec.dir\\Debug\\RSP000002.rsp' > > Try `link --help' for more information. > > cmTryCompileExec : error PRJ0002 : error result returned from > 'link.exe'. > > > You have link.exe from cygwin in your path. It is not a linker, but > rather creates symbolic links. I usually remove this file from my > cygwin bin directory or rename it to linkcygwin.exe > > -Bill Oh dear.. I guess I *did* have too much wine last night! You're right.. Seems to work fine now, I'll get back when I've run a build to see if the linking works better now than with cmake 2.6 Alexandra. From suzhanna.rossini at balsaestates.com Sat Jul 19 07:30:57 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sat Jul 19 07:31:18 2008 Subject: SV: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> References: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> Message-ID: <008901c8e9ac$10fea630$32fbf290$@rossini@balsaestates.com> > > On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton > > wrote: > > > > > > > > > I've tracked this problem down to having version 2.6.0 of CMake > > installed > > > rather than 2.4.8. I'll put a note on the Wiki to emphasize it must > > be > > > 2.4.8. > > > > Ah! > > > > Suzhanna, could your problem be the same? > Now then.. I reverted from cmake 2.6.0 to cmake 2.4.8 and the build is running just clean and fine on VS2003. So the problem seems to be in the cmake process. Alexandra. From lenglish5 at cox.net Sat Jul 19 09:33:55 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 19 09:33:57 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: References: <89ca6da00807130819m5b7e9658w357b95c478db0442@mail.gmail.com> <8DD5B0A8-EB57-4308-BFF2-1835C48A68DF@lindenlab.com> <89ca6da00807131245n9aa7902g1001d5e82673ea63@mail.gmail.com> <89ca6da00807151929o57b51774pb13b4ecdb37944c4@mail.gmail.com> <1278.75.33.197.92.1216180496.squirrel@mail.lindenlab.com> <89ca6da00807161808j73a27684q326212e9dac612a6@mail.gmail.com> <01C105FB-EA7C-4C5E-8A34-A371AAA65A92@lindenlab.com> <89ca6da00807171905p2897e83drb37a7e35b63a0ae4@mail.gmail.com> Message-ID: <48821773.7090202@cox.net> Karl Stiefvater wrote: >> But you could say the same about _INVERT. When would you need both >> normal and inverted) versions in a scene > > oh oh oh - i understand now. there actually IS a good use case for > the INVERT flag: > > both planar and cylindrical sculpties are "invisible" from the > backside. (this is typical of 3d meshes, and desirable, i think.) > > but when making a sail or a piece of paper, you want a backside too. > and now you can - with that INVERT flag. > > thus far, content creators have been making a second inverted sculpt > map to achieve this end - now they can use the same map, and so INVERT > is very similar to MIRROR in that it reduces the number of necessary > maps. > > >> You are more than welcome to rubber stamp this "PENDING CROQUET >> BECOMING AN OLYMPIC SPORT AGAIN" and I won't take offense. > > HEY! i was on my college croquet team. IT'S A REAL SPORT. > > :) > > Bring back Olympic Indian Clubbing. In fact, make juggling an Olympic sport, period! Lawson From dmahalko at gmail.com Sat Jul 19 10:06:43 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Jul 19 10:06:46 2008 Subject: [sldev] Documenting the viewer source In-Reply-To: <4d211a610807190100x798934f5m2051764bcb89343f@mail.gmail.com> References: <487FCF28.5040407@lindenlab.com> <4d211a610807190100x798934f5m2051764bcb89343f@mail.gmail.com> Message-ID: After doing some more testing, I see that right-clicking on a definition like "F32" only works within "llcommon.vcproj", but does not work in other projects such as "newview.vcproj". If it's supposed to "just work" then I probably don't have VS2003 set up correctly, and something needs to be done to make VS2003 load all these projects simultaneously or tell it to look across all the various project files to find source definitions across all of them. ------------------------------------ Fresh reinstall of VS2003 on Windows XP: 1. Create working directory "C:\SL_Viewer_Builds\1_20_12_RC" 2. 7-Zip: Unzip "slviewer-src-Branch_1-20-Viewer-2-r90824.zip" to here 3. 7-Zip: Unzip "slviewer-artwork-Branch_1-20-Viewer-2-r90824.zip" to here 4. 7-Zip: Unzip "slviewer-win32-libs-Branch_1-20-Viewer-2-r90824.zip" to here 5. Copy the additional 3rd party libs into here (Fmod, Qucktime) 6. Open VS2003, open project "\linden\indra\newview\newview.vcproj" Solution "Newview" -> expand "Source Files" -> open "llagent.cpp" at top as random test subject In section: // Mousewheel camera zoom const F32 MIN_ZOOM_FRACTION = 0.25f; const F32 INITIAL_ZOOM_FRACTION = 1.f; Right-click on "F32", select "Go to Definition" *** ERROR: Microsoft Development Environment / The symbol 'F32' is not defined. Right-click on "F32", select "Go to Declaration" *** ERROR: Microsoft Development Environment / The symbol 'F32' is not defined. ----------------------------------------------- In project "linden\indra\llcommon\llcommon.vcproj", if I right-click on "F32" in "llapp.cpp", and select "go to definition" or "go to declaration", it does open stdtypes.h and jump to the referenced line. Having llcommon.vcproj open in another window has no effect on the newview project. It still says "not defined" if I right-click on F32 in llagent.cpp in newview.vcproj. - Scalar Tardis / Dale Mahalko On Sat, Jul 19, 2008 at 3:00 AM, Dante Tucker wrote: > hmm.... Usualy i just right click on it, and it gives you options like that, > to follow it through to where it was declared etc. > From soft at lindenlab.com Sat Jul 19 10:26:51 2008 From: soft at lindenlab.com (Soft) Date: Sat Jul 19 10:26:53 2008 Subject: [sldev] Making symbol browsing work across projects in VS Message-ID: It's easy to forget - but if something veers this far off the original topic, please consider changing the subject line. It can easily grow to dwarf and kill the original topic. On Sat, Jul 19, 2008 at 12:06 PM, Dale Mahalko wrote: > After doing some more testing, I see that right-clicking on a > definition like "F32" only works within "llcommon.vcproj", but does > not work in other projects such as "newview.vcproj". > > If it's supposed to "just work" then I probably don't have VS2003 set > up correctly, and something needs to be done to make VS2003 load all > these projects simultaneously or tell it to look across all the > various project files to find source definitions across all of them. > > ------------------------------------ > > Fresh reinstall of VS2003 on Windows XP: > > 1. Create working directory "C:\SL_Viewer_Builds\1_20_12_RC" > 2. 7-Zip: Unzip "slviewer-src-Branch_1-20-Viewer-2-r90824.zip" to here > 3. 7-Zip: Unzip "slviewer-artwork-Branch_1-20-Viewer-2-r90824.zip" to here > 4. 7-Zip: Unzip "slviewer-win32-libs-Branch_1-20-Viewer-2-r90824.zip" to here > 5. Copy the additional 3rd party libs into here (Fmod, Qucktime) > 6. Open VS2003, open project "\linden\indra\newview\newview.vcproj" > > Solution "Newview" -> expand "Source Files" -> open "llagent.cpp" at > top as random test subject > > In section: > // Mousewheel camera zoom > const F32 MIN_ZOOM_FRACTION = 0.25f; > const F32 INITIAL_ZOOM_FRACTION = 1.f; > > Right-click on "F32", select "Go to Definition" > *** ERROR: Microsoft Development Environment / The symbol 'F32' is not defined. > > Right-click on "F32", select "Go to Declaration" > *** ERROR: Microsoft Development Environment / The symbol 'F32' is not defined. > > ----------------------------------------------- > > In project "linden\indra\llcommon\llcommon.vcproj", if I right-click > on "F32" in "llapp.cpp", and select "go to definition" or "go to > declaration", it does open stdtypes.h and jump to the referenced line. > > Having llcommon.vcproj open in another window has no effect on the > newview project. It still says "not defined" if I right-click on F32 > in llagent.cpp in newview.vcproj. > > > - Scalar Tardis / Dale Mahalko > > > > On Sat, Jul 19, 2008 at 3:00 AM, Dante Tucker wrote: >> hmm.... Usualy i just right click on it, and it gives you options like that, >> to follow it through to where it was declared etc. >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From jacek.antonelli at gmail.com Sat Jul 19 15:11:54 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sat Jul 19 15:11:57 2008 Subject: [sldev] Re: New Sculpty Features In-Reply-To: <2CE7890A-97CF-4CB6-8553-9BEA611332CA@lindenlab.com> References: <20080716190030.0976C41B2FC@stupor.lindenlab.com> <2CE7890A-97CF-4CB6-8553-9BEA611332CA@lindenlab.com> Message-ID: <105c09f0807191511t3cf893c7lfb58f67af3c412ab@mail.gmail.com> On Wed, Jul 16, 2008 at 2:16 PM, Karl Stiefvater wrote: > 3) most practically - by simply rotating the model first before you generate > the sculpt map, you can effectively mirror along ANY plane (not just the X, > Y, and Z planes.) this is the preferred method since it gives you more > freedom. (and as such, you can see how a single mirror option is more > "fundamental" than the other ones.) I was all confused about this. "What's so special about the X axis?" I was imagining the use case as existing sculpties being the target for this feature (in other words, sculpties that were designed without consideration for axis orientation). But then it hit me that it's more about _new_ sculpties, which can be designed with this feature in mind (or old ones that can be updated). It's true that in the vast majority of cases where symmetric sculpties are wanted, they're symmetric on a single axis. *brain goes "click"* So I see now, and agree that a single axis is "sufficient" for almost all uses. For special cases where it's not... well, they'll just have to fall back on the manual mirroring-before-export that we do now. > it really has nothing to do with the extra two characters "_X". :) Really? I pictured you going, "I'd sure love to add Y and Z... but then I'd have to type two extra characters. Meh." Hehe. ;-D Just out of curiosity (and because it _would_ be kinda handy), how much effort would it be for someone to add Y and Z? Is it something that could be added further down the road without a big fuss? I could picture it possibly being really easy (copy & paste, swap two cells in a transform matrix or such), but maybe I'm just being na?ve. :-) - Jacek From suzhanna.rossini at balsaestates.com Sun Jul 20 05:05:25 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sun Jul 20 05:05:53 2008 Subject: SV: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <008901c8e9ac$10fea630$32fbf290$@rossini@balsaestates.com> References: <001e01c8e8fd$ea43c920$becb5b60$@rossini@balsaestates.com> <008901c8e9ac$10fea630$32fbf290$@rossini@balsaestates.com> Message-ID: <004601c8ea60$e56fd290$b04f77b0$@rossini@balsaestates.com> > > > On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton zing.co.uk> > > > wrote: > > > > > > > > > > > > I've tracked this problem down to having version 2.6.0 of CMake > > > installed > > > > rather than 2.4.8. I'll put a note on the Wiki to emphasize it > must > > > be > > > > 2.4.8. > > > > > > Ah! > > > > > > Suzhanna, could your problem be the same? > > > > > Now then.. I reverted from cmake 2.6.0 to cmake 2.4.8 and the build is > running just clean and fine on VS2003. > So the problem seems to be in the cmake process. Changing from cmake 2.6 to 2.4.8 also made it possible to build clean on VS2008, however, the resulting application refuse to start, and generates this in the log: 2008-07-20T11:53:59Z ../../llrender/llimagegl.cpp(929) : error 2008-07-20T11:53:59Z ERROR: LLImageGL::createGLTexture: LLImageGL::createGLTexture failed to make texture Anyone with an idea on what to look for to isolate that error? The same source tree makes an executable that runs fine when compiled with VS2003. /Alexandra From robin.cornelius at gmail.com Sun Jul 20 05:23:28 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Jul 20 05:23:50 2008 Subject: [sldev] [VWR] 64bit Nvidia GL Corruption (sometimes) Message-ID: <48832E40.4030504@gmail.com> Hi everyone, After beating this around in IRC (thanks Carjay), i wanted to see if anyone else had a clue what is going on (possibly some graphcis devs?) The issue is VWR-8194 that I and one other person i know is seeing. We are both 64bit Linux NVidia, me a 7100 and Louise a 8600. Other people with 64bit and Nvidia don't have this issue. I have tried nvidia drivers 173.14.09 and 169.12 and both have the same results. Its related to the drawing of Silhouettes for selected objects by the selectmgr and in particular void LLSelectNode::renderOneSilhouette(const LLColor4 &color). Now it seems that if mSilhouetteSegments.size() is > 660 corruption will occur *everytime* This is only the case for tortured prims and sculpts where the shape is complex so the twisting or sculpting adds a high number of nodes. Linked multiple prims call the renderOneSilhouette multiple times so it runs multiple gl push/pop matrix and all is fine. If i create primms with less segments than 660 and select them its all fine, if i clamp the for loop to 660 its all fine too. I would guess that the gl push/pop matrix does not like too many things on its stack at once? I have to wonder if this is present on other systems but only causing very mild effects such as the occasional random crash? I have not seen this on 32bit builds at all. I am also not sure if the fault is the viewer or the nvidia gl library (maybe just the 64 bit version?) but this is also strange that its not been widely seen. Anyone have a clue what is going on? Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080720/b770443d/signature.pgp From soft at lindenlab.com Sun Jul 20 07:43:57 2008 From: soft at lindenlab.com (Soft) Date: Sun Jul 20 07:43:59 2008 Subject: [sldev] SV: Missing cares, apr in Mac build In-Reply-To: <-1016822099275429252@unknownmsgid> References: <-1016822099275429252@unknownmsgid> Message-ID: On Sun, Jul 20, 2008 at 7:05 AM, Suzhanna Rossini wrote: >> > > On Fri, Jul 18, 2008 at 12:11 PM, Aimee Walton > zing.co.uk> >> > > wrote: >> > > > >> > > > >> > > > I've tracked this problem down to having version 2.6.0 of CMake >> > > installed >> > > > rather than 2.4.8. I'll put a note on the Wiki to emphasize it >> must >> > > be >> > > > 2.4.8. >> > > >> > > Ah! >> > > >> > > Suzhanna, could your problem be the same? >> > >> >> >> Now then.. I reverted from cmake 2.6.0 to cmake 2.4.8 and the build is >> running just clean and fine on VS2003. >> So the problem seems to be in the cmake process. > > > Changing from cmake 2.6 to 2.4.8 also made it possible to build clean on > VS2008, however, the resulting application refuse to start, and generates > this in the log: > > 2008-07-20T11:53:59Z ../../llrender/llimagegl.cpp(929) : error > 2008-07-20T11:53:59Z ERROR: LLImageGL::createGLTexture: > LLImageGL::createGLTexture failed to make texture > > Anyone with an idea on what to look for to isolate that error? The same > source tree makes an executable that runs fine when compiled with VS2003. I believe you said you were adding lldku. I would try removing llkdu.dll and the three copy rules for those in copy_win_libs - just delete them from the tree. This will make the viewer fall back on built-in openjpeg support. llkdu.dll incorporates a closed source library we can't redistribute, and it's also built against LLImage and other open source classes. This causes problems if the resulting LLImage in the project and the one in the DLL are built in incompatible ways. Different STL implementations and a different virtual function ABI are likely with the VS2003 to VS2008 change. From suzhanna.rossini at balsaestates.com Sun Jul 20 10:51:32 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sun Jul 20 10:51:54 2008 Subject: [sldev] LLImageGL::createGLTexture failed to make texture In-Reply-To: References: <-1016822099275429252@unknownmsgid> Message-ID: <009101c8ea91$3ff90120$bfeb0360$@rossini@balsaestates.com> [snip] > > Changing from cmake 2.6 to 2.4.8 also made it possible to build clean > on > > VS2008, however, the resulting application refuse to start, and > generates > > this in the log: > > > > 2008-07-20T11:53:59Z ../../llrender/llimagegl.cpp(929) : error > > 2008-07-20T11:53:59Z ERROR: LLImageGL::createGLTexture: > > LLImageGL::createGLTexture failed to make texture > > > > Anyone with an idea on what to look for to isolate that error? The > same > > source tree makes an executable that runs fine when compiled with > VS2003. > > I believe you said you were adding lldku. I would try removing > llkdu.dll and the three copy rules for those in copy_win_libs - just > delete them from the tree. This will make the viewer fall back on > built-in openjpeg support. > > llkdu.dll incorporates a closed source library we can't redistribute, > and it's also built against LLImage and other open source classes. > This causes problems if the resulting LLImage in the project and the > one in the DLL are built in incompatible ways. Different STL > implementations and a different virtual function ABI are likely with > the VS2003 to VS2008 change. Unfortunately that did no difference. I removed all references to llkdu in all files, made a complete rebuild, and was met by the very same error. No really big deal though, I can get by using my friends VS2003 and/or VS2005 instead. Unless you folks want me to stick to VS2008 and try to find the reason for this error. Log file: 2008-07-20T17:45:50Z INFO: viewer_windows_exception_handler: Entering Windows Exception Handler... 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Handle viewer crash entry. 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Creating crash marker file C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_marker 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Created crash marker file C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_marker 2008-07-20T17:45:53Z ../../llrender/llimagegl.cpp(929) : error 2008-07-20T17:45:53Z ERROR: LLImageGL::createGLTexture: LLImageGL::createGLTexture failed to make texture From soft at lindenlab.com Sun Jul 20 10:57:30 2008 From: soft at lindenlab.com (Soft) Date: Sun Jul 20 10:57:32 2008 Subject: [sldev] Re: LLImageGL::createGLTexture failed to make texture In-Reply-To: <6321950751326938096@unknownmsgid> References: <-1016822099275429252@unknownmsgid> <6321950751326938096@unknownmsgid> Message-ID: On Sun, Jul 20, 2008 at 12:51 PM, Suzhanna Rossini wrote: > [snip] >> > Changing from cmake 2.6 to 2.4.8 also made it possible to build clean >> on >> > VS2008, however, the resulting application refuse to start, and >> generates >> > this in the log: >> > >> > 2008-07-20T11:53:59Z ../../llrender/llimagegl.cpp(929) : error >> > 2008-07-20T11:53:59Z ERROR: LLImageGL::createGLTexture: >> > LLImageGL::createGLTexture failed to make texture >> > >> > Anyone with an idea on what to look for to isolate that error? The >> same >> > source tree makes an executable that runs fine when compiled with >> VS2003. >> >> I believe you said you were adding lldku. I would try removing >> llkdu.dll and the three copy rules for those in copy_win_libs - just >> delete them from the tree. This will make the viewer fall back on >> built-in openjpeg support. >> >> llkdu.dll incorporates a closed source library we can't redistribute, >> and it's also built against LLImage and other open source classes. >> This causes problems if the resulting LLImage in the project and the >> one in the DLL are built in incompatible ways. Different STL >> implementations and a different virtual function ABI are likely with >> the VS2003 to VS2008 change. > > > Unfortunately that did no difference. I removed all references to llkdu in > all files, made a complete rebuild, and was met by the very same error. > No really big deal though, I can get by using my friends VS2003 and/or > VS2005 instead. Unless you folks want me to stick to VS2008 and try to find > the reason for this error. If it makes you itchy, by all means go for it - it would be useful to know. But follow whatever interests you most. Nobody's handing out assignments here. :) From kelly at lindenlab.com Sun Jul 20 10:59:45 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Sun Jul 20 10:59:47 2008 Subject: [sldev] LLImageGL::createGLTexture failed to make texture In-Reply-To: <009101c8ea91$3ff90120$bfeb0360$@rossini@balsaestates.com> References: <-1016822099275429252@unknownmsgid> <009101c8ea91$3ff90120$bfeb0360$@rossini@balsaestates.com> Message-ID: <48837D11.4010703@lindenlab.com> Suzhanna Rossini wrote: > Unfortunately that did no difference. I removed all references to llkdu in > all files, made a complete rebuild, and was met by the very same error. > No really big deal though, I can get by using my friends VS2003 and/or > VS2005 instead. Unless you folks want me to stick to VS2008 and try to find > the reason for this error. > > Log file: > 2008-07-20T17:45:50Z INFO: viewer_windows_exception_handler: Entering > Windows Exception Handler... > 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Handle viewer > crash entry. > 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Creating crash > marker file > C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_marker > 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Created crash > marker file > C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_marker > 2008-07-20T17:45:53Z ../../llrender/llimagegl.cpp(929) : error > 2008-07-20T17:45:53Z ERROR: LLImageGL::createGLTexture: > LLImageGL::createGLTexture failed to make texture > > > What parameters are you starting the viewer with? As bizzare as this is, I got that error (or one very similar) when building with VS2003 due to some bad command line parameters. Specifically in my case I was doing "--multiple true" when it needs to be "--multiple". I'm not quite sure what the connection between bad args and LLImageGL is though. -- Kelly From suzhanna.rossini at balsaestates.com Mon Jul 21 00:21:30 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Mon Jul 21 00:21:46 2008 Subject: SV: [sldev] LLImageGL::createGLTexture failed to make texture In-Reply-To: <48837D11.4010703@lindenlab.com> References: <-1016822099275429252@unknownmsgid> <009101c8ea91$3ff90120$bfeb0360$@rossini@balsaestates.com> <48837D11.4010703@lindenlab.com> Message-ID: <00c101c8eb02$66a0b810$33e22830$@rossini@balsaestates.com> > Suzhanna Rossini wrote: > > Unfortunately that did no difference. I removed all references to > llkdu in > > all files, made a complete rebuild, and was met by the very same > error. > > No really big deal though, I can get by using my friends VS2003 > and/or > > VS2005 instead. Unless you folks want me to stick to VS2008 and try > to find > > the reason for this error. > > > > Log file: > > 2008-07-20T17:45:50Z INFO: viewer_windows_exception_handler: Entering > > Windows Exception Handler... > > 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Handle > viewer > > crash entry. > > 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Creating > crash > > marker file > > > C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_mar > ker > > 2008-07-20T17:45:53Z INFO: LLAppViewer::handleViewerCrash: Created > crash > > marker file > > > C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_mar > ker > > 2008-07-20T17:45:53Z ../../llrender/llimagegl.cpp(929) : error > > 2008-07-20T17:45:53Z ERROR: LLImageGL::createGLTexture: > > LLImageGL::createGLTexture failed to make texture > > > > > > > What parameters are you starting the viewer with? As bizzare as this > is, I got that error (or one very similar) when building with VS2003 > due > to some bad command line parameters. Specifically in my case I was > doing "--multiple true" when it needs to be "--multiple". I'm not > quite sure what the connection between bad args and LLImageGL is > though. Actually, none. I use the shortcut created be the installer, and it doesn't add anything to the command line, it's only the .exe file. Just to test, I added my "normal" command line so it contains this "C:\Program Files (x86)\SecondLifeMyBuild\SecondLife.exe" -set SystemLanguage en-us But that didn't make any difference. Alexandra From robin.cornelius at gmail.com Mon Jul 21 01:01:53 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jul 21 01:01:56 2008 Subject: [sldev] LLImageGL::createGLTexture failed to make texture In-Reply-To: <1962604557406926432@unknownmsgid> References: <-1016822099275429252@unknownmsgid> <48837D11.4010703@lindenlab.com> <1962604557406926432@unknownmsgid> Message-ID: On Mon, Jul 21, 2008 at 8:21 AM, Suzhanna Rossini wrote: > Actually, none. I use the shortcut created be the installer, and it doesn't > add anything to the command line, it's only the .exe file. Just to test, I > added my "normal" command line so it contains this "C:\Program Files > (x86)\SecondLifeMyBuild\SecondLife.exe" -set SystemLanguage en-us > But that didn't make any difference. > Jumping head first and a bit late here ;-) What context is the error in the log appearing, i mean at what point, what messages are directly before. I'm just trying to see where in the startup it is occurring. My guess is that the viewer is not finding the default artwork files due to some misconfiguration in the VS environment. I know the viewer will blow this way if certain artwork is missing. Robin From suzhanna.rossini at balsaestates.com Mon Jul 21 01:11:12 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Mon Jul 21 01:11:31 2008 Subject: SV: [sldev] LLImageGL::createGLTexture failed to make texture In-Reply-To: References: <-1016822099275429252@unknownmsgid> <48837D11.4010703@lindenlab.com> <1962604557406926432@unknownmsgid> Message-ID: <000001c8eb09$59080530$0b180f90$@rossini@balsaestates.com> > On Mon, Jul 21, 2008 at 8:21 AM, Suzhanna Rossini > wrote: > > > Actually, none. I use the shortcut created be the installer, and it > doesn't > > add anything to the command line, it's only the .exe file. Just to > test, I > > added my "normal" command line so it contains this "C:\Program Files > > (x86)\SecondLifeMyBuild\SecondLife.exe" -set SystemLanguage en-us > > But that didn't make any difference. > > > > > Jumping head first and a bit late here ;-) > > What context is the error in the log appearing, i mean at what point, > what messages are directly before. I'm just trying to see where in the > startup it is occurring. > > My guess is that the viewer is not finding the default artwork files > due to some misconfiguration in the VS environment. I know the viewer > will blow this way if certain artwork is missing. > > Robin I never get any screen output at all, nothing. Just the Windows "wait" cursor, and then it dies... Here's the complete log that's generated.. 2008-07-21T07:21:15Z INFO: LLAppViewer::initConfiguration: Loading settings file listC:\Program Files (x86)\SecondLifeMyBuild\app_settings\settings_files.xml 2008-07-21T07:21:15Z INFO: LLAppViewer::loadSettingsFromDirectory: Loaded settings file C:\Program Files (x86)\SecondLifeMyBuild\app_settings\settings_crash_behavior.xml 2008-07-21T07:21:16Z INFO: LLAppViewer::loadSettingsFromDirectory: Loaded settings file C:\Program Files (x86)\SecondLifeMyBuild\app_settings\settings.xml 2008-07-21T07:21:16Z INFO: LLAppViewer::loadSettingsFromDirectory: Loaded settings file C:\Program Files (x86)\SecondLifeMyBuild\app_settings\settings_per_account.xml 2008-07-21T07:21:16Z INFO: viewer_windows_exception_handler: Entering Windows Exception Handler... 2008-07-21T07:21:17Z INFO: LLAppViewer::handleViewerCrash: Handle viewer crash entry. 2008-07-21T07:21:17Z INFO: LLAppViewer::handleViewerCrash: Creating crash marker file C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_marker 2008-07-21T07:21:17Z INFO: LLAppViewer::handleViewerCrash: Created crash marker file C:\Users\alexandra\AppData\Roaming\SecondLife\logs\SecondLife.error_marker 2008-07-21T07:21:18Z ../../llrender/llimagegl.cpp(929) : error 2008-07-21T07:21:18Z ERROR: LLImageGL::createGLTexture: LLImageGL::createGLTexture failed to make texture And attached you'll find the exception log... Alexandra -------------- next part -------------- A non-text attachment was scrubbed... Name: SecondLifeException.log Type: application/octet-stream Size: 21496 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080721/4cc53a8f/SecondLifeException-0001.obj From lenglish5 at cox.net Mon Jul 21 01:37:18 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Jul 21 01:37:20 2008 Subject: [sldev] [ANN][AWG] Daily pygop meetings now MWF Message-ID: <48844ABE.3000506@cox.net> Our first week of meetings went well. We had 3 in a row, then decided there were too many conflicts with relevant office hours, and changed the schedule to MWF, where Fridays do double duty as pygop + Enus Linden's office hours. http://wiki.secondlife.com/wiki/Category:Pyogp_Transcripts And so we start this week with a pyogp meeting on Monday 9:30AM SLT and the new schedule should continue indefinitely... what PyOGP Coders Meeting who PyOGP l33t C0d3rZ where "infinity is full of stars" @ http://slurl.com/secondlife/Levenhall/91/208/22 when 9:30AM SLT / 12:30PM Eastern Time / 5:30PM GMT / 6:30PM Central European Time why for PyOGP contributors to hash out architecture, design, test and deploy issues IRC: irc://irc.freenode.com/#pyogp Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp wiki: http://wiki.secondlife.com/wiki/Pyogp transcripts: http://wiki.secondlife.com/wiki/Category:Pyogp_Transcripts Lawson From chaosstar at gmail.com Mon Jul 21 02:40:11 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Jul 21 02:40:14 2008 Subject: [sldev] LLString, char -> std::string Message-ID: <9bb32d430807210240h42afdb20w5490ac60c69beb15@mail.gmail.com> Greetings, This is not a question or inquiry per se, more a notification to the client tinkerers and source enthusiasts that may not have kept up with the latest changes in the release branch of the client on the SVN. Currently there seems to be a major overhaul of the String handling in the source. I'm quite impressed. All LLString occurances and char variables/pointers seem to be getting replaced by the C++ Standard library string type, and the old snprintf's are being replaced by direct value assignments. Major Kudos to LL on that decision. I'm really glad this is being done finally. That is all. Hope the list was the right spot to do this :3 --Chalice Yao From blindwanderer at gmail.com Mon Jul 21 03:32:35 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Mon Jul 21 03:32:38 2008 Subject: [sldev] LLString, char -> std::string In-Reply-To: <9bb32d430807210240h42afdb20w5490ac60c69beb15@mail.gmail.com> References: <9bb32d430807210240h42afdb20w5490ac60c69beb15@mail.gmail.com> Message-ID: <89ca6da00807210332x6f00d561s9cf202eca2fd21ae@mail.gmail.com> I've been watching this go on (i keep an eye on the SVN). Kinda annoying though, "oh look a new revision" "oh poo, it's just refactoring, snooze" Strife Onizuka On Mon, Jul 21, 2008 at 5:40 AM, Ambrosia wrote: > Greetings, > > This is not a question or inquiry per se, more a notification to the client > tinkerers and source enthusiasts that may not have kept up with the > latest changes in the release branch of the client on the SVN. > > Currently there seems to be a major overhaul of the String handling > in the source. I'm quite impressed. All LLString occurances and > char variables/pointers seem to be getting replaced by the C++ Standard > library string type, and the old snprintf's are being replaced by direct > value > assignments. > > Major Kudos to LL on that decision. I'm really glad this is being done > finally. > > That is all. Hope the list was the right spot to do this :3 > > --Chalice Yao > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080721/f5fa32c6/attachment.htm From bill.hoffman at kitware.com Mon Jul 21 06:20:36 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon Jul 21 06:21:25 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> Message-ID: <48848D24.7060909@kitware.com> Aimee Walton wrote: >> >> Sure, that is a warning, does the build still work? > > Sorry, not my most useful reply ever, I'll blame lack of sleep. > > We have > target_link_libraries(myexe /path/to/foo) > > Which is working on 2.4 as it splits to give -lfoo > > However on 2.6 it breaks the build, as it uses /path/to/foo when it > really needs /path/to/libfoo.a > > AImee. > > Could someone please clarify if this was working on makefile builds? You say it was /path/to/libfoo.a, and that implies linux/unix. I want to make sure this is not a new issue. As far as I know /path/to/foo always failed (even in CMake 2.4) for any makefile builds included nmake, and unix makefiles. The only time it worked was with the VS IDE. Thanks. -Bill From grant at lindenlab.com Mon Jul 21 12:49:37 2008 From: grant at lindenlab.com (Grant Linden) Date: Mon Jul 21 12:49:40 2008 Subject: [sldev] RX Office hours - Dusan Writer will review the interface contest panel presentations. Message-ID: <907af5560807211249q3c9c996dr7ad7a575d65ad984@mail.gmail.com> Dusan Writer will be our guest host for the RX Office Hours this week. Dusan will review the interface contest results, highlights of common elements, and join us for a discussion of the contest. Dusan plans to share 1-2 slides per entry and talk a bit about the panel presentations. Dusan's interface contest. http://dusanwriter.com/?p=603 Thursday July 24th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village ___ For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080721/7d1a0c63/attachment.htm From poppy at lindenlab.com Mon Jul 21 14:05:18 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Jul 21 14:05:09 2008 Subject: [sldev] [HELP] CMake: Problem with missing directory 'indra/viewer-linux-i686' In-Reply-To: <48810371.6000608@boroon.dasgupta.ch> References: <4873C378.1010802@boroon.dasgupta.ch> <48810371.6000608@boroon.dasgupta.ch> Message-ID: <4884FA0E.6040508@lindenlab.com> Boroondas Gupte wrote: > Boroondas Gupte schrieb: >>> ~/slsrc/svn/release/linden/indra $ *./develop.py* >>> Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >>> -G \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE >>> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >>> \'/home//slsrc/svn/release/linden/indra\'' in >>> 'viewer-linux-i686' >>> [...] >>> Writing state to >>> /home//slsrc/svn/release/linden/installed.xml >>> *CMake Error: Cannot find source file >>> "/home/**/slsrc/svn/release/linden/indra/viewer-linux-i686/newview/character/attentions.xml"* >>> >>> Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm >>> .hpp .hxx .in .txx >>> CMake Error: CMake failed to properly look up cmSourceFile: >>> character/attentions.xml >>> [...] >> The directory indra/viewer-linux-i686 doesn't exist, but I also can't >> find any file named attentions.xml anywhere else in the tree. > I'm on Linux (i686) and have cmake version 2.4-patch 8, if that should > matter. the indra/newview/characters folder isn't in http://svn.secondlife.com/trac/linden/browser/release/indra/newview it is in the art tarball. http://wiki.secondlife.com/wiki/Source_archive (cleverly hidden in the "source" column) + poppy From monkowsk at watson.ibm.com Mon Jul 21 15:01:09 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jul 21 15:01:15 2008 Subject: [sldev] Re: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4877F31B.1010404@lindenlab.com> References: <487779A4.2070309@watson.ibm.com> <4877C40F.2050901@lindenlab.com> <4877DB6B.4080105@watson.ibm.com> <4877F31B.1010404@lindenlab.com> Message-ID: <48850725.8050700@watson.ibm.com> Rob Lanphier wrote: > None of this is rocket science, but it all takes time, just like writing > this email takes time. ;-) Thanks. I believe it was time well spent. :-) Don't underestimate the value of open communication. Mike From sllists at boroon.dasgupta.ch Mon Jul 21 15:23:16 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Jul 21 15:23:20 2008 Subject: [sldev] [HELP] CMake: Problem with missing directory 'indra/viewer-linux-i686' In-Reply-To: <4884FA0E.6040508@lindenlab.com> References: <4873C378.1010802@boroon.dasgupta.ch> <48810371.6000608@boroon.dasgupta.ch> <4884FA0E.6040508@lindenlab.com> Message-ID: <48850C54.3020709@boroon.dasgupta.ch> Paul Oppenheim (Poppy Linden) schrieb: > the indra/newview/characters folder isn't in > http://svn.secondlife.com/trac/linden/browser/release/indra/newview > > it is in the art tarball. > http://wiki.secondlife.com/wiki/Source_archive > > (cleverly hidden in the "source" column) ah, thanks a lot. :-) Somehow I assumed that the script automatically pulling the library bundles would imply it also to catch the artwork by itself. Am I right, that for svn checkouts I better get the artwork URL from linden/doc/asset_urls.txt than guessing which source tarball version the svn revision might correspond to (if any)? Boroondas From poppy at lindenlab.com Mon Jul 21 15:34:17 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Jul 21 15:34:08 2008 Subject: [sldev] [HELP] CMake: Problem with missing directory 'indra/viewer-linux-i686' In-Reply-To: <48850C54.3020709@boroon.dasgupta.ch> References: <4873C378.1010802@boroon.dasgupta.ch> <48810371.6000608@boroon.dasgupta.ch> <4884FA0E.6040508@lindenlab.com> <48850C54.3020709@boroon.dasgupta.ch> Message-ID: <48850EE9.2020807@lindenlab.com> Boroondas Gupte wrote: > Paul Oppenheim (Poppy Linden) schrieb: >> the indra/newview/characters folder isn't in >> http://svn.secondlife.com/trac/linden/browser/release/indra/newview >> >> it is in the art tarball. >> http://wiki.secondlife.com/wiki/Source_archive >> >> (cleverly hidden in the "source" column) > ah, thanks a lot. :-) > Somehow I assumed that the script automatically pulling the library > bundles would imply it also to catch the artwork by itself. Am I right, > that for svn checkouts I better get the artwork URL from > linden/doc/asset_urls.txt than guessing which source tarball version the > svn revision might correspond to (if any)? That sounds like a patch I'd take if it doesn't do this already. I'm not that familiar with the downloader, but I don't see art in install.xml. + poppy From monkowsk at watson.ibm.com Mon Jul 21 15:41:42 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jul 21 15:41:47 2008 Subject: [sldev] Re: Speed of adopting open practices (Re: IJIRA and PJIRA) In-Reply-To: <4877E38F.7000106@lindenlab.com> References: <487779A4.2070309@watson.ibm.com><4877C40F.2050901@lindenlab.com> <4877DB6B.4080105@watson.ibm.com> <4877E38F.7000106@lindenlab.com> Message-ID: <488510A6.7040708@watson.ibm.com> OK, so you can't make the internal JIRA public and a switch to PJIRA seems to be impossible. You need to figure out a relatively simple first step if you want to get more out of open source bug fixing. How about a version of the SLJiraStats list http://www.sljirastats.com/jira_search.php?search=30 for the internal JIRA with as much information as can reasonably be made public? Obviously there would be no links to the internal JIRA issue details. Since it's not a direct access to the JIRA, you can filter the information as much as you like and display only the columns that you feel comfortable displaying, although I would hope that at least Linden ID, priority, status, assignee (can be just yes/no if you want), created, and updated would be there. I am also wondering if the internal JIRA has a link to the corresponding PJIRA issue that the LL developers can click on. My guess would be that it would be there, but the lack of participation by LL developers on PJIRA leads me to suspect that it is not. Mike Tofu Linden wrote: > Mike Monkowski wrote: > > You don't have to go full >> PJIRA all at once. Read-only IJIRA would be a big step forward, though > > I totally sympathise - we've been discussing the ramifications of an > integrated Jira since before the initial open-source release. There's > general agreement that an integrated Jira is desirable as a goal, BUT > for reasons Rob described - and more - this hasn't happened yet and > won't take the form of automatically throwing our old issues public as a > rule. > > We use our internal Jira for way, way more than technical bug-tracking, > plus I'm sure you understand that historical attached data and comments > written against issues for the context of internal consumption can > easily contain sensitive information concerning residents (i.e. contact > information, etc) which was never intended to leave Linden Lab. From monkowsk at watson.ibm.com Mon Jul 21 16:07:09 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jul 21 16:07:14 2008 Subject: [sldev] Documenting the viewer source In-Reply-To: <487FCF28.5040407@lindenlab.com> References: <487FCF28.5040407@lindenlab.com> Message-ID: <4885169D.7050907@watson.ibm.com> Rob Lanphier wrote: > * The need for better documentation on the wiki. I'd like to focus > your attention on this page: > https://wiki.secondlife.com/wiki/Viewer_Architecture > > The page in-and-of-itself isn't as important as all of the info it links > to. The "Viewer Architecture" page itself probably isn't above some > reorganization though, but most importantly, adding cross-links to > current information is something that anyone here could do. For > example, there's also this page: > https://wiki.secondlife.com/wiki/Viewer_Roadmap > > ...and it's subpages. The subpages of each of these could stand to be > cross-linked. Also there's this page: > https://wiki.secondlife.com/wiki/Viewer_Software_Overview > > ....which kinda duplicates Viewer Architecture, and the two should > probably be merged. A Linden can do this work (and I might just tackle > it), but hey, it's a wiki, and you all have the power. So, any volunteers? Actually, I like having Viewer Architecture and Viewer Software Overview separate. It's kind of a design versus implementation separation. But I did add the cross-links between the pages. The Viewer Roadmap links were already there. I still have to add a page for Culling, which I've had a rough draft of for several months now. :-) Mike From aimee at ama-zing.co.uk Mon Jul 21 19:16:58 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Jul 21 19:17:16 2008 Subject: [sldev] Mac Build Instructions / Universal / FMOD In-Reply-To: <4885169D.7050907@watson.ibm.com> References: <487FCF28.5040407@lindenlab.com> <4885169D.7050907@watson.ibm.com> Message-ID: OK, following the Mac build instructions to the letter there seems to be one remaining problem. TThe build instructions say to install the FMOD libraries with ... $ cp -p fmodapi375mac/api/inc/*.h linden/libraries/include $ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc- darwin/lib_debug $ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc- darwin/lib_release $ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386- darwin/lib_debug/libfmod.a $ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386- darwin/lib_release/libfmod.a Cmake however doesn't detect the fmod library there as it's only searching in linden/libraries/universal-darwin. This means it disables fmod and builds without libfmodwrapper ... which viewer_manifest.py then tries to copy ... and dies. Easiest solution seemed to be to create a fat library when doing the copy, changing the above to ... cp -p ../fmodapi375mac/api/inc/*.h linden/libraries/include lipo -create fmodapi375mac/api/lib/libfmod.a fmodapi375mac/api/lib/ libfmodx86.a -output linden/libraries/universal-darwin/lib_release/ libfmod.a cp -p linden/libraries/universal-darwin/lib_release/libfmod.a linden/ libraries/universal-darwin/lib_debug/libfmod.a Should I put that on the Wiki or is there another preferred solution? Aimee. PS. Still seem to be those few files missing from llrender in the featurettes-5 branch *Nudges Soft softly* :D blindly copying them over from release "seems" to work though at the moment. From sammy.frederix at gmail.com Mon Jul 21 20:17:51 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Mon Jul 21 20:27:15 2008 Subject: [sldev] Mac Build Instructions / Universal / FMOD In-Reply-To: References: <487FCF28.5040407@lindenlab.com> <4885169D.7050907@watson.ibm.com> Message-ID: <4AF5E431-7819-42F1-B071-F476C0EE45AF@gmail.com> I've been using lipo to create a universal library: $ cp -p fmodapi375mac/api/inc/*.h libraries/include $ lipo -create fmodapi375mac/api/lib/libfmod.a fmodapi375mac/api/lib/ libfmodx86.a -output libraries/universal-darwin/lib_debug/libfmod.a $ lipo -create fmodapi375mac/api/lib/libfmod.a fmodapi375mac/api/lib/ libfmodx86.a -output libraries/universal-darwin/lib_release/libfmod.a $ touch -r fmodapi375mac/api/lib/libfmod.a libraries/universal-darwin/ lib_debug/libfmod.a $ touch -r fmodapi375mac/api/lib/libfmod.a libraries/universal-darwin/ lib_release/libfmod.a (Beware of line wrapping) On 22/07/2008, at 12:16 PM, Aimee Walton wrote: > OK, following the Mac build instructions to the letter there seems > to be one remaining problem. TThe build instructions say to install > the FMOD libraries with ... > > $ cp -p fmodapi375mac/api/inc/*.h linden/libraries/include > $ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc- > darwin/lib_debug > $ cp -p fmodapi375mac/api/lib/libfmod.a linden/libraries/powerpc- > darwin/lib_release > $ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386- > darwin/lib_debug/libfmod.a > $ cp -p fmodapi375mac/api/lib/libfmodx86.a linden/libraries/i386- > darwin/lib_release/libfmod.a > > Cmake however doesn't detect the fmod library there as it's only > searching in linden/libraries/universal-darwin. This means it > disables fmod and builds without libfmodwrapper ... which > viewer_manifest.py then tries to copy ... and dies. > > Easiest solution seemed to be to create a fat library when doing the > copy, changing the above to ... > > cp -p ../fmodapi375mac/api/inc/*.h linden/libraries/include > > lipo -create fmodapi375mac/api/lib/libfmod.a fmodapi375mac/api/lib/ > libfmodx86.a -output linden/libraries/universal-darwin/lib_release/ > libfmod.a > cp -p linden/libraries/universal-darwin/lib_release/libfmod.a linden/ > libraries/universal-darwin/lib_debug/libfmod.a > > Should I put that on the Wiki or is there another preferred solution? > > Aimee. > > PS. Still seem to be those few files missing from llrender in the > featurettes-5 branch *Nudges Soft softly* :D blindly copying them > over from release "seems" to work though at the moment. > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From dmahalko at gmail.com Tue Jul 22 01:58:04 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Jul 22 01:58:06 2008 Subject: [sldev] Re: Making symbol browsing work across projects in VS In-Reply-To: References: Message-ID: I didn't think this was veering off the original documentation topic, which is why I posted it as a reply to Rob's original post. After backtracking and essentially starting over with the compile instructions, I see that the problems I've been having are due to more of my Visual Studio n00bishness. I have learned a valuable lesson: 1. Don't try to edit the source by opening a single *.vcproj file vs opening the entire "indra_complete.sln". 2. While you can certainly open individual project files and edit them that way, if the all the projects aren't loaded together as part of a single solution then symbol browsing doesn't work across all the projects and Visual Studio can't tell you what is wrong or how to fix it.. At some point I got off on the wrong track of downloading the source, opening just the "linden\indra\newview\newview.vcproj" and then going to the Build menu to try and compile the viewer.. which excludes all the other projects from the build attempt and of course (as I now realize) it fails horribly in ways no one here has ever seen before.. oops. On Sat, Jul 19, 2008 at 12:26 PM, Soft wrote: > It's easy to forget - but if something veers this far off the original > topic, please consider changing the subject line. It can easily grow > to dwarf and kill the original topic. > From sllists at boroon.dasgupta.ch Tue Jul 22 06:50:50 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jul 22 06:50:55 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> Message-ID: <4885E5BA.8060300@boroon.dasgupta.ch> Ricky schrieb: > Linking CXX executable linux-crash-logger > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Realloc' > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Alloc' > /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so > : undefined reference to `FT_Free' > collect2: ld returned 1 exit status > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > make[1]: *** > [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] Error 2 > make: *** [all] Error 2 Has a solution to this one be found, yet? I'm getting exactly the same error message with revision 830 of "release". I'm not using any chroot environment, because I'm on a i686 system. Though, I'm on Gentoo, too, so maybe it's a Gentoo specific issue? Boroondas From carjay at gmx.net Tue Jul 22 10:54:06 2008 From: carjay at gmx.net (Carsten Juttner) Date: Tue Jul 22 10:54:14 2008 Subject: [sldev] Re: Making symbol browsing work across projects in VS In-Reply-To: References: Message-ID: <48861EBE.3070200@gmx.net> Dale Mahalko wrote: > 1. Don't try to edit the source by opening a single *.vcproj file vs > opening the entire "indra_complete.sln". > > 2. While you can certainly open individual project files and edit them > that way, if the all the projects aren't loaded together as part of a > single solution then symbol browsing doesn't work across all the > projects and Visual Studio can't tell you what is wrong or how to fix > it.. > Yes, true, VS thinks in solutions, if you open up a vcproj and try to save, VS usually automatically creates a new solution for it and if one already exists, it offers to open up that one. The symbol browsing (also known as "Intellisense") is actually one of the most useful and at the same time most annoying features of VS. Given, parsing C++ source code is hard enough, trying to do so while you are editing them is probably even harder. But still... So don't wonder if it suddenly fails to work in mysterious ways. This is ok, it just does that. Often it's because you created an unparsable temporary construction (like not adding a "{" or "(") but sometimes it simply stops working for a while. Don't worry though, after compiling and/or changing source files it will return. Another thing is that it usually starts to parse your source files right when you don't want it to (because it causes your whole system to slow down even on fast systems. If you spot a "feacp" in the task manager draining lots of CPU time, that's the Intellisense parser). Don't get me wrong, If it works, it's great indeed. PS: If all things fail, you can try deleting the .ncb file (no compile browse). It will be regenerated. Sometimes it seems necessary though I didn't have to do it for a long time now. Regards, Carsten From jhurliman at jhurliman.org Tue Jul 22 11:24:06 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jul 22 11:24:09 2008 Subject: [sldev] AssetUploadRequest documentation needs help Message-ID: I filled out documentation for AssetUploadRequest as best I could at https://wiki.secondlife.com/wiki/AssetUploadRequest but I don't have a complete understanding of how StoreLocal and Tempfile fields work. Can anyone shed some light on that? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/cfea05f4/attachment.htm From kf6kjg at gmail.com Tue Jul 22 11:40:18 2008 From: kf6kjg at gmail.com (Ricky) Date: Tue Jul 22 11:40:21 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <4885E5BA.8060300@boroon.dasgupta.ch> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> Message-ID: <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> It's been a little while, but if I remember aright... I think I was executing the wrong command... Lemme check my build script... Ya.. here's how I fixed it: $ cd ./linden/indra $ ./develop.py build and it automatically makes the entire project... Thanks for digging this up.. I haven't checked out the latest recently... My linden folder is still rev 616! Ouch. I should dig back into this :D Ricky On Tue, Jul 22, 2008 at 6:50 AM, Boroondas Gupte wrote: > Ricky schrieb: > >> Linking CXX executable linux-crash-logger >> >> /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ >> libpangoft2-1.0.so : undefined reference to >> `FT_Realloc' >> >> /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ >> libpangoft2-1.0.so : undefined reference to >> `FT_Alloc' >> >> /home/ricky/sl_development/linden/indra/../libraries/i686-linux/lib_release_client/ >> libpangoft2-1.0.so : undefined reference to >> `FT_Free' >> collect2: ld returned 1 exit status >> make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 >> make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] >> Error 2 >> make: *** [all] Error 2 >> > > Has a solution to this one be found, yet? > > I'm getting exactly the same error message with revision 830 of "release". > I'm not using any chroot environment, because I'm on a i686 system. Though, > I'm on Gentoo, too, so maybe it's a Gentoo specific issue? > > Boroondas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/1cd778d0/attachment.htm From jhurliman at jhurliman.org Tue Jul 22 11:45:18 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jul 22 11:45:26 2008 Subject: [sldev] Re: AssetUploadRequest documentation needs help In-Reply-To: References: Message-ID: Kelly Linden helped me out with StoreLocal, just missing Tempfile information now. On Tue, Jul 22, 2008 at 11:24 AM, John Hurliman wrote: > I filled out documentation for AssetUploadRequest as best I could at > https://wiki.secondlife.com/wiki/AssetUploadRequest but I don't have a > complete understanding of how StoreLocal and Tempfile fields work. Can > anyone shed some light on that? > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/351edd4f/attachment.htm From jhurliman at jhurliman.org Tue Jul 22 11:47:50 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jul 22 11:47:52 2008 Subject: [sldev] Re: AssetUploadRequest documentation needs help In-Reply-To: References: Message-ID: Turns out Tempfile is deprecated. Sorry for the e-mail spam, but if you ever wanted to know how AssetUploadRequest works the packet is fully documented now :-). On Tue, Jul 22, 2008 at 11:45 AM, John Hurliman wrote: > Kelly Linden helped me out with StoreLocal, just missing Tempfile > information now. > > On Tue, Jul 22, 2008 at 11:24 AM, John Hurliman > wrote: > >> I filled out documentation for AssetUploadRequest as best I could at >> https://wiki.secondlife.com/wiki/AssetUploadRequest but I don't have a >> complete understanding of how StoreLocal and Tempfile fields work. Can >> anyone shed some light on that? >> >> John >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/0bba6a47/attachment.htm From bill.hoffman at kitware.com Tue Jul 22 12:14:49 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Jul 22 12:15:46 2008 Subject: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <48848D24.7060909@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> Message-ID: <488631A9.2030404@kitware.com> Bill Hoffman wrote: > Aimee Walton wrote: > >>> >>> Sure, that is a warning, does the build still work? >> >> Sorry, not my most useful reply ever, I'll blame lack of sleep. >> >> We have >> target_link_libraries(myexe /path/to/foo) >> >> Which is working on 2.4 as it splits to give -lfoo >> >> However on 2.6 it breaks the build, as it uses /path/to/foo when it >> really needs /path/to/libfoo.a >> >> AImee. >> >> > > Could someone please clarify if this was working on makefile builds? You > say it was /path/to/libfoo.a, and that implies linux/unix. I want to > make sure this is not a new issue. As far as I know /path/to/foo always > failed (even in CMake 2.4) for any makefile builds included nmake, and > unix makefiles. The only time it worked was with the VS IDE. > Assuming this was an issue that only affected the VS IDE, the most recent release candidate for cmake 2.6.1 RC 12 contains a fix that should make this work like it did in 2.4, but with a warning. I would appreciate it if someone could verify that this fixes your problem. You can find the windows binary here: http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-12-win32-x86.exe Thanks. -Bill From suzhanna.rossini at balsaestates.com Tue Jul 22 13:19:30 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Tue Jul 22 13:19:44 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <488631A9.2030404@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> Message-ID: <011d01c8ec38$404226e0$c0c674a0$@rossini@balsaestates.com> > Bill Hoffman wrote: > > Aimee Walton wrote: > > > >>> > >>> Sure, that is a warning, does the build still work? > >> > >> Sorry, not my most useful reply ever, I'll blame lack of sleep. > >> > >> We have > >> target_link_libraries(myexe /path/to/foo) > >> > >> Which is working on 2.4 as it splits to give -lfoo > >> > >> However on 2.6 it breaks the build, as it uses /path/to/foo when it > >> really needs /path/to/libfoo.a > >> > >> AImee. > >> > >> > > > > Could someone please clarify if this was working on makefile builds? > You > > say it was /path/to/libfoo.a, and that implies linux/unix. I want > to > > make sure this is not a new issue. As far as I know /path/to/foo > always > > failed (even in CMake 2.4) for any makefile builds included nmake, > and > > unix makefiles. The only time it worked was with the VS IDE. > > > Assuming this was an issue that only affected the VS IDE, the most > recent release candidate for cmake 2.6.1 RC 12 contains a fix that > should make this work like it did in 2.4, but with a warning. > > I would appreciate it if someone could verify that this fixes your > problem. You can find the windows binary here: > > http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-12-win32-x86.exe > > Thanks. > > -Bill Bill, I've started a build on VS2003. But I won't be able to report the result until tomorrow morning (CET) as I'm off to bed right now.. ;-) /Alexandra From sllists at boroon.dasgupta.ch Tue Jul 22 13:24:33 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jul 22 13:24:39 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> Message-ID: <48864201.8070706@boroon.dasgupta.ch> Ricky schrieb: > It's been a little while, but if I remember aright... I think I was > executing the wrong command... Lemme check my build script... > > Ya.. here's how I fixed it: > $ cd ./linden/indra > $ ./develop.py build > > and it automatically makes the entire project... Tried that and still get "undefined reference to `{FT_Realloc,FT_Alloc,FT_Free}'" errors. I made sure my tree was clean. Is there a way to output the actual compiler commands executed, so one could check the -l and -L parameters for saneness? Boroondas From kf6kjg at gmail.com Tue Jul 22 14:03:34 2008 From: kf6kjg at gmail.com (Ricky) Date: Tue Jul 22 14:03:38 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <48864201.8070706@boroon.dasgupta.ch> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> <48864201.8070706@boroon.dasgupta.ch> Message-ID: <3bb9647e0807221403s65e83db7v12ff962e4752b98@mail.gmail.com> Re-glanced at script... Ah.. Not saying this works (because I just got the new set of files from SVN and it didn't work.. research pending...) but here's the process as I know it so far: (This used to work...) $ cd ./linden/indra $ ./develop.py cmake $ ./develop.py build BUT... This process doesn't make it past the cmake part. It dies with the following: Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -G \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" \'/home/ricky/sl_development/linden/indra\'' in 'viewer-linux-i686' -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works Traceback (most recent call last): File "install.py", line 61, in ? from indra.base import llsd File "/home/ricky/sl_development/linden/indra/lib/python/indra/base/llsd.py", line 36, in ? from indra.util.fastest_elementtree import fromstring File "/home/ricky/sl_development/linden/indra/lib/python/indra/util/fastest_elementtree.py", line 51, in ? from xml.etree.ElementTree import * ImportError: No module named etree.ElementTree CMake Error: Failed to download or unpack prebuilt 'ogg-vorbis'. Process returned 1. -- Configuring done Cleaning 'viewer-linux-i686' Error: the command 'cmake' exited with status 255 On a side note, the linux compile page seems wildly out of date, and I'm fairly sure I'm not yet qualified to bring it up to date.. http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) Like I said, it's been a while and I haven't kept caught up... :/ Ricky On Tue, Jul 22, 2008 at 1:24 PM, Boroondas Gupte wrote: > Ricky schrieb: > >> It's been a little while, but if I remember aright... I think I was >> executing the wrong command... Lemme check my build script... >> >> Ya.. here's how I fixed it: >> $ cd ./linden/indra >> $ ./develop.py build >> >> and it automatically makes the entire project... >> > Tried that and still get "undefined reference to > `{FT_Realloc,FT_Alloc,FT_Free}'" errors. > I made sure my tree was clean. > > Is there a way to output the actual compiler commands executed, so one > could check the -l and -L parameters for saneness? > > Boroondas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/e526b8c0/attachment.htm From monkowsk at watson.ibm.com Tue Jul 22 14:29:50 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jul 22 14:30:57 2008 Subject: [sldev] Wiki article on culling Message-ID: <4886514E.2010009@watson.ibm.com> I've extracted some information regarding culling from the SLDev mailing list to create a page on the wiki. Unfortunately, I don't know the code involved, so I don't know if it is still current. Would anyone who knows, please have a look and correct anything I've got wrong and add anything you think might be useful. http://wiki.secondlife.com/wiki/Culling Thanks, Mike From carjay at gmx.net Tue Jul 22 15:17:59 2008 From: carjay at gmx.net (Carsten Juttner) Date: Tue Jul 22 15:18:16 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0807221403s65e83db7v12ff962e4752b98@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> <48864201.8070706@boroon.dasgupta.ch> <3bb9647e0807221403s65e83db7v12ff962e4752b98@mail.gmail.com> Message-ID: <48865C97.6020807@gmx.net> Ricky wrote: > > File > "/home/ricky/sl_development/linden/indra/lib/python/indra/util/fastest_elementtree.py", > line 51, in ? > from xml.etree.ElementTree import * > ImportError: No module named etree.ElementTree Your Python installation is missing the ElementTree XML API. What python version is that? You need at least 2.5 Carsten From gigstaggart at gmail.com Tue Jul 22 15:32:23 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 22 15:32:27 2008 Subject: [sldev] Wiki article on culling In-Reply-To: <4886514E.2010009@watson.ibm.com> References: <4886514E.2010009@watson.ibm.com> Message-ID: <48865FF7.2070004@gmail.com> This looks good as a summary/first pass, thanks! My only concern about it is that comments from Lindens that were in an unofficial capacity seem to take on an air of more authority when wikied like this. For the technical side of things, I believe all this information is still very relevant and current. Mike Monkowski wrote: > I've extracted some information regarding culling from the SLDev mailing > list to create a page on the wiki. Unfortunately, I don't know the code > involved, so I don't know if it is still current. Would anyone who > knows, please have a look and correct anything I've got wrong and add > anything you think might be useful. > > http://wiki.secondlife.com/wiki/Culling > > Thanks, > Mike > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080722/ca5dc4bb/smime-0001.bin From soft at lindenlab.com Tue Jul 22 15:33:14 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 22 15:33:17 2008 Subject: [sldev] Mac Build Instructions / Universal / FMOD In-Reply-To: References: <487FCF28.5040407@lindenlab.com> <4885169D.7050907@watson.ibm.com> Message-ID: On Mon, Jul 21, 2008 at 9:16 PM, Aimee Walton wrote: > > PS. Still seem to be those few files missing from llrender in the > featurettes-5 branch *Nudges Soft softly* :D blindly copying them over from > release "seems" to work though at the moment. I forgot to post follow-up. featurettes-5 is being replaced by featurettes-6, which is a rebranch with all the corrected export bits in place. I'm dropping that in place now. From jhurliman at jhurliman.org Tue Jul 22 15:38:29 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Tue Jul 22 15:38:31 2008 Subject: [sldev] Wiki article on culling In-Reply-To: <48865FF7.2070004@gmail.com> References: <4886514E.2010009@watson.ibm.com> <48865FF7.2070004@gmail.com> Message-ID: Might also be helpful to split this page up into categories, since it covers interest lists, image transfer priorities, and frustum/occlusion culling. On Tue, Jul 22, 2008 at 3:32 PM, Jason Giglio wrote: > This looks good as a summary/first pass, thanks! > > My only concern about it is that comments from Lindens that were in an > unofficial capacity seem to take on an air of more authority when wikied > like this. > > For the technical side of things, I believe all this information is > still very relevant and current. > > > > Mike Monkowski wrote: > > I've extracted some information regarding culling from the SLDev mailing > > list to create a page on the wiki. Unfortunately, I don't know the code > > involved, so I don't know if it is still current. Would anyone who > > knows, please have a look and correct anything I've got wrong and add > > anything you think might be useful. > > > > http://wiki.secondlife.com/wiki/Culling > > > > Thanks, > > Mike > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/057a069a/attachment.htm From soft at lindenlab.com Tue Jul 22 15:40:37 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 22 15:40:39 2008 Subject: [sldev] Wiki article on culling In-Reply-To: <48865FF7.2070004@gmail.com> References: <4886514E.2010009@watson.ibm.com> <48865FF7.2070004@gmail.com> Message-ID: It's 100% okay to add a cautionary note to the page -- it's better to have a caution flag on info that turns out to be okay than to have bad info treated as canon. You could also ping the sourced Lindens on-list directly to ask for a review. On Tue, Jul 22, 2008 at 5:32 PM, Jason Giglio wrote: > > My only concern about it is that comments from Lindens that were in an > unofficial capacity seem to take on an air of more authority when wikied > like this. > > Mike Monkowski wrote: >> I've extracted some information regarding culling from the SLDev mailing >> list to create a page on the wiki. Unfortunately, I don't know the code >> involved, so I don't know if it is still current. Would anyone who >> knows, please have a look and correct anything I've got wrong and add >> anything you think might be useful. >> >> http://wiki.secondlife.com/wiki/Culling From kf6kjg at gmail.com Tue Jul 22 16:14:02 2008 From: kf6kjg at gmail.com (Ricky) Date: Tue Jul 22 16:14:04 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <48865C97.6020807@gmx.net> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> <48864201.8070706@boroon.dasgupta.ch> <3bb9647e0807221403s65e83db7v12ff962e4752b98@mail.gmail.com> <48865C97.6020807@gmx.net> Message-ID: <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> Ah... Looks like I need to update my system. The installed python version is 2.4.4, and I'm upgrading to 2.5.2 now. Will report on build status when upgrade is complete. Interesting idea I just had... Is is possible to make the develop.py script detect and error when the version of python is too old? Ricky On Tue, Jul 22, 2008 at 3:17 PM, Carsten Juttner wrote: > Ricky wrote: > >> >> File >> "/home/ricky/sl_development/linden/indra/lib/python/indra/util/fastest_elementtree.py", >> line 51, in ? >> from xml.etree.ElementTree import * >> ImportError: No module named etree.ElementTree >> > > Your Python installation is missing the ElementTree XML API. What python > version is that? > > You need at least 2.5 > > > Carsten > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/705b62c6/attachment.htm From gigstaggart at gmail.com Tue Jul 22 16:18:43 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 22 16:18:50 2008 Subject: [sldev] Wiki article on culling In-Reply-To: References: <4886514E.2010009@watson.ibm.com> <48865FF7.2070004@gmail.com> Message-ID: <48866AD3.8010905@gmail.com> Soft wrote: > It's 100% okay to add a cautionary note to the page -- it's better to > have a caution flag on info that turns out to be okay than to have bad > info treated as canon. You could also ping the sourced Lindens on-list > directly to ask for a review. > Warning added about the informal, non-policy, nature of the source. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080722/71282676/smime.bin From kf6kjg at gmail.com Tue Jul 22 17:52:09 2008 From: kf6kjg at gmail.com (Ricky) Date: Tue Jul 22 17:52:13 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger link error In-Reply-To: <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <3bb9647e0807221140x2b5640e3w95706d6b9bf22c17@mail.gmail.com> <48864201.8070706@boroon.dasgupta.ch> <3bb9647e0807221403s65e83db7v12ff962e4752b98@mail.gmail.com> <48865C97.6020807@gmx.net> <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> Message-ID: <3bb9647e0807221752w69718afdhc8c759a99596548e@mail.gmail.com> Ok. I updated Python to 2.5. And the previous error went away, thanks Carsten. Now I'm on to another error in my little quest to try and duplicate Boroondas' errors. Or at least get a compiled viewer again! Here's the error: CMake Error: Cannot find source file "/home/ricky/sl_development/linden/indra/viewer-linux-i686/newview/character/attentions.xml" Cmake then tries to go find a host of other files in the characters folder and can't. It finally dies with exit status 255. Next! :D Ricky On Tue, Jul 22, 2008 at 4:14 PM, Ricky wrote: > Ah... Looks like I need to update my system. The installed python version > is 2.4.4, and I'm upgrading to 2.5.2 now. > > Will report on build status when upgrade is complete. > > Interesting idea I just had... Is is possible to make the develop.py script > detect and error when the version of python is too old? > > Ricky > > On Tue, Jul 22, 2008 at 3:17 PM, Carsten Juttner wrote: > >> Ricky wrote: >> >>> >>> File >>> "/home/ricky/sl_development/linden/indra/lib/python/indra/util/fastest_elementtree.py", >>> line 51, in ? >>> from xml.etree.ElementTree import * >>> ImportError: No module named etree.ElementTree >>> >> >> Your Python installation is missing the ElementTree XML API. What python >> version is that? >> >> You need at least 2.5 >> >> >> Carsten >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080722/b6e978ae/attachment-0001.htm From soft at lindenlab.com Tue Jul 22 18:35:57 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 22 18:35:59 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger linkerror In-Reply-To: <3bb9647e0807221752w69718afdhc8c759a99596548e@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <48864201.8070706@boroon.dasgupta.ch> <48865C97.6020807@gmx.net> <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> <3bb9647e0807221752w69718afdhc8c759a99596548e@mail.gmail.com> Message-ID: Have you installed the library and art bundles in the same location as the source? The art bundle contains attentions.xml. On Tue, Jul 22, 2008 at 7:52 PM, Ricky wrote: > Ok. I updated Python to 2.5. And the previous error went away, thanks > Carsten. > > Now I'm on to another error in my little quest to try and duplicate > Boroondas' errors. Or at least get a compiled viewer again! > > Here's the error: > CMake Error: Cannot find source file > "/home/ricky/sl_development/linden/indra/viewer-linux-i686/newview/character/attentions.xml" > > Cmake then tries to go find a host of other files in the characters folder > and can't. It finally dies with exit status 255. > > Next! :D > Ricky > > On Tue, Jul 22, 2008 at 4:14 PM, Ricky wrote: >> >> Ah... Looks like I need to update my system. The installed python version >> is 2.4.4, and I'm upgrading to 2.5.2 now. >> >> Will report on build status when upgrade is complete. >> >> Interesting idea I just had... Is is possible to make the develop.py >> script detect and error when the version of python is too old? >> >> Ricky >> >> On Tue, Jul 22, 2008 at 3:17 PM, Carsten Juttner wrote: >>> >>> Ricky wrote: >>>> >>>> File >>>> "/home/ricky/sl_development/linden/indra/lib/python/indra/util/fastest_elementtree.py", >>>> line 51, in ? >>>> from xml.etree.ElementTree import * >>>> ImportError: No module named etree.ElementTree >>> >>> Your Python installation is missing the ElementTree XML API. What python >>> version is that? >>> >>> You need at least 2.5 >>> >>> >>> Carsten >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From kf6kjg at gmail.com Tue Jul 22 22:18:10 2008 From: kf6kjg at gmail.com (Ricky) Date: Tue Jul 22 22:18:13 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger linkerror In-Reply-To: References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <48864201.8070706@boroon.dasgupta.ch> <48865C97.6020807@gmx.net> <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> <3bb9647e0807221752w69718afdhc8c759a99596548e@mail.gmail.com> Message-ID: <3bb9647e0807222218i5c65b1e2v2cd11bcb5855deb5@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: sl_update.sh Type: application/x-sh Size: 3421 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080722/36e377a2/sl_update.sh From kf6kjg at gmail.com Tue Jul 22 22:28:39 2008 From: kf6kjg at gmail.com (Ricky) Date: Tue Jul 22 22:28:42 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger linkerror In-Reply-To: <3bb9647e0807222218i5c65b1e2v2cd11bcb5855deb5@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <48864201.8070706@boroon.dasgupta.ch> <48865C97.6020807@gmx.net> <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> <3bb9647e0807221752w69718afdhc8c759a99596548e@mail.gmail.com> <3bb9647e0807222218i5c65b1e2v2cd11bcb5855deb5@mail.gmail.com> Message-ID: <3bb9647e0807222228h5cdd290dka33fa9e73a46c852@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: sl_update.sh Type: application/x-sh Size: 3420 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080722/c23bb949/sl_update-0001.sh From soft at lindenlab.com Tue Jul 22 22:36:44 2008 From: soft at lindenlab.com (Soft) Date: Tue Jul 22 22:36:47 2008 Subject: [sldev] Compiling release svn (r616) - linux-crash-logger linkerror In-Reply-To: <3bb9647e0807222218i5c65b1e2v2cd11bcb5855deb5@mail.gmail.com> References: <3bb9647e0806042230p17da6c09jb007cdc7e3e9cb3b@mail.gmail.com> <4885E5BA.8060300@boroon.dasgupta.ch> <48864201.8070706@boroon.dasgupta.ch> <48865C97.6020807@gmx.net> <3bb9647e0807221614y2bedf377u31d5733f60244651@mail.gmail.com> <3bb9647e0807221752w69718afdhc8c759a99596548e@mail.gmail.com> <3bb9647e0807222218i5c65b1e2v2cd11bcb5855deb5@mail.gmail.com> Message-ID: On Wed, Jul 23, 2008 at 12:18 AM, Ricky wrote: > Hmm.. My (attached) update script is supposed to get the URLs for those > files from the commit log.. (BTW, thanks for putting those messages there! > It's made my life easier!) You bet. Note that my scripts also drop that data in doc/asset_urls.txt - that's formatted so you can source it directly in your bash script with the period (self-parse) command: . doc/asset_urls.txt From suzhanna.rossini at balsaestates.com Tue Jul 22 23:19:23 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Tue Jul 22 23:19:34 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <488631A9.2030404@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> Message-ID: <012c01c8ec8c$0cf3cce0$26db66a0$@rossini@balsaestates.com> > Bill Hoffman wrote: > > Aimee Walton wrote: > > > >>> > >>> Sure, that is a warning, does the build still work? > >> > >> Sorry, not my most useful reply ever, I'll blame lack of sleep. > >> > >> We have > >> target_link_libraries(myexe /path/to/foo) > >> > >> Which is working on 2.4 as it splits to give -lfoo > >> > >> However on 2.6 it breaks the build, as it uses /path/to/foo when it > >> really needs /path/to/libfoo.a > >> > >> AImee. > >> > >> > > > > Could someone please clarify if this was working on makefile builds? > You > > say it was /path/to/libfoo.a, and that implies linux/unix. I want > to > > make sure this is not a new issue. As far as I know /path/to/foo > always > > failed (even in CMake 2.4) for any makefile builds included nmake, > and > > unix makefiles. The only time it worked was with the VS IDE. > > > Assuming this was an issue that only affected the VS IDE, the most > recent release candidate for cmake 2.6.1 RC 12 contains a fix that > should make this work like it did in 2.4, but with a warning. > > I would appreciate it if someone could verify that this fixes your > problem. You can find the windows binary here: > > http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-12-win32-x86.exe > > Thanks. > > -Bill It didn't do any good for me Bill.. I get a clean build with cmake 2.4.8, and when I used 2.6.1 RC12, I got the very same errors as I had problems with before when I ran 2.6.0 Linking... llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(class std::basic_string,class std::allocator > const &,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) C:\SLDev\release\indra\build-VS2003\newview\RelWithDebInfo\secondlife-bin.ex e : fatal error LNK1120: 1 unresolved externals /Alexandra. From bill.hoffman at kitware.com Wed Jul 23 05:14:05 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Jul 23 05:14:56 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <012c01c8ec8c$0cf3cce0$26db66a0$@rossini@balsaestates.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <012c01c8ec8c$0cf3cce0$26db66a0$@rossini@balsaestates.com> Message-ID: <4887208D.50309@kitware.com> Suzhanna Rossini wrote: >> Bill Hoffman wrote: >>> Aimee Walton wrote: >>> >>>>> Sure, that is a warning, does the build still work? >>>> Sorry, not my most useful reply ever, I'll blame lack of sleep. >>>> >>>> We have >>>> target_link_libraries(myexe /path/to/foo) >>>> >>>> Which is working on 2.4 as it splits to give -lfoo >>>> >>>> However on 2.6 it breaks the build, as it uses /path/to/foo when it >>>> really needs /path/to/libfoo.a >>>> >>>> AImee. >>>> >>>> >>> Could someone please clarify if this was working on makefile builds? >> You >>> say it was /path/to/libfoo.a, and that implies linux/unix. I want >> to >>> make sure this is not a new issue. As far as I know /path/to/foo >> always >>> failed (even in CMake 2.4) for any makefile builds included nmake, >> and >>> unix makefiles. The only time it worked was with the VS IDE. >>> >> Assuming this was an issue that only affected the VS IDE, the most >> recent release candidate for cmake 2.6.1 RC 12 contains a fix that >> should make this work like it did in 2.4, but with a warning. >> >> I would appreciate it if someone could verify that this fixes your >> problem. You can find the windows binary here: >> >> http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-12-win32-x86.exe >> >> Thanks. >> >> -Bill > > > It didn't do any good for me Bill.. > I get a clean build with cmake 2.4.8, and when I used 2.6.1 RC12, I got the > very same errors as I had problems with before when I ran 2.6.0 > > Linking... > llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl > lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void > __thiscall LLFloaterCompileQueue::compile(class > std::basic_string,class > std::allocator > const &,class LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std > @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) > llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl > lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > C:\SLDev\release\indra\build-VS2003\newview\RelWithDebInfo\secondlife-bin.ex > e : fatal error LNK1120: 1 unresolved externals > > /Alexandra. > > OK, but that is not the error you would get from the .obj .lib issue. That is just a single undefined symbol. Where is lscript_compile supposed to be? -Bill From robin.cornelius at gmail.com Wed Jul 23 05:32:37 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Jul 23 05:32:43 2008 Subject: [sldev] [VWR] idle_mem_check() Message-ID: <488724E5.7020400@gmail.com> Hey Everyone, Whist looking through the idle loop i came across the idle_mem_check() function. What this does is every frame allocate 10MB of memory in 1MB chunks then frees them again, just to check it can. This seems like a generally bad idea and if you are already hitting swap space its going to contribute to a swap storm and lets face it, if you can't allocate 10MB your pretty screwed anyway, something going to crash or be terminated *very* soon. I would also imagine this can lead to memory fragmentation (although i am blissfully unaware how well OS's cope with this these days). I did get a small increase in FPS by removing it. My viewer was at 5.9-6.0 FPS in a sim with no avatars in or out (or moving) after removing the idle_mem_check() i got 7.0 FPS in exactly the same location. I vote its removed but wanted to see if there are any comments or good reasons why it needs to still be there. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080723/e9515dbd/signature.pgp From chaosstar at gmail.com Wed Jul 23 05:37:15 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Jul 23 05:37:18 2008 Subject: [sldev] [VWR] idle_mem_check() In-Reply-To: <488724E5.7020400@gmail.com> References: <488724E5.7020400@gmail.com> Message-ID: <9bb32d430807230537l3409988cre8fc6536bfe0dcc0@mail.gmail.com> I personally commented out this check in my viewer a few days ago, and have not witnessed any problems at all. The contrary, this check does -not- protect the SL client from crashing at all when the box runs out of RAM. I've verified this voluntarily and involuntarily a few times. All in all, this seems quite obsolete, and running it every frame is a pure resource hog. --Chalice Yao On Wed, Jul 23, 2008 at 14:32, Robin Cornelius wrote: > > Hey Everyone, > > Whist looking through the idle loop i came across the idle_mem_check() > function. What this does is every frame allocate 10MB of memory in 1MB > chunks then frees them again, just to check it can. > > This seems like a generally bad idea and if you are already hitting swap > space its going to contribute to a swap storm and lets face it, if you > can't allocate 10MB your pretty screwed anyway, something going to crash > or be terminated *very* soon. > > I would also imagine this can lead to memory fragmentation (although i > am blissfully unaware how well OS's cope with this these days). > > I did get a small increase in FPS by removing it. My viewer was at > 5.9-6.0 FPS in a sim with no avatars in or out (or moving) after > removing the idle_mem_check() i got 7.0 FPS in exactly the same location. > > I vote its removed but wanted to see if there are any comments or good > reasons why it needs to still be there. > > Robin > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From soft at lindenlab.com Wed Jul 23 06:34:45 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 23 06:34:48 2008 Subject: [sldev] [VWR] idle_mem_check() In-Reply-To: <488724E5.7020400@gmail.com> References: <488724E5.7020400@gmail.com> Message-ID: On Wed, Jul 23, 2008 at 7:32 AM, Robin Cornelius wrote: > > Hey Everyone, > > Whist looking through the idle loop i came across the idle_mem_check() > function. What this does is every frame allocate 10MB of memory in 1MB > chunks then frees them again, just to check it can. > > This seems like a generally bad idea and if you are already hitting swap > space its going to contribute to a swap storm and lets face it, if you > can't allocate 10MB your pretty screwed anyway, something going to crash > or be terminated *very* soon. > > I would also imagine this can lead to memory fragmentation (although i > am blissfully unaware how well OS's cope with this these days). > > I did get a small increase in FPS by removing it. My viewer was at > 5.9-6.0 FPS in a sim with no avatars in or out (or moving) after > removing the idle_mem_check() i got 7.0 FPS in exactly the same location. > > I vote its removed but wanted to see if there are any comments or good > reasons why it needs to still be there. To my eye, it looks like some debug code that slipped into release, and I have mailed the Linden who added this to ask for more details. Note that it's also going to leak up to 9 megs plus the container when one of the 1 meg allocations fails, as it bails from the routine without doing cleanup on the first failure. From aimee at ama-zing.co.uk Wed Jul 23 07:23:02 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Jul 23 07:23:26 2008 Subject: Fwd: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) References: Message-ID: (Sorry for the second copy of this Bill, forgot to reply to the list) On Jul 22, 2008, at 20:14, Bill Hoffman wrote: > Bill Hoffman wrote: > Aimee Walton wrote: >> We have >> target_link_libraries(myexe /path/to/foo) >> >> Which is working on 2.4 as it splits to give -lfoo >> >> However on 2.6 it breaks the build, as it uses /path/to/foo when >> it really needs /path/to/libfoo.a >> >> AImee. >> > > Could someone please clarify if this was working on makefile > builds? You say it was /path/to/libfoo.a, and that implies linux/ > unix. I want to make sure this is not a new issue. As far as I > know /path/to/foo always failed (even in CMake 2.4) for any > makefile builds included nmake, and unix makefiles. The only time > it worked was with the VS IDE. > Assuming this was an issue that only affected the VS IDE, the most > recent release candidate for cmake 2.6.1 RC 12 contains a fix that > should make this work like it did in 2.4, but with a warning. I'm working on OS X 10.4.11 with Xcode 2.4, I did try RC12, but it still breaks on linking in the same way. As an example the actual code is stuff like: In cmake/APR.cmake: ... elseif (DARWIN) set(APR_LIBRARIES debug ${ARCH_PREBUILT_DIRS_DEBUG}/apr-1 optimized ${ARCH_PREBUILT_DIRS_RELEASE}/apr-1 ) set(APRUTIL_LIBRARIES debug ${ARCH_PREBUILT_DIRS_DEBUG}/aprutil-1 optimized ${ARCH_PREBUILT_DIRS_RELEASE}/aprutil-1 ) ... Then in cmake/LLCommon.cmake: ... set(LLCOMMON_LIBRARIES llcommon ${APRUTIL_LIBRARIES} ${APR_LIBRARIES} ${EXPAT_LIBRARIES} ${ZLIB_LIBRARIES} ) Then in mac_crash_logger/CMakeLists.txt: ... target_link_libraries(mac-crash-logger ${LLCRASHLOGGER_LIBRARIES} ${LLVFS_LIBRARIES} ${LLXML_LIBRARIES} ${LLMESSAGE_LIBRARIES} ${LLVFS_LIBRARIES} ${LLMATH_LIBRARIES} ${LLCOMMON_LIBRARIES} ${BOOST_SIGNALS_LIBRARY} ) With Cmake 2.6 running develop.py (after setting the CMP0003 as recommended by the warning) and then opening and building build- darwin-i386/SecondLife.xcodeproj in Xcode results in (paths shortened with "......" to save space): ... Ld ....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo/mac- crash-logger normal i386 mkdir ....../indra/build-darwin-i386/mac_crash_logger/ RelWithDebInfo cd ....../indra/build-darwin-i386 /usr/bin/g++-4.0 -o ....../indra/build-darwin-i386/ mac_crash_logger/RelWithDebInfo/mac-crash-logger -L....../indra/build- darwin-i386/mac_crash_logger/RelWithDebInfo -F....../indra/build- darwin-i386/mac_crash_logger/RelWithDebInfo -filelist ....../indra/ build-darwin-i386/mac_crash_logger/SecondLife.build/RelWithDebInfo/ mac-crash-logger.build/Objects-normal/i386/mac-crash- logger.LinkFileList -arch i386 -Wl,-Y,1455 -L/opt/local/lib -L/usr/ X11R6/lib -Wl,-headerpad_max_install_names,-search_paths_first ....../ indra/build-darwin-i386/llcrashlogger/RelWithDebInfo/ libllcrashlogger.a ....../indra/build-darwin-i386/llvfs/ RelWithDebInfo/libllvfs.a -framework Carbon -lexpat -lcurl ....../ indra/../libraries/universal-darwin/lib_release/cares -lssl - lllcrypto -lxmlrpc-epi ....../indra/../libraries/universal-darwin/ lib_release/aprutil-1 ....../indra/../libraries/universal-darwin/ lib_release/apr-1 -framework Carbon -lexpat -lcurl ....../indra/../ libraries/universal-darwin/lib_release/cares -lssl -lllcrypto - lxmlrpc-epi ....../indra/../libraries/universal-darwin/lib_release/ aprutil-1 ....../indra/../libraries/universal-darwin/lib_release/ apr-1 ....../indra/build-darwin-i386/llxml/RelWithDebInfo/ libllxml.a ....../indra/build-darwin-i386/llmessage/RelWithDebInfo/ libllmessage.a ....../indra/build-darwin-i386/llmath/RelWithDebInfo/ libllmath.a ....../indra/build-darwin-i386/llcommon/RelWithDebInfo/ libllcommon.a -lz -lboost_signals-mt -lexpat ....../indra/build- darwin-i386/llmessage/RelWithDebInfo/libllmessage.a -lcurl ....../ indra/../libraries/universal-darwin/lib_release/cares -lssl - lllcrypto -lxmlrpc-epi ....../indra/build-darwin-i386/llvfs/ RelWithDebInfo/libllvfs.a -framework Carbon ....../indra/build-darwin- i386/llmath/RelWithDebInfo/libllmath.a ....../indra/build-darwin-i386/ llcommon/RelWithDebInfo/libllcommon.a ....../indra/../libraries/ universal-darwin/lib_release/aprutil-1 ....../indra/../libraries/ universal-darwin/lib_release/apr-1 -lexpat -lz -lboost_signals-mt i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/cares: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/apr-1: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/cares: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/apr-1: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/cares: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin8-g++-4.0.1: ....../indra/../libraries/universal- darwin/lib_release/apr-1: No such file or directory The files are there in that location as libcares.a, libapr-1.a and libaprutil-1.a With Cmake 2.4.8 it succeeds with: ... Ld ....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo/mac- crash-logger normal i386 mkdir ....../indra/build-darwin-i386/mac_crash_logger/ RelWithDebInfo cd ....../indra/build-darwin-i386 /usr/bin/g++-4.0 -o ....../indra/build-darwin-i386/ mac_crash_logger/RelWithDebInfo/mac-crash-logger -L....../indra/build- darwin-i386/mac_crash_logger/RelWithDebInfo -L....../indra/build- darwin-i386/llcrashlogger/RelWithDebInfo -L....../indra/build-darwin- i386/llcrashlogger -L....../indra/build-darwin-i386/llvfs/ RelWithDebInfo -L....../indra/build-darwin-i386/llvfs -L....../indra/ build-darwin-i386/llxml/RelWithDebInfo -L....../indra/build-darwin- i386/llxml -L....../indra/build-darwin-i386/llmessage/RelWithDebInfo - L....../indra/build-darwin-i386/llmessage -L....../indra/build-darwin- i386/llmath/RelWithDebInfo -L....../indra/build-darwin-i386/llmath - L....../indra/build-darwin-i386/llcommon/RelWithDebInfo -L....../ indra/build-darwin-i386/llcommon -L....../indra/../libraries/ universal-darwin/lib_release/RelWithDebInfo -L....../indra/../ libraries/universal-darwin/lib_release -F....../indra/build-darwin- i386/mac_crash_logger/RelWithDebInfo -F/System/Library/Frameworks - filelist ....../indra/build-darwin-i386/mac_crash_logger/ SecondLife.build/RelWithDebInfo/mac-crash-logger.build/Objects-normal/ i386/mac-crash-logger.LinkFileList -arch i386 -Wl,-Y,1455 -L/opt/ local/lib -L/usr/X11R6/lib -Wl,-headerpad_max_install_names,- search_paths_first -lllcrashlogger -lllvfs -framework Carbon -lllxml - lexpat -lllmessage -lcurl -lcares -lssl -lllcrypto -lxmlrpc-epi - lllvfs -framework Carbon -lllmath -lllcommon -laprutil-1 -lapr-1 - lexpat -lz -lboost_signals-mt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080723/88fbe499/attachment-0001.htm From monkowsk at watson.ibm.com Wed Jul 23 07:29:23 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jul 23 07:29:42 2008 Subject: [sldev] Wiki article on culling In-Reply-To: References: <4886514E.2010009@watson.ibm.com> <48865FF7.2070004@gmail.com> Message-ID: <48874043.1050104@watson.ibm.com> Feel free to edit as you like. My goal was just to get something out there. Sort of the stone for the stone soup. http://en.wikipedia.org/wiki/Stone_soup Mike John Hurliman wrote: > Might also be helpful to split this page up into categories, since it > covers interest lists, image transfer priorities, and frustum/occlusion > culling. > > > On Tue, Jul 22, 2008 at 3:32 PM, Jason Giglio > wrote: > > This looks good as a summary/first pass, thanks! > > My only concern about it is that comments from Lindens that were in an > unofficial capacity seem to take on an air of more authority when wikied > like this. > > For the technical side of things, I believe all this information is > still very relevant and current. > > > > Mike Monkowski wrote: > > I've extracted some information regarding culling from the SLDev > mailing > > list to create a page on the wiki. Unfortunately, I don't know > the code > > involved, so I don't know if it is still current. Would anyone who > > knows, please have a look and correct anything I've got wrong and add > > anything you think might be useful. > > > > http://wiki.secondlife.com/wiki/Culling > > > > Thanks, > > Mike From bill.hoffman at kitware.com Wed Jul 23 07:51:14 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Jul 23 07:52:16 2008 Subject: Fwd: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: References: Message-ID: <48874562.5040805@kitware.com> Aimee Walton wrote: > (Sorry for the second copy of this Bill, forgot to reply to the list) > -L....../indra/../libraries/universal-darwin/lib_release/RelWithDebInfo > -L....../indra/../libraries/universal-darwin/lib_release > -F....../indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo > -F/System/Library/Frameworks > -filelist ....../indra/build-darwin-i386/mac_crash_logger/SecondLife.build/RelWithDebInfo/mac-crash-logger.build/Objects-normal/i386/mac-crash-logger.LinkFileList > -arch i386 -Wl,-Y,1455 -L/opt/local/lib -L/usr/X11R6/lib > -Wl,-headerpad_max_install_names,-search_paths_first -lllcrashlogger > -lllvfs -framework Carbon -lllxml -lexpat -lllmessage -lcurl *-lcares* > -lssl -lllcrypto -lxmlrpc-epi -lllvfs -framework Carbon -lllmath > -lllcommon *-laprutil-1 -lapr-1* -lexpat -lz -lboost_signals-mt > OK, thanks. I will see what I can do. You do know that this will not work in 2.4.8 or in a fixed 2.6.0 with makefiles on the mac. -Bill From soft at lindenlab.com Wed Jul 23 10:38:03 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 23 10:38:06 2008 Subject: [sldev] [VWR] idle_mem_check() In-Reply-To: References: <488724E5.7020400@gmail.com> Message-ID: On Wed, Jul 23, 2008 at 8:34 AM, Soft wrote: > On Wed, Jul 23, 2008 at 7:32 AM, Robin Cornelius > wrote: >> >> Hey Everyone, >> >> Whist looking through the idle loop i came across the idle_mem_check() >> function. What this does is every frame allocate 10MB of memory in 1MB >> chunks then frees them again, just to check it can. >> >> This seems like a generally bad idea and if you are already hitting swap >> space its going to contribute to a swap storm and lets face it, if you >> can't allocate 10MB your pretty screwed anyway, something going to crash >> or be terminated *very* soon. >> >> I would also imagine this can lead to memory fragmentation (although i >> am blissfully unaware how well OS's cope with this these days). >> >> I did get a small increase in FPS by removing it. My viewer was at >> 5.9-6.0 FPS in a sim with no avatars in or out (or moving) after >> removing the idle_mem_check() i got 7.0 FPS in exactly the same location. >> >> I vote its removed but wanted to see if there are any comments or good >> reasons why it needs to still be there. > > To my eye, it looks like some debug code that slipped into release, > and I have mailed the Linden who added this to ask for more details. > Note that it's also going to leak up to 9 megs plus the container when > one of the 1 meg allocations fails, as it bails from the routine > without doing cleanup on the first failure. It's very late in the QA cycle for the 1.20 viewer, so it might ship there. But it is gone from our release/ branch as will be reflected in the next release/ drop. Thank you for pointing this out. From jake at lindenlab.com Wed Jul 23 16:19:13 2008 From: jake at lindenlab.com (Jake Simpson) Date: Wed Jul 23 16:19:15 2008 Subject: [sldev] Re: Wiki article on culling In-Reply-To: <4886514E.2010009@watson.ibm.com> References: <4886514E.2010009@watson.ibm.com> Message-ID: <4887BC71.6050204@lindenlab.com> Mike Monkowski wrote: > I've extracted some information regarding culling from the SLDev > mailing list to create a page on the wiki. Unfortunately, I don't > know the code involved, so I don't know if it is still current. Would > anyone who knows, please have a look and correct anything I've got > wrong and add anything you think might be useful. > > http://wiki.secondlife.com/wiki/Culling > > Thanks, > Mike This is a pretty good article there Mike. Very comprehensive. I have some internal thoughts on our networking layer and will possibly be doing some work in that area relatively soon (approval pending) so I'll add some detailing to this page if/when I get to that work. Your idea of only sending delta's is a good one - it's what Quake uses in fact. However you can extend that further so that when a client ack's a delta packet, the simulator then updates it's default state which it uses as the control state (ie that which it derives the delta packet from, by comparing this state with the current object state) since it knows that the client now has a copy of that latest state, since the delta packet was acked. The client of course, does the same thing internally. It takes more memory (in order to store older delta'd packets that it's sent that can then be applied against the current internal control state) but it cuts down on state transfer quite considerably. As you point out, one of the nicest things about the delta approach is that if a UDP packet is dropped (or comes in out of order, in which case it's dropped) then the system just naturally keeps going until packets get through and the client acks them - the deviation in the packets just gets larger until such time as an ack is received at which point the control state is reset and the deviations drop in size and count. There are other network compression tricks that can be employed as well - dictionary systems whereby common packets (ie packets where the payload are the same) that get sent are noted as such and a dynamic dictionary is constructed on the fly so in future only an index into a dictionary is sent rather than a huge packet. One thing I would like to see us do is better sort ordering of the Interest set, so we send down those objects that are closest to you first. I need to have internal discussions with the relevant engineering groups inside of Doug's group first though. Jake From sllists at boroon.dasgupta.ch Wed Jul 23 17:02:37 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed Jul 23 17:02:40 2008 Subject: [sldev] Deltas and ACK (was: Wiki article on culling) In-Reply-To: <4887BC71.6050204@lindenlab.com> References: <4886514E.2010009@watson.ibm.com> <4887BC71.6050204@lindenlab.com> Message-ID: <4887C69D.4050707@boroon.dasgupta.ch> Jake Simpson schrieb: > Your idea of only sending delta's is a good one - it's what Quake uses > in fact. However you can extend that further so that when a client > ack's a delta packet, the simulator then updates it's default state > which it uses as the control state (ie that which it derives the delta > packet from, by comparing this state with the current object state) > since it knows that the client now has a copy of that latest state, > since the delta packet was acked. The client of course, does the same > thing internally. What if the ACK is lost (or just delayed)? Would the client interpret following deltas relative to the just ACKed state while the server would have created them still relative to some earlier state? Boroondas From monkowsk at watson.ibm.com Wed Jul 23 17:07:21 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jul 23 17:07:40 2008 Subject: [sldev] Re: Wiki article on culling In-Reply-To: <4887BC71.6050204@lindenlab.com> References: <4886514E.2010009@watson.ibm.com> <4887BC71.6050204@lindenlab.com> Message-ID: <4887C7B9.3040600@watson.ibm.com> Jake, None of the ideas are mine. They are yours and your colleagues'. :-) I just edited the posts that you all sent to SLDev and I do say that at the top of the page. Mike Jake Simpson wrote: > Mike Monkowski wrote: > >> I've extracted some information regarding culling from the SLDev >> mailing list to create a page on the wiki. Unfortunately, I don't >> know the code involved, so I don't know if it is still current. Would >> anyone who knows, please have a look and correct anything I've got >> wrong and add anything you think might be useful. >> >> http://wiki.secondlife.com/wiki/Culling >> >> Thanks, >> Mike > > This is a pretty good article there Mike. Very comprehensive. > > I have some internal thoughts on our networking layer and will possibly > be doing some work in that area relatively soon (approval pending) so > I'll add some detailing to this page if/when I get to that work. > > Your idea of only sending delta's is a good one - it's what Quake uses > in fact. However you can extend that further so that when a client ack's > a delta packet, the simulator then updates it's default state which it > uses as the control state (ie that which it derives the delta packet > from, by comparing this state with the current object state) since it > knows that the client now has a copy of that latest state, since the > delta packet was acked. The client of course, does the same thing > internally. It takes more memory (in order to store older delta'd > packets that it's sent that can then be applied against the current > internal control state) but it cuts down on state transfer quite > considerably. > > As you point out, one of the nicest things about the delta approach is > that if a UDP packet is dropped (or comes in out of order, in which case > it's dropped) then the system just naturally keeps going until packets > get through and the client acks them - the deviation in the packets just > gets larger until such time as an ack is received at which point the > control state is reset and the deviations drop in size and count. > > There are other network compression tricks that can be employed as well > - dictionary systems whereby common packets (ie packets where the > payload are the same) that get sent are noted as such and a dynamic > dictionary is constructed on the fly so in future only an index into a > dictionary is sent rather than a huge packet. > > One thing I would like to see us do is better sort ordering of the > Interest set, so we send down those objects that are closest to you > first. I need to have internal discussions with the relevant engineering > groups inside of Doug's group first though. > > Jake From gigstaggart at gmail.com Wed Jul 23 17:42:30 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 23 17:42:33 2008 Subject: [sldev] Fixed Internally resolution. Message-ID: <4887CFF6.9030004@gmail.com> "Fixed Internally" number is ballooning again. Is there a process to reconcile shipped code? Is code that is released in a RC branch considered fixed, or fixed internally? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080723/3322b47e/smime.bin From rdw at lindenlab.com Wed Jul 23 18:41:36 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Jul 23 18:41:37 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: <4887CFF6.9030004@gmail.com> References: <4887CFF6.9030004@gmail.com> Message-ID: <4887DDD0.8030504@lindenlab.com> Jason Giglio wrote: > "Fixed Internally" number is ballooning again. Is there a process to > reconcile shipped code? > > Is code that is released in a RC branch considered fixed, or fixed > internally? > I've been treating RC as fixed internally. Perhaps that's wrong? -RYaN From jake at lindenlab.com Thu Jul 24 03:11:28 2008 From: jake at lindenlab.com (Jake Simpson) Date: Thu Jul 24 03:11:31 2008 Subject: [sldev] Re: Deltas and ACK In-Reply-To: <4887C69D.4050707@boroon.dasgupta.ch> References: <4886514E.2010009@watson.ibm.com> <4887BC71.6050204@lindenlab.com> <4887C69D.4050707@boroon.dasgupta.ch> Message-ID: <48885550.1020102@lindenlab.com> Boroondas Gupte wrote: > Jake Simpson schrieb: >> Your idea of only sending delta's is a good one - it's what Quake >> uses in fact. However you can extend that further so that when a >> client ack's a delta packet, the simulator then updates it's default >> state which it uses as the control state (ie that which it derives >> the delta packet from, by comparing this state with the current >> object state) since it knows that the client now has a copy of that >> latest state, since the delta packet was acked. The client of course, >> does the same thing internally. > What if the ACK is lost (or just delayed)? Would the client interpret > following deltas relative to the just ACKed state while the server > would have created them still relative to some earlier state? > > Boroondas If the ack is lost, the server operates against the last actually acked packet. When a delta packet is sent down to the client it contains the packet count number of the packet it is built against so the client can always know "this packet is delta-ed against packet X - where is my list of states for packet X - oh, here they are. Right, so that's what I am delta-ing against". If an ack is lost, then the packet X count is not incremented, and the client operates against an older one. From sllists at boroon.dasgupta.ch Thu Jul 24 03:17:38 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu Jul 24 03:17:41 2008 Subject: [sldev] Re: Deltas and ACK In-Reply-To: <48885550.1020102@lindenlab.com> References: <4886514E.2010009@watson.ibm.com> <4887BC71.6050204@lindenlab.com> <4887C69D.4050707@boroon.dasgupta.ch> <48885550.1020102@lindenlab.com> Message-ID: <488856C2.4090108@boroon.dasgupta.ch> Jake Simpson schrieb: > [...] When a delta packet is sent down to the client it contains the > packet count number of the packet it is built against [...] Ah, everything fine then. Just wanted to make sure. :-) From robin.cornelius at gmail.com Thu Jul 24 03:28:51 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jul 24 03:28:54 2008 Subject: [sldev] [VWR] Crash on TP from LM on 1.20.14 Message-ID: <48885963.8060302@gmail.com> Hey everyone, 1.20.14 has hit a show stopper for me http://jira.secondlife.com/browse/VWR-8310 I'm crashing every TP from LM. The jira contains the gdb back trace and the patch to fix the issue. I've patched with null pointer protection and the use of array delete[], as array new[] is used so also memory leak there too. It fixes the issue for me. This just can't me another me only bug? or is my libc throwing up due to some kind of memory protection with the mismatch and detecting the invalid state? We may also need a new/delete new[]/delete[] audit. I know of at least one other (which is a whole other story). Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080724/263c1686/signature.pgp From monkowsk at watson.ibm.com Thu Jul 24 09:01:39 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Jul 24 09:04:19 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: <4887DDD0.8030504@lindenlab.com> References: <4887CFF6.9030004@gmail.com> <4887DDD0.8030504@lindenlab.com> Message-ID: <4888A763.4060301@watson.ibm.com> I don't think that's being done uniformly. There are 166 VWR bugs with Fix Version "1.20 Release Candidate". Only six of those have Status "Fix Pending". Mike Ryan Williams (Which) wrote: > Jason Giglio wrote: > >> "Fixed Internally" number is ballooning again. Is there a process to >> reconcile shipped code? >> >> Is code that is released in a RC branch considered fixed, or fixed >> internally? > > I've been treating RC as fixed internally. Perhaps that's wrong? From soft at lindenlab.com Thu Jul 24 12:43:30 2008 From: soft at lindenlab.com (Soft) Date: Thu Jul 24 12:43:34 2008 Subject: [sldev] [VWR] Crash on TP from LM on 1.20.14 In-Reply-To: <48885963.8060302@gmail.com> References: <48885963.8060302@gmail.com> Message-ID: On Thu, Jul 24, 2008 at 5:28 AM, Robin Cornelius wrote: > Hey everyone, > > 1.20.14 has hit a show stopper for me > > http://jira.secondlife.com/browse/VWR-8310 > > I'm crashing every TP from LM. The jira contains the gdb back trace and > the patch to fix the issue. > > I've patched with null pointer protection and the use of array delete[], > as array new[] is used so also memory leak there too. It fixes the issue > for me. > > This just can't me another me only bug? or is my libc throwing up due to > some kind of memory protection with the mismatch and detecting the > invalid state? > > We may also need a new/delete new[]/delete[] audit. I know of at least > one other (which is a whole other story). new[]/delete mismatches are harmless with arrays of scalar types. Witness the almost universal new char[]/delete mismatch in basic string handling. It's good form to correct those if you happen to be in related code, but please - nobody submit a single grand sweeping patch correcting every array of ints. On any complex types, those are landmines. An audit only covering those sounds like a grand idea. From robin.cornelius at gmail.com Thu Jul 24 13:01:25 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jul 24 13:02:13 2008 Subject: [sldev] [VWR] Crash on TP from LM on 1.20.14 In-Reply-To: References: <48885963.8060302@gmail.com> Message-ID: <4888DF95.6010809@gmail.com> Soft wrote: > On Thu, Jul 24, 2008 at 5:28 AM, Robin Cornelius > wrote: > > new[]/delete mismatches are harmless with arrays of scalar types. > Witness the almost universal new char[]/delete mismatch in basic > string handling. It's good form to correct those if you happen to be > in related code, but please - nobody submit a single grand sweeping > patch correcting every array of ints. > > On any complex types, those are landmines. An audit only covering > those sounds like a grand idea. I think this was a case of premature excitement as my viewer lasted for 4 hours solid after this patch. What is actually going on is good old fashioned memory corruption and this is causing the new or malloc to fail. My patch was unrelated to this condition and seemed to fix the issue when infact it did very very little. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080724/05ac8711/signature.pgp From ramzi at lindenlab.com Thu Jul 24 15:54:44 2008 From: ramzi at lindenlab.com (Ramzi) Date: Thu Jul 24 15:54:47 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: <4888A763.4060301@watson.ibm.com> References: <4887CFF6.9030004@gmail.com> <4887DDD0.8030504@lindenlab.com> <4888A763.4060301@watson.ibm.com> Message-ID: <48890834.2050201@lindenlab.com> Yes, it's probably not being applied well uniformly. Another wrinkle is that the reporter may Resolve/Close the issue of their own accord, the very moment that a fix appears in an RC build. (Mike- I think this explains much of that number.) 1. My operative has been to set the status as (still) "Fixed Pending" while the fix is propagating through the RC cycle. (Depending on the person changing it, only some of these have their 'Fix Version' is set too.) 2. When the bug fix appears in an official viewer (to ALL residents), its status can be moved to "Fixed." (And if it has no Fix Version at this point, I'm sure to set it then.) With the official release of viewer 1.20 today, it was on my list to move Fixed Pending->Fixed for the tasks in the 1.20 release notes. I just accomplished this, but the delta was only 28 issues from their status as of this morning... So I may not have made such a big dent in the number Jason mentions at the top of the thread. -Ramzi Mike Monkowski wrote: > I don't think that's being done uniformly. There are 166 VWR bugs > with Fix Version "1.20 Release Candidate". Only six of those have > Status "Fix Pending". > > Mike > > > Ryan Williams (Which) wrote: >> Jason Giglio wrote: >> >>> "Fixed Internally" number is ballooning again. Is there a process to >>> reconcile shipped code? >>> >>> Is code that is released in a RC branch considered fixed, or fixed >>> internally? >> >> I've been treating RC as fixed internally. Perhaps that's wrong? > _ From dmahalko at gmail.com Thu Jul 24 17:27:15 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu Jul 24 17:27:17 2008 Subject: [sldev] Setting up source version control, for beginners? Message-ID: I am (again) starting to poke at the source and I see what a huge undertaking it is to edit a raw directory source files. I have to keep track of what I changed, where I changed it, and what the original looked like in case I ever want to revert my changes or compare to the original. I have absolutely no experience with version control but it looks like I'm going to need to learn how to use it. What would be recommended for a beginner, using Windows XP/Vista and Visual Studio 03/05/08? Hopefully I can use free software since I'm just doing this as a hobby. I see this usually operates using a client/server model of access. Is it enough for me to just use a client, or do I need to also set up my own local repository server? I assume the client could have some small server-like abilities of its own for tracking of projects but I have no idea. I am of the opinion that the process of setting up for version control needs to be one of the steps for preparing to contribute to the open source project. To that end I have created a new article and added it to the "Ways to Participate" portal: https://wiki.secondlife.com/wiki/Creating_a_version_control_repository This is really just a stub for now but I am intending to flesh out the details with any helpful information that experienced programmers may be able to provide in response to this thread. Please add to it if you can. I don't yet know if this article should be part of the regular version control article since this is intended for beginners. That other "main" article seems to be intended for experienced programmers who have already had years of experience working with version control systems. Would it be useful to have separate setup instructions for Windows, Mac, and linux beginners? - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Thu Jul 24 18:29:02 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 24 18:29:05 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: References: Message-ID: <48892C5E.5000601@gmail.com> Dale Mahalko wrote: > I am (again) starting to poke at the source and I see what a huge > undertaking it is to edit a raw directory source files. I have to keep > track of what I changed, where I changed it, and what the original > looked like in case I ever want to revert my changes or compare to the > original. > > I have absolutely no experience with version control but it looks like > I'm going to need to learn how to use it. > No, not really. You can do those basic tasks above with simpler tools. You will need to learn/use diff, patch, and possibly rsync and the svn client only. For just a single user editing the source, you really don't need a full version control server setup. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080724/9615c9da/smime.bin From rdw at lindenlab.com Thu Jul 24 18:39:58 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu Jul 24 18:40:00 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: <48892C5E.5000601@gmail.com> References: <48892C5E.5000601@gmail.com> Message-ID: <48892EEE.4080106@lindenlab.com> Jason Giglio wrote: > Dale Mahalko wrote: > >> I am (again) starting to poke at the source and I see what a huge >> undertaking it is to edit a raw directory source files. I have to keep >> track of what I changed, where I changed it, and what the original >> looked like in case I ever want to revert my changes or compare to the >> original. >> >> I have absolutely no experience with version control but it looks like >> I'm going to need to learn how to use it. >> >> > > No, not really. You can do those basic tasks above with simpler tools. > You will need to learn/use diff, patch, and possibly rsync and the svn > client only. > > For just a single user editing the source, you really don't need a full > version control server setup. > Mercurial is a nice choice for the single-user case because you don't have to set up a server. Just 'hg init' and 'hg addremove' in your directory and you're good to go*. It's all self-contained. -RYaN * Not sure if this is the exactly the precise set of commands you want to issue, but it's pretty close. From bill.hoffman at kitware.com Thu Jul 24 18:57:22 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu Jul 24 18:58:13 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr in Mac build) In-Reply-To: <012c01c8ec8c$0cf3cce0$26db66a0$@rossini@balsaestates.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <012c01c8ec8c$0cf3cce0$26db66a0$@rossini@balsaestates.com> Message-ID: <48893302.50306@kitware.com> Suzhanna Rossini wrote: > > It didn't do any good for me Bill.. > I get a clean build with cmake 2.4.8, and when I used 2.6.1 RC12, I got the > very same errors as I had problems with before when I ran 2.6.0 > > Linking... > llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl > lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void > __thiscall LLFloaterCompileQueue::compile(class > std::basic_string,class > std::allocator > const &,class LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std > @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) > llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl > lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > C:\SLDev\release\indra\build-VS2003\newview\RelWithDebInfo\secondlife-bin.ex > e : fatal error LNK1120: 1 unresolved externals > > /Alexandra. > I am trying to release cmake 2.6.1 and would like to make it work with Secondlife if possible. The only remaining issue is the undefined symbol above. Can someone tell me exactly which version of the SecondLife viewer I would need to build to reproduce this issue? (The Xcode issue should be fixed in cmake 2.6.1 now. ) Thanks -Bill From soft at lindenlab.com Thu Jul 24 20:57:19 2008 From: soft at lindenlab.com (Soft) Date: Thu Jul 24 20:57:22 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <48893302.50306@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> Message-ID: On Thu, Jul 24, 2008 at 8:57 PM, Bill Hoffman wrote: > Suzhanna Rossini wrote: > >> >> It didn't do any good for me Bill.. >> I get a clean build with cmake 2.4.8, and when I used 2.6.1 RC12, I got >> the >> very same errors as I had problems with before when I ran 2.6.0 >> >> Linking... >> llcompilequeue.obj : error LNK2019: unresolved external symbol "int >> __cdecl >> lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void >> __thiscall LLFloaterCompileQueue::compile(class >> std::basic_string,class >> std::allocator > const &,class LLUUID const &)" >> >> (?compile@LLFloaterCompileQueue@@IAEXABV?$basic_string@DU?$char_traits@D@std >> @@V?$allocator@D@2@@std@@ABVLLUUID@@@Z) >> llpreviewscript.obj : error LNK2001: unresolved external symbol "int >> __cdecl >> lscript_compile(char const *,char const *,char const *,int)" >> (?lscript_compile@@YAHPBD00H@Z) >> >> C:\SLDev\release\indra\build-VS2003\newview\RelWithDebInfo\secondlife-bin.ex >> e : fatal error LNK1120: 1 unresolved externals >> >> /Alexandra. >> > > > I am trying to release cmake 2.6.1 and would like to make it work with > Secondlife if possible. The only remaining issue is the undefined symbol > above. Can someone tell me exactly which version of the SecondLife viewer I > would need to build to reproduce this issue? I love that you're doing this. It looks as though she's working off the release branch. There have been no notable cmake changes of recent, so pulling from head should be sufficient. The svn: http://svn.secondlife.com/svn/linden/release/ The quick version: You would need to unpack the library and artwork tarballs for your platform into the tree. These are linked from doc/asset_urls.txt. In addition, you will need to install fmod 3.75, which we can't redistribute ourselves: http://www.fmod.org/index.php/download#FMOD3ProgrammersAPI The long version: http://wiki.secondlife.com/wiki/CMake That doesn't yet include instructions on where to copy fmod, and what additional libraries are needed if building Linux. That can be pulled from the myriad of old per-platform instructions: http://wiki.secondlife.com/wiki/Get_source_and_compile From kf6kjg at gmail.com Thu Jul 24 21:23:12 2008 From: kf6kjg at gmail.com (Ricky) Date: Thu Jul 24 21:23:14 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: <48892EEE.4080106@lindenlab.com> References: <48892C5E.5000601@gmail.com> <48892EEE.4080106@lindenlab.com> Message-ID: <3bb9647e0807242123g11717af8iddb23dbf6d9cda7e@mail.gmail.com> On Windoze I find that I like TortoiseSVN ( http://tortoisesvn.tigris.org/ ) for accessing existing repositories. If you want a standalone versioning system... I'm at a loss... I've always built a full Subversion repository on my Linux box. Not hard to do on most common distros. Ricky On Thu, Jul 24, 2008 at 6:39 PM, Ryan Williams (Which) wrote: > Jason Giglio wrote: > >> Dale Mahalko wrote: >> >> >>> I am (again) starting to poke at the source and I see what a huge >>> undertaking it is to edit a raw directory source files. I have to keep >>> track of what I changed, where I changed it, and what the original >>> looked like in case I ever want to revert my changes or compare to the >>> original. >>> >>> I have absolutely no experience with version control but it looks like >>> I'm going to need to learn how to use it. >>> >>> >>> >> >> No, not really. You can do those basic tasks above with simpler tools. >> You will need to learn/use diff, patch, and possibly rsync and the svn >> client only. >> >> For just a single user editing the source, you really don't need a full >> version control server setup. >> >> > Mercurial is a nice choice for the single-user case because you don't have > to set up a server. Just 'hg init' and 'hg addremove' in your directory and > you're good to go*. It's all self-contained. > > -RYaN > > * Not sure if this is the exactly the precise set of commands you want to > issue, but it's pretty close. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080724/3953318a/attachment.htm From kel at ouchies.org Thu Jul 24 22:35:05 2008 From: kel at ouchies.org (Kel Hartunian) Date: Thu Jul 24 22:35:10 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: <3bb9647e0807242123g11717af8iddb23dbf6d9cda7e@mail.gmail.com> References: <48892C5E.5000601@gmail.com> <48892EEE.4080106@lindenlab.com> <3bb9647e0807242123g11717af8iddb23dbf6d9cda7e@mail.gmail.com> Message-ID: <48896609.8060603@ouchies.org> Ricky wrote: > On Windoze I find that I like TortoiseSVN ( > http://tortoisesvn.tigris.org/ ) for accessing existing repositories. > > If you want a standalone versioning system... I'm at a loss... I've > always built a full Subversion repository on my Linux box. Not hard > to do on most common distros. > > Ricky > > On Thu, Jul 24, 2008 at 6:39 PM, Ryan Williams (Which) > > wrote: > > Jason Giglio wrote: > > Dale Mahalko wrote: > > > I am (again) starting to poke at the source and I see what > a huge > undertaking it is to edit a raw directory source files. I > have to keep > track of what I changed, where I changed it, and what the > original > looked like in case I ever want to revert my changes or > compare to the > original. > > I have absolutely no experience with version control but > it looks like > I'm going to need to learn how to use it. > > > > > No, not really. You can do those basic tasks above with > simpler tools. > You will need to learn/use diff, patch, and possibly rsync > and the svn > client only. > > For just a single user editing the source, you really don't > need a full > version control server setup. > > > Mercurial is a nice choice for the single-user case because you > don't have to set up a server. Just 'hg init' and 'hg addremove' > in your directory and you're good to go*. It's all self-contained. > > -RYaN > > * Not sure if this is the exactly the precise set of commands you > want to issue, but it's pretty close. > > I'm going to be teaching a high school computer programming course this year. The language will be Java, since that's what the UIL uses and the College Board uses for their CS courses. After this year, I'll be making it an AP course. Anyway, I want to let my students utilize the greatness of version control, but I'd like to use an accessible, "learn in an hour and go" solution for the kids. Does anyone have a suggestion? Server based is fine, as I'll be setting up an Ubuntu server for some different projects the kids'll be doing. -Kel From kf6kjg at gmail.com Thu Jul 24 23:14:01 2008 From: kf6kjg at gmail.com (Ricky) Date: Thu Jul 24 23:14:03 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: <48896609.8060603@ouchies.org> References: <48892C5E.5000601@gmail.com> <48892EEE.4080106@lindenlab.com> <3bb9647e0807242123g11717af8iddb23dbf6d9cda7e@mail.gmail.com> <48896609.8060603@ouchies.org> Message-ID: <3bb9647e0807242314p2d040fa1j59cff1900e812f6d@mail.gmail.com> If you use Eclipse, you can repackage the program with Subversive streamlined in. Eclipse is great for developing in Java and has support for versioning built-in and more. If you want to know more, or if you are not sure how to work with Eclipse, etc, just email me offlist. Got to keep this list concentrated on SL development. ;-) Ricky On Thu, Jul 24, 2008 at 10:35 PM, Kel Hartunian wrote: > Ricky wrote: > > On Windoze I find that I like TortoiseSVN ( > > http://tortoisesvn.tigris.org/ ) for accessing existing repositories. > > > > If you want a standalone versioning system... I'm at a loss... I've > > always built a full Subversion repository on my Linux box. Not hard > > to do on most common distros. > > > > Ricky > > > > On Thu, Jul 24, 2008 at 6:39 PM, Ryan Williams (Which) > > > wrote: > > > > Jason Giglio wrote: > > > > Dale Mahalko wrote: > > > > > > I am (again) starting to poke at the source and I see what > > a huge > > undertaking it is to edit a raw directory source files. I > > have to keep > > track of what I changed, where I changed it, and what the > > original > > looked like in case I ever want to revert my changes or > > compare to the > > original. > > > > I have absolutely no experience with version control but > > it looks like > > I'm going to need to learn how to use it. > > > > > > > > > > No, not really. You can do those basic tasks above with > > simpler tools. > > You will need to learn/use diff, patch, and possibly rsync > > and the svn > > client only. > > > > For just a single user editing the source, you really don't > > need a full > > version control server setup. > > > > > > Mercurial is a nice choice for the single-user case because you > > don't have to set up a server. Just 'hg init' and 'hg addremove' > > in your directory and you're good to go*. It's all self-contained. > > > > -RYaN > > > > * Not sure if this is the exactly the precise set of commands you > > want to issue, but it's pretty close. > > > > > > I'm going to be teaching a high school computer programming course this > year. The language will be Java, since that's what the UIL uses and the > College Board uses for their CS courses. After this year, I'll be > making it an AP course. > > Anyway, I want to let my students utilize the greatness of version > control, but I'd like to use an accessible, "learn in an hour and go" > solution for the kids. Does anyone have a suggestion? Server based is > fine, as I'll be setting up an Ubuntu server for some different projects > the kids'll be doing. > > -Kel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080724/20e77d44/attachment.htm From GordonWendt at gmail.com Fri Jul 25 00:56:14 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri Jul 25 00:56:17 2008 Subject: [sldev] There has to be a better way (or how I learned to stop worrying but still continuing to hate trying to compile the sl source code) Message-ID: <493033a70807250056s2ba6a346qce1be80a88d99ad0@mail.gmail.com> I apologize in advance for the fact that this post is only half constructive and the other half is pure gripe, if you have ever been a non programmer trying to compile source code on a compiler that is not the one originally used you will know how I am feeling right now. There has to be a better way to deal with compiling the source code. A bit of background, tonight I made my first serious effort to try to get via svn and compile the sl source code, my system is WinXP SP3 and I have Microsoft Visual Studio 2005 pro. SVN is simple and getting the source code was fine then I attempted to deal with compiling the source code. Even the various instructions (which seem to be woefully out of date in some cases) on the wiki pretty much state that it is a lost cause UNLESS you are using Microsoft Visual Studio 2003. I made it about halfway through the 2nd or 3rd install required to even get the base tools needed for the install before giving up, rolling everything back or uninstlaling as it may warrant and literally saying "*** this (I'd rather not self censor but more importantly I'd also rather not be removed for cursing). My constructive statement is that even knowing enough about programming to know that there are idiosyncrisis between compilers and that even though a coding language is designed to be standard doesn't mean that it's standard between compilers (a distinction which to this day baffles me to because it is supposedly one of the reasonings we even have coding languages), however between the impossibility of even getting to the libraries stage of preperation and the fact that even if I had you have to essentially hack (in the constructive and proper sense) the system to get the libraries needed you have what is essentially an impenetrable barrier to 99.999...% of those interested in actually compiling the source code. I of course realize that the compilers issue is not at all LL's fault or anyone else specifically's fault but just a byproduct of many fragmented and disorganized systems and the library issue is one that LL is (supposedly) slowly working to resolve by bringing in free libraries where available to replace closed ones however I re-iterate that there has to be a better way forward for all this which I'm hoping that the discussion spawned by this ongwinded and ranting post by an insomniac second life user will bring about. -Gordon Wendt P.S. I do try to have fun with my posts so please don't construe the subtle and not so subtle references and in-humor to be degrading my message however if you think you've found them all feel free to send me an IM noting them and I may send you a small prize. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/c103dd9f/attachment-0001.htm From matthew.dowd at hotmail.co.uk Fri Jul 25 01:44:59 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jul 25 01:45:01 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: <48890834.2050201@lindenlab.com> References: <4887CFF6.9030004@gmail.com> <4887DDD0.8030504@lindenlab.com> <4888A763.4060301@watson.ibm.com> <48890834.2050201@lindenlab.com> Message-ID: Is it possible to (easily) distinguish between a "fixed pending" which is in the RC cycle, and a "fixed pending" which is still in some internal branch yet to be folded into the RC cycle at some as yet undecided stage? Matthew> Date: Thu, 24 Jul 2008 15:54:44 -0700> From: ramzi@lindenlab.com> To: monkowsk@watson.ibm.com> Subject: Re: [sldev] Fixed Internally resolution.> CC: sldev@lists.secondlife.com; rdw@lindenlab.com> > Yes, it's probably not being applied well uniformly. Another wrinkle is > that the reporter may Resolve/Close the issue of their own accord, the > very moment that a fix appears in an RC build. (Mike- I think this > explains much of that number.)> > 1. My operative has been to set the status as (still) "Fixed Pending" > while the fix is propagating through the RC cycle. (Depending on the > person changing it, only some of these have their 'Fix Version' is set too.)> 2. When the bug fix appears in an official viewer (to ALL residents), > its status can be moved to "Fixed." (And if it has no Fix Version at > this point, I'm sure to set it then.)> > With the official release of viewer 1.20 today, it was on my list to > move Fixed Pending->Fixed for the tasks in the 1.20 release notes. I > just accomplished this, but the delta was only 28 issues from their > status as of this morning... So I may not have made such a big dent in > the number Jason mentions at the top of the thread.> -Ramzi> > > Mike Monkowski wrote:> > I don't think that's being done uniformly. There are 166 VWR bugs > > with Fix Version "1.20 Release Candidate". Only six of those have > > Status "Fix Pending".> >> > Mike> >> >> > Ryan Williams (Which) wrote:> >> Jason Giglio wrote:> >>> >>> "Fixed Internally" number is ballooning again. Is there a process to> >>> reconcile shipped code?> >>>> >>> Is code that is released in a RC branch considered fixed, or fixed> >>> internally? > >>> >> I've been treating RC as fixed internally. Perhaps that's wrong?> > _> > _______________________________________________> Policies and (un)subscribe information available here:> http://wiki.secondlife.com/wiki/SLDev> Please read the policies before posting to keep unmoderated posting privileges _________________________________________________________________ 100?s of Nikon cameras to be won with Live Search http://clk.atdmt.com/UKM/go/101719808/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/e2e4348d/attachment.htm From sllists at boroon.dasgupta.ch Fri Jul 25 02:13:33 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri Jul 25 02:13:37 2008 Subject: There will be a better way (was: [sldev] There has to be a better way (or how I learned to stop worrying but still continuing to hate trying to compile the sl source code)) In-Reply-To: <493033a70807250056s2ba6a346qce1be80a88d99ad0@mail.gmail.com> References: <493033a70807250056s2ba6a346qce1be80a88d99ad0@mail.gmail.com> Message-ID: <4889993D.8090600@boroon.dasgupta.ch> http://wiki.secondlife.com/wiki/CMake I don't know if this will help with dependency hell, but at least the barriers between different IDEs should become lower. It won't fix/work around compiler incompatibilities, that has to be done by either writing portable code or #ifdef compiler macros. As far as I can tell, secondlife is already quite good at that. (It can be compiled and run on at least tree completely different platforms!) As the current head of the "release" branch already uses CMake, all documentation not reflecting this is definitely out of date, when applied to the code checked out from there. I think Soft once said that if you haven't already, there isn't much sense in still learning the old (pre-CMake) build system. Better to wait until the new way is documented enough for new coders (or non-coders) to be followed. cheers Boroondas From mark at identityserver.net Fri Jul 25 04:11:25 2008 From: mark at identityserver.net (Domino Marama) Date: Fri Jul 25 04:11:33 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: <48896609.8060603@ouchies.org> References: <48892C5E.5000601@gmail.com> <48892EEE.4080106@lindenlab.com> <3bb9647e0807242123g11717af8iddb23dbf6d9cda7e@mail.gmail.com> <48896609.8060603@ouchies.org> Message-ID: <1216984285.9351.11.camel@domino-laptop> > Anyway, I want to let my students utilize the greatness of version > control, but I'd like to use an accessible, "learn in an hour and go" > solution for the kids. Does anyone have a suggestion? Server based is > fine, as I'll be setting up an Ubuntu server for some different projects > the kids'll be doing. > > -Kel I'd recommend GIT or another non-centralised VCS. GIT is easy to setup on a server too. Pushes are done over SSH and as repositories can be shared over HTTP, it's easy to include a lesson on the kids setting up their own repositories. http://dominodesigns.info/second_life/blender_scripts_git.html has links at right for GIT. From danteferret at gmail.com Fri Jul 25 09:52:03 2008 From: danteferret at gmail.com (Dante Tucker) Date: Fri Jul 25 09:52:07 2008 Subject: There will be a better way (was: [sldev] There has to be a better way (or how I learned to stop worrying but still continuing to hate trying to compile the sl source code)) In-Reply-To: <4889993D.8090600@boroon.dasgupta.ch> References: <493033a70807250056s2ba6a346qce1be80a88d99ad0@mail.gmail.com> <4889993D.8090600@boroon.dasgupta.ch> Message-ID: <4d211a610807250952q10d05a47v1390f15790f9a922@mail.gmail.com> Is it possible for someone to post a link to complete instructions on building the current CMake viewer? Or do these not exist yet? I had absolutely no problem building the viewer under the previous system. However now that it has changed I am not sure where to even start. A complete start to finish guide would be nice. On Fri, Jul 25, 2008 at 5:13 AM, Boroondas Gupte wrote: > http://wiki.secondlife.com/wiki/CMake > I don't know if this will help with dependency hell, but at least the > barriers between different IDEs should become lower. It won't fix/work > around compiler incompatibilities, that has to be done by either writing > portable code or #ifdef compiler macros. As far as I can tell, secondlife is > already quite good at that. (It can be compiled and run on at least tree > completely different platforms!) > > As the current head of the "release" branch already uses CMake, all > documentation not reflecting this is definitely out of date, when applied to > the code checked out from there. I think Soft once said that if you haven't > already, there isn't much sense in still learning the old (pre-CMake) build > system. Better to wait until the new way is documented enough for new coders > (or non-coders) to be followed. > > cheers > Boroondas > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/d7544671/attachment.htm From robin.cornelius at gmail.com Fri Jul 25 10:21:55 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jul 25 10:22:02 2008 Subject: [sldev] Re: There will be a better way In-Reply-To: <4d211a610807250952q10d05a47v1390f15790f9a922@mail.gmail.com> References: <493033a70807250056s2ba6a346qce1be80a88d99ad0@mail.gmail.com> <4889993D.8090600@boroon.dasgupta.ch> <4d211a610807250952q10d05a47v1390f15790f9a922@mail.gmail.com> Message-ID: <488A0BB3.4080602@gmail.com> Dante Tucker wrote: > Is it possible for someone to post a link to complete instructions on > building the current CMake viewer? Or do these not exist yet? > > I had absolutely no problem building the viewer under the previous > system. However now that it has changed I am not sure where to even start. > > A complete start to finish guide would be nice. > Yes it would, I started a while ago, but never quite finished it :- http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake It may be out of date now or have holes, but please if it is even useful fill gaps and correct mistakes Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080725/5d1e12f5/signature.pgp From kf6kjg at gmail.com Fri Jul 25 10:35:12 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Jul 25 10:35:23 2008 Subject: [sldev] Get Source and Compile page update Message-ID: <3bb9647e0807251035g4c9f9f4eo76c9140693a3da39@mail.gmail.com> I just added a link to the CMake instructions so new potential devs can find the CMake page. If anybody could help flesh out the link list, and perhaps help flesh out the library install requirements on the CMake page to something more meaningful to a noob than "dig about the old compile pages"... :-) Thanks! Ricky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/c030ae0a/attachment.htm From soft at lindenlab.com Fri Jul 25 10:56:08 2008 From: soft at lindenlab.com (Soft) Date: Fri Jul 25 10:56:10 2008 Subject: [sldev] Better build instructions Message-ID: A complete guide for cmake that's inclusive of all library copies and system setup steps does not yet exist. 1.21/ will branch from release/ shortly, so it's just about time. We can use the existing cmake page as a base, but this time around I'd really like to avoid two things. I think these are to blame for the current confusing instructions: 1) Avoid having separate pages for every platform and compiler combination. cmake unifies many of the build and configuration steps. Most things developers care about can be explained conceptually. "Open the project in your cmake target directory and select the debug build" can replace specific references to XCode, KDevelop, Visual Studio, etc. on separate pages. "Be sure python 2.5 is installed" - if we really need to delve into where to find it, we can do better than a page per platform. A single python page makes more sense than five different rewordings of the same concept buried in five different pages. 2) Stop reusing the same wiki page for every viewer version. Build steps will continue to change in the future. I would rather we copy and archive build instructions for prior versions. Right now, we have instructions peppered all throughout the documentation saying "If your tree is newer than 1.18.5..." or "Before 1.20..." I would rather we have a release build page, then fork that and label it with the applicable versions when build steps will change substantially. Are these two things agreeable? What else can we do to avoid these things ballooning unmanageably? On Fri, Jul 25, 2008 at 11:52 AM, Dante Tucker wrote: > Is it possible for someone to post a link to complete instructions on > building the current CMake viewer? Or do these not exist yet? > > I had absolutely no problem building the viewer under the previous system. > However now that it has changed I am not sure where to even start. > > A complete start to finish guide would be nice. > > > On Fri, Jul 25, 2008 at 5:13 AM, Boroondas Gupte > wrote: >> >> http://wiki.secondlife.com/wiki/CMake >> I don't know if this will help with dependency hell, but at least the >> barriers between different IDEs should become lower. It won't fix/work >> around compiler incompatibilities, that has to be done by either writing >> portable code or #ifdef compiler macros. As far as I can tell, secondlife is >> already quite good at that. (It can be compiled and run on at least tree >> completely different platforms!) >> >> As the current head of the "release" branch already uses CMake, all >> documentation not reflecting this is definitely out of date, when applied to >> the code checked out from there. I think Soft once said that if you haven't >> already, there isn't much sense in still learning the old (pre-CMake) build >> system. Better to wait until the new way is documented enough for new coders >> (or non-coders) to be followed. >> >> cheers >> Boroondas >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From kf6kjg at gmail.com Fri Jul 25 11:02:51 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Jul 25 11:02:54 2008 Subject: [sldev] Better build instructions In-Reply-To: References: Message-ID: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> I whole-heartedly agre on Point 1. On point #2 however.. Maybe we can keep using existing pages, but add a sidebar linking to the old revisions of the page where each build instruction set had been completed before the change. This would require some discipline to keep maintained, but I think it is better than cluttering the Wiki with a bunch of new pages, and having to remember to update links on other pages scattered all over the wiki. :-) Ricky On Fri, Jul 25, 2008 at 10:56 AM, Soft wrote: > A complete guide for cmake that's inclusive of all library copies and > system setup steps does not yet exist. 1.21/ will branch from release/ > shortly, so it's just about time. > > We can use the existing cmake page as a base, but this time around I'd > really like to avoid two things. I think these are to blame for the > current confusing instructions: > > 1) Avoid having separate pages for every platform and compiler > combination. cmake unifies many of the build and configuration steps. > Most things developers care about can be explained conceptually. "Open > the project in your cmake target directory and select the debug build" > can replace specific references to XCode, KDevelop, Visual Studio, > etc. on separate pages. "Be sure python 2.5 is installed" - if we > really need to delve into where to find it, we can do better than a > page per platform. A single python page makes more sense than five > different rewordings of the same concept buried in five different > pages. > > 2) Stop reusing the same wiki page for every viewer version. Build > steps will continue to change in the future. I would rather we copy > and archive build instructions for prior versions. Right now, we have > instructions peppered all throughout the documentation saying "If your > tree is newer than 1.18.5..." or "Before 1.20..." I would rather we > have a release build page, then fork that and label it with the > applicable versions when build steps will change substantially. > > Are these two things agreeable? What else can we do to avoid these > things ballooning unmanageably? > > > On Fri, Jul 25, 2008 at 11:52 AM, Dante Tucker > wrote: > > Is it possible for someone to post a link to complete instructions on > > building the current CMake viewer? Or do these not exist yet? > > > > I had absolutely no problem building the viewer under the previous > system. > > However now that it has changed I am not sure where to even start. > > > > A complete start to finish guide would be nice. > > > > > > On Fri, Jul 25, 2008 at 5:13 AM, Boroondas Gupte > > wrote: > >> > >> http://wiki.secondlife.com/wiki/CMake > >> I don't know if this will help with dependency hell, but at least the > >> barriers between different IDEs should become lower. It won't fix/work > >> around compiler incompatibilities, that has to be done by either writing > >> portable code or #ifdef compiler macros. As far as I can tell, > secondlife is > >> already quite good at that. (It can be compiled and run on at least tree > >> completely different platforms!) > >> > >> As the current head of the "release" branch already uses CMake, all > >> documentation not reflecting this is definitely out of date, when > applied to > >> the code checked out from there. I think Soft once said that if you > haven't > >> already, there isn't much sense in still learning the old (pre-CMake) > build > >> system. Better to wait until the new way is documented enough for new > coders > >> (or non-coders) to be followed. > >> > >> cheers > >> Boroondas > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/730b5ab1/attachment.htm From robin.cornelius at gmail.com Fri Jul 25 11:31:39 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Jul 25 11:31:44 2008 Subject: [sldev] Better build instructions In-Reply-To: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> Message-ID: <488A1C0B.4060909@gmail.com> Ricky wrote: > I whole-heartedly agre on Point 1. > > On point #2 however.. Maybe we can keep using existing pages, but add a > sidebar linking to the old revisions of the page where each build > instruction set had been completed before the change. > > This would require some discipline to keep maintained, but I think it is > better than cluttering the Wiki with a bunch of new pages, and having to > remember to update links on other pages scattered all over the wiki. :-) > I don't think it would generate that much page clutter, the build instructions are not going to change every release and i think its worth keeping the history of how version X was built. It would be particularly useful if there are large changes then its possible to start on the new versions as it goes through RC but keep the old ones very much up front to avoid user confusion. Just add an index page that links to each version. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080725/a2a27315/signature.pgp From tongb at ohio.edu Fri Jul 25 11:35:45 2008 From: tongb at ohio.edu (Bruce Tong) Date: Fri Jul 25 11:35:46 2008 Subject: [sldev] Better build instructions In-Reply-To: References: Message-ID: <4f335a50807251135s28920a8br3e9161940e08d1c7@mail.gmail.com> It's been a while since I've had a chance to look into building. I remember using about five wiki pages, each talking about the build process from a different angle. This got me to the point where cmake wasn't able to communicate something with the freebie visual studio 2005. * I do remember Michell2's (sorry, probably butchering the name) page as being the most helpful. * Something akin to a step-by-step list is desirable to me, at my level of familiarity with viewer builds. * If the generic step-by-step has to go into platform specific things, linking to small, very specific and topical pages seems reasonable. And when done there, return to the main page. I think that approach should be viable. -- Bruce Tong Software Engineer Office of Information Technology Ohio University From kf6kjg at gmail.com Fri Jul 25 13:06:00 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Jul 25 13:06:03 2008 Subject: [sldev] Better build instructions In-Reply-To: <488A1C0B.4060909@gmail.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> Message-ID: <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> I fully agree that the old versions should be still referenced, and that the instructions shouldn't change too dramatically between each individual version. I also see your point about the ability to keep articles pointed at the old version until the new one is ready. But maybe I am under a wrong assumption here, but I thought that most /new/ developers will want to pull from trunk on the SVN. If that assumption is true, (it was for me...) then the most visible article should be the absolute latest. If someone then wants to build an older (including the mainstream/released,) client then all they have to do is select the link to the archived edition of the instructions as they were for that edition. The biggest cases that I can think of against my modification of Soft's idea are as follows: 1: If the most common new developer (see note) DOESN'T want to get the latest edition of the code. I don't understand why they wouldn't... Maybe some enlightenment for me? 2: If the build article is converted to a new set of instructions before the old instructions are fleshed out and working. This would make correcting the old edition impossible, whereas separate articles would make it possible. The benefits as I see them for my idea are summed up as follows: (In no particular order) * Less distinct articles to hunt around in. * The "default" view of the build article is the latest edition by default. * Not having to re-work all the links to the current build article in order to bring the new build article online. Things in common: * There should be an index, whether sidebar or distinct article, to all the old editions. So if my assumptions seem invalid, then by all means, lets make distinct articles for each time the system changes. But if not, then let us consider not making the system harder to maintain. Ricky NOTE: The reason I only consider new developers here is because an existent developer will ALREADY know how to work with the codebase they are working against... :-) NOTE2: What I mean by sidebar is a div or table set to float on the right side of the build article. On Fri, Jul 25, 2008 at 11:31 AM, Robin Cornelius wrote: > Ricky wrote: > > I whole-heartedly agre on Point 1. > > > > On point #2 however.. Maybe we can keep using existing pages, but add a > > sidebar linking to the old revisions of the page where each build > > instruction set had been completed before the change. > > > > This would require some discipline to keep maintained, but I think it is > > better than cluttering the Wiki with a bunch of new pages, and having to > > remember to update links on other pages scattered all over the wiki. :-) > > > > I don't think it would generate that much page clutter, the build > instructions are not going to change every release and i think its worth > keeping the history of how version X was built. It would be particularly > useful if there are large changes then its possible to start on the new > versions as it goes through RC but keep the old ones very much up front > to avoid user confusion. > > Just add an index page that links to each version. > > Robin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/bf49b054/attachment.htm From kf6kjg at gmail.com Fri Jul 25 13:09:01 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Jul 25 13:09:04 2008 Subject: [sldev] Better build instructions In-Reply-To: <4f335a50807251135s28920a8br3e9161940e08d1c7@mail.gmail.com> References: <4f335a50807251135s28920a8br3e9161940e08d1c7@mail.gmail.com> Message-ID: <3bb9647e0807251309y44b9126cj35348db13519160@mail.gmail.com> Yes. I like your ideas here. Especially the last one. We should most definitely only separate instructions where they need to be distinct, and only if they get too unwieldy to all be on the same page. This is much like how Wikipedia seems to work. Ricky On Fri, Jul 25, 2008 at 11:35 AM, Bruce Tong wrote: > It's been a while since I've had a chance to look into building. I > remember using about five wiki pages, each talking about the build > process from a different angle. This got me to the point where cmake > wasn't able to communicate something with the freebie visual studio > 2005. > > * I do remember Michell2's (sorry, probably butchering the name) page > as being the most helpful. > > * Something akin to a step-by-step list is desirable to me, at my > level of familiarity with viewer builds. > > * If the generic step-by-step has to go into platform specific things, > linking to small, very specific and topical pages seems reasonable. > And when done there, return to the main page. I think that approach > should be viable. > > -- > Bruce Tong > Software Engineer > Office of Information Technology > Ohio University > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/c7996e32/attachment.htm From monkowsk at watson.ibm.com Fri Jul 25 13:10:15 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jul 25 13:10:25 2008 Subject: [sldev] Better build instructions In-Reply-To: References: Message-ID: <488A3327.6000907@watson.ibm.com> Soft wrote: > 1) Avoid having separate pages for every platform and compiler > combination. This happened because very few developers build on more than one platform. The only ones that consistently do are Linden developers and they haven't contributed much to the wiki build pages in the past. Also, there isn't much duplication across the different pages because they really need to be different. Let's see if CMake can change that. And let's not have any #ifdef equivalents in the documentation. I hate skipping around "...and if you're on Mac OS/X...and if you're on VS2008...and if you're on Ubuntu..." If it requires that nonsense, split them. Even if I do build on multiple platforms, I am doing only one at a time on one platform. Keep it simple. Mike From monkowsk at watson.ibm.com Fri Jul 25 13:45:43 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jul 25 13:46:14 2008 Subject: [sldev] Better build instructions In-Reply-To: <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> Message-ID: <488A3B77.1060401@watson.ibm.com> Ricky wrote: > 1: If the most common new developer (see note) DOESN'T want to get the > latest edition of the code. I don't understand why they wouldn't... > Maybe some enlightenment for me? If you want to make a code change and you want to allow many people to use it without much hassle, then you want to distribute as little as possible, usually only the viewer executable, and let others just drop it into the existing installation. This means the stable version and the release candidates and an occasional First Look. I have never built from the trunk and I don't see any reason I would want to. :-) Mike From josh at lindenlab.com Fri Jul 25 14:07:00 2008 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jul 25 14:07:04 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: References: <4887CFF6.9030004@gmail.com> <4887DDD0.8030504@lindenlab.com><4888A763.4060301@watson.ibm.com> <48890834.2050201@lindenlab.com> Message-ID: <488A4074.4090701@lindenlab.com> This should be indicated by setting the Fix Version as soon as it's in an RC. No Fix Version should imply that it's not folded into any particular release yet. That's how we track fixes internally. Odds are there will be some lag, since correct representation of issue status in JIRA is important but not a blocker for releases. (Once I get that cloning machine up and running for my team, though...) Matthew Dowd wrote: > Is it possible to (easily) distinguish between a "fixed pending" which > is in the RC cycle, and a "fixed pending" which is still in some > internal branch yet to be folded into the RC cycle at some as yet > undecided stage? > Matthew > > > > Date: Thu, 24 Jul 2008 15:54:44 -0700 > > From: ramzi@lindenlab.com > > To: monkowsk@watson.ibm.com > > Subject: Re: [sldev] Fixed Internally resolution. > > CC: sldev@lists.secondlife.com; rdw@lindenlab.com > > > > Yes, it's probably not being applied well uniformly. Another wrinkle is > > that the reporter may Resolve/Close the issue of their own accord, the > > very moment that a fix appears in an RC build. (Mike- I think this > > explains much of that number.) > > > > 1. My operative has been to set the status as (still) "Fixed Pending" > > while the fix is propagating through the RC cycle. (Depending on the > > person changing it, only some of these have their 'Fix Version' is > set too.) > > 2. When the bug fix appears in an official viewer (to ALL residents), > > its status can be moved to "Fixed." (And if it has no Fix Version at > > this point, I'm sure to set it then.) > > > > With the official release of viewer 1.20 today, it was on my list to > > move Fixed Pending->Fixed for the tasks in the 1.20 release notes. I > > just accomplished this, but the delta was only 28 issues from their > > status as of this morning... So I may not have made such a big dent in > > the number Jason mentions at the top of the thread. > > -Ramzi > > > > > > Mike Monkowski wrote: > > > I don't think that's being done uniformly. There are 166 VWR bugs > > > with Fix Version "1.20 Release Candidate". Only six of those have > > > Status "Fix Pending". > > > > > > Mike > > > > > > > > > Ryan Williams (Which) wrote: > > >> Jason Giglio wrote: > > >> > > >>> "Fixed Internally" number is ballooning again. Is there a process to > > >>> reconcile shipped code? > > >>> > > >>> Is code that is released in a RC branch considered fixed, or fixed > > >>> internally? > > >> > > >> I've been treating RC as fixed internally. Perhaps that's wrong? > > > _ > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > ------------------------------------------------------------------------ > Get Hotmail on your Mobile! Try it Now! > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From kf6kjg at gmail.com Fri Jul 25 14:08:36 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Jul 25 14:08:39 2008 Subject: [sldev] Better build instructions In-Reply-To: <488A3B77.1060401@watson.ibm.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> <488A3B77.1060401@watson.ibm.com> Message-ID: <3bb9647e0807251408m11012a64g532289d44af01cd2@mail.gmail.com> Thanks for the enlightenment! :D If this is common, then the biggest pillar I was standing upon will have withered away, and we should build distinct articles for each new build process. If we do go that route, the neext question is how do we know when to just tweak the existing article, and when to split a new article? Do we only ever split? In the case of swithcing from the old build system to CMake, I can see the logic. But what happens when only one or two dependencies are changed? Or if a script is adjusted to make the workflow smoother? Etc. Large and sudden changes in build system makes it easy to know to make a new split, but small incremental changes can hurt just as badly after a few of them come into play. Ricky On Fri, Jul 25, 2008 at 1:45 PM, Mike Monkowski wrote: > Ricky wrote: > >> 1: If the most common new developer (see note) DOESN'T want to get the >> latest edition of the code. I don't understand why they wouldn't... Maybe >> some enlightenment for me? >> > > If you want to make a code change and you want to allow many people to use > it without much hassle, then you want to distribute as little as possible, > usually only the viewer executable, and let others just drop it into the > existing installation. This means the stable version and the release > candidates and an occasional First Look. > > I have never built from the trunk and I don't see any reason I would want > to. :-) > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/3fa2d5e6/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Jul 25 14:58:52 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri Jul 25 14:58:57 2008 Subject: Criterion for forking build instructions for new source versions (was: [sldev] Better build instructions) In-Reply-To: <3bb9647e0807251408m11012a64g532289d44af01cd2@mail.gmail.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> <488A3B77.1060401@watson.ibm.com> <3bb9647e0807251408m11012a64g532289d44af01cd2@mail.gmail.com> Message-ID: <488A4C9C.4030101@boroon.dasgupta.ch> Ricky schrieb: > the neext question is how do we know when to just tweak the existing > article, and when to split a new article? Do we only ever split? Coming up with a criterion is easy. The difficult part will be to apply it: My suggestion: Whenever it is possible to change the description so it'll *keep working for the versions it used to apply to*, as well as to one (or more) additional version(s), just modify the article (as long as things stay practical and readable, that is). If that can't be done in a reasonable way, fork the article. To determine when that's the case -- well, the wiki articles do have discussion pages. Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/fb6cceee/attachment.htm From qarl at lindenlab.com Fri Jul 25 15:09:43 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Fri Jul 25 15:09:45 2008 Subject: [sldev] screen space ambient occlusion Message-ID: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> so - it's not my project - i have almost nothing to do with it - but i saw some screenshots today that i MUST share. screen space ambient occlusion is the je-ne-sais-quoi of rendering realism: http://picasaweb.google.com/Runitai/DeferredRendering/photo#5227024709133778722 K. From jhurliman at jhurliman.org Fri Jul 25 16:51:59 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Fri Jul 25 16:52:01 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> Message-ID: Unless you're rendering something with alpha transparency ;-). But speaking of this, how is the shadow-draft branch coming along? Does that screenshot show the new gaussian blur setting? Is the branch usable for checkout-and-compile? On Fri, Jul 25, 2008 at 3:09 PM, Karl Stiefvater wrote: > so - it's not my project - i have almost nothing to do with it - but i saw > some screenshots today that i MUST share. > > screen space ambient occlusion is the je-ne-sais-quoi of rendering realism: > > > http://picasaweb.google.com/Runitai/DeferredRendering/photo#5227024709133778722 > > > K. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/4a15a425/attachment.htm From robla at lindenlab.com Fri Jul 25 17:38:23 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jul 25 17:38:35 2008 Subject: Criterion for forking build instructions for new source versions(was: [sldev] Better build instructions) In-Reply-To: <488A4C9C.4030101@boroon.dasgupta.ch> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> <488A3B77.1060401@watson.ibm.com><3bb9647e0807251408m11012a64g532289d44af01cd2@mail.gmail.com> <488A4C9C.4030101@boroon.dasgupta.ch> Message-ID: <488A71FF.1010409@lindenlab.com> On 07/25/2008 02:58 PM, Boroondas Gupte wrote: > Ricky schrieb: >> the neext question is how do we know when to just tweak the existing >> article, and when to split a new article? Do we only ever split? > Coming up with a criterion is easy. The difficult part will be to > apply it: > > My suggestion: Whenever it is possible to change the description so > it'll *keep working for the versions it used to apply to*, as well as > to one (or more) additional version(s), just modify the article (as > long as things stay practical and readable, that is). If that can't be > done in a reasonable way, fork the article. > > To determine when that's the case -- well, the wiki articles do have > discussion pages. Another important consideration: consider inbound links, and keep the *links* up-to-date. We need to consider that people will be deep linking to this wiki from unexpected places, and search engine results may not always be optimal. For example, the page "Compiling the viewer (MSVS2003)" currently has no disclaimer in the title that it only applies to 1.20 and older. When 1.21 is released (and maybe earlier), the ideal solution would be to fix that, and for the following: 1. Rename "Compiling the viewer (MSVS2003)" to "Compiling the viewer (MSVS2003 - 1.20 and earlier)" with a new disclaimer added to the top 2. A redirect from "Compiling the viewer (MSVS2003)" be placed to whatever article tells you how to compile the viewer using CMake, since someone who tries to visit that page title probably wants to build the latest viewer using MSVS2003. Links to that URL should go to whatever the right instructions are for the latest viewer. 3. Fix up any places where there's a link to "Compiling the viewer (MSVS2003)" and it really does mean "give me the old page". If this sounds like a lot of work; well, it is, which is why fewer pages (in the future) is probably better. It's handy to keep the old content around, but it should be increasingly difficult to find, because otherwise novices are going to stumble into it and get frustrated. Rob From dmahalko at gmail.com Fri Jul 25 19:01:30 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri Jul 25 19:01:32 2008 Subject: [sldev] Better build instructions In-Reply-To: References: Message-ID: I see no problem with a new build page for each viewer release. Re-editing the same page over and over for each release means that historical build information may become lost or overwritten as time passes. It takes about 30 seconds to edit the current (old) build page, copy the text, make a new page for the next viewer, paste, and then update this new page to make note of any changes. So the general wiki layout would be: Compiling the viewer - main wiki page [[Compiling Viewer 1.20.10.RC]] [[Compiling Viewer 1.20.9.RC]] [[Compiling Viewer 1.20.8.RC]] [[Compiling Viewer 1.20.7.RC]] [[Compiling Viewer 1.20.6.RC]] [[Compiling Viewer 1.20.5.RC]] [[Compiling Viewer 1.20.4.RC]] [[Compiling Viewer 1.20.3.RC]] [[Compiling Viewer 1.20.2.RC]] [[Compiling Viewer 1.20.1.RC]] The main problem is that many release pages will create a very long unwieldy list of build pages to wade through, rather than the current very long unwieldy single build page for all versions. Look far to the future and you'll have an incredibly large build versions page, uh, sort of like the current source download page, except bigger yet. Perhaps you'd want to establish a method for archiving/indexing old viewers, by major build version? This allows going back all the way to the beginning with just 20 archive pages: Compiling the viewer - main wiki page == Current Releases == [[Compiling Viewer 1.21.3]] [[Compiling Viewer 1.21.2]] [[Compiling Viewer 1.21.1]] == Older Viewers == [[Viewer Release 1.20 Index]] [[Viewer Release 1.19 Index]] [[Viewer Release 1.18 Index]] [[Viewer Release 1.17 Index]] [[Viewer Release 1.16 Index]] [[Viewer Release 1.15 Index]] For future complexity, it is helpful to note that this will probably some day be complemented by: Compiling the Simulator -- main wiki page == Current Releases == [[Compiling Simulator 1.43.2]] [[Compiling Simulator 1.43.1.2]] == Older Simulators == [[Simulator Release 1.42 Index]] [[Simulator Release 1.41 Index]] [[Simulator Release 1.40 Index]] [[Simulator Release 1.39 Index]] [[Simulator Release 1.38 Index]] [[Simulator Release 1.37 Index]] - Scalar Tardis / Dale Mahalko On Fri, Jul 25, 2008 at 12:56 PM, Soft wrote: > 1) Avoid having separate pages for every platform and compiler > combination. > 2) Stop reusing the same wiki page for every viewer version. Build > steps will continue to change in the future. From kf6kjg at gmail.com Fri Jul 25 19:31:33 2008 From: kf6kjg at gmail.com (Ricky) Date: Fri Jul 25 19:31:38 2008 Subject: Criterion for forking build instructions for new source versions(was: [sldev] Better build instructions) In-Reply-To: <488A71FF.1010409@lindenlab.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> <488A3B77.1060401@watson.ibm.com> <3bb9647e0807251408m11012a64g532289d44af01cd2@mail.gmail.com> <488A4C9C.4030101@boroon.dasgupta.ch> <488A71FF.1010409@lindenlab.com> Message-ID: <3bb9647e0807251931sc12fe30l55885d379c3edb76@mail.gmail.com> Hehe, that was one of the points in one my earlier posts today. :D Links, whether internal to the Wiki, or from external websites are an important feature to keep track of. But what edition should be top? This is still under debate! :D The options looks like either the current released edition, the current RC, or the SVN trunk build instructions... Ricky On Fri, Jul 25, 2008 at 5:38 PM, Rob Lanphier wrote: > On 07/25/2008 02:58 PM, Boroondas Gupte wrote: > >> Ricky schrieb: >> >>> the neext question is how do we know when to just tweak the existing >>> article, and when to split a new article? Do we only ever split? >>> >> Coming up with a criterion is easy. The difficult part will be to apply >> it: >> >> My suggestion: Whenever it is possible to change the description so it'll >> *keep working for the versions it used to apply to*, as well as to one (or >> more) additional version(s), just modify the article (as long as things stay >> practical and readable, that is). If that can't be done in a reasonable way, >> fork the article. >> >> To determine when that's the case -- well, the wiki articles do have >> discussion pages. >> > > Another important consideration: consider inbound links, and keep the > *links* up-to-date. We need to consider that people will be deep linking to > this wiki from unexpected places, and search engine results may not always > be optimal. For example, the page "Compiling the viewer (MSVS2003)" > currently has no disclaimer in the title that it only applies to 1.20 and > older. When 1.21 is released (and maybe earlier), the ideal solution would > be to fix that, and for the following: > 1. Rename "Compiling the viewer (MSVS2003)" to "Compiling the viewer > (MSVS2003 - 1.20 and earlier)" with a new disclaimer added to the top > 2. A redirect from "Compiling the viewer (MSVS2003)" be placed to whatever > article tells you how to compile the viewer using CMake, since someone who > tries to visit that page title probably wants to build the latest viewer > using MSVS2003. Links to that URL should go to whatever the right > instructions are for the latest viewer. > 3. Fix up any places where there's a link to "Compiling the viewer > (MSVS2003)" and it really does mean "give me the old page". > > If this sounds like a lot of work; well, it is, which is why fewer pages > (in the future) is probably better. It's handy to keep the old content > around, but it should be increasingly difficult to find, because otherwise > novices are going to stumble into it and get frustrated. > > Rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080725/0d8ba6d3/attachment.htm From lenglish5 at cox.net Fri Jul 25 20:24:28 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Jul 25 20:24:31 2008 Subject: Criterion for forking build instructions for new source versions(was: [sldev] Better build instructions) In-Reply-To: <488A71FF.1010409@lindenlab.com> References: <3bb9647e0807251102m2a72ab9ap3c6367f012c99477@mail.gmail.com> <488A1C0B.4060909@gmail.com> <3bb9647e0807251306p52adfdb3ldfc263245790b0f5@mail.gmail.com> <488A3B77.1060401@watson.ibm.com><3bb9647e0807251408m11012a64g532289d44af01cd2@mail.gmail.com> <488A4C9C.4030101@boroon.dasgupta.ch> <488A71FF.1010409@lindenlab.com> Message-ID: <488A98EC.6050002@cox.net> Rob Lanphier wrote: > On 07/25/2008 02:58 PM, Boroondas Gupte wrote: >> Ricky schrieb: >>> the neext question is how do we know when to just tweak the existing >>> article, and when to split a new article? Do we only ever split? >> Coming up with a criterion is easy. The difficult part will be to >> apply it: >> >> My suggestion: Whenever it is possible to change the description so >> it'll *keep working for the versions it used to apply to*, as well as >> to one (or more) additional version(s), just modify the article (as >> long as things stay practical and readable, that is). If that can't >> be done in a reasonable way, fork the article. >> >> To determine when that's the case -- well, the wiki articles do have >> discussion pages. > > Another important consideration: consider inbound links, and keep the > *links* up-to-date. We need to consider that people will be deep > linking to this wiki from unexpected places, and search engine results > may not always be optimal. For example, the page "Compiling the > viewer (MSVS2003)" currently has no disclaimer in the title that it > only applies to 1.20 and older. When 1.21 is released (and maybe > earlier), the ideal solution would be to fix that, and for the following: > 1. Rename "Compiling the viewer (MSVS2003)" to "Compiling the viewer > (MSVS2003 - 1.20 and earlier)" with a new disclaimer added to the top > 2. A redirect from "Compiling the viewer (MSVS2003)" be placed to > whatever article tells you how to compile the viewer using CMake, > since someone who tries to visit that page title probably wants to > build the latest viewer using MSVS2003. Links to that URL should go > to whatever the right instructions are for the latest viewer. > 3. Fix up any places where there's a link to "Compiling the viewer > (MSVS2003)" and it really does mean "give me the old page". > > If this sounds like a lot of work; well, it is, which is why fewer > pages (in the future) is probably better. It's handy to keep the old > content around, but it should be increasingly difficult to find, > because otherwise novices are going to stumble into it and get > frustrated. Now that I understand better how Categories work on the wiki, I've been using them a lot (too much?). Perhaps two categories could be setup and all current pages go into the *_current category and when they are no longer useful they get put in the *_archives category instead. If something appears with a direct link, it should be marked with *_current. That way people can know what is current and what is archived by just checking the relevant category, which can always be linked from the main * page anyway. Lawson From bill.hoffman at kitware.com Fri Jul 25 20:27:37 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Jul 25 20:28:29 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> Message-ID: <488A99A9.7010802@kitware.com> Soft wrote: > On Thu, Jul 24, 2008 at 8:57 PM, Bill Hoffman wrote: >> Suzhanna Rossini wrote: >> >> I am trying to release cmake 2.6.1 and would like to make it work with >> Secondlife if possible. The only remaining issue is the undefined symbol >> above. Can someone tell me exactly which version of the SecondLife viewer I >> would need to build to reproduce this issue? > > I love that you're doing this. > I love that you love that I am doing this. :) > It looks as though she's working off the release branch. There have > been no notable cmake changes of recent, so pulling from head should > be sufficient. > Suzhanna sent me a few binary files that I requested from her, and I checked release out of svn. I found the issue, and have put a fix into CMake CVS and on the 2.6 branch. I should have the next CMake 2.6.1 release candidate with the fix ready by Monday so you folks can try it out. The Second Life CMake files are still broken for makefiles on the Mac and Windows for any version of CMake. Full paths to libraries need to include the extensions of the libraries. However, after this next patch the same stuff should work with 2.4.8 as works with 2.6.1. -Bill From secret.argent at gmail.com Sat Jul 26 05:57:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 26 05:57:44 2008 Subject: [sldev] Better build instructions In-Reply-To: References: Message-ID: <4FED08DE-A4A9-49BD-9367-0D8A1B5F847D@gmail.com> I approve both your suggestions, Soft! From secret.argent at gmail.com Sat Jul 26 06:50:10 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 26 06:49:55 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> Message-ID: I think you're on a better path with shadowing. Getting shadowing right is better than trying to fake it with 'ambient occlusion' hacks. They lead to unnatural shadows in corners that just scream "computer generated" to me. That pile of box is showing a bunch of examples of that. If you count two blocks across from the bottom, there's three blocks on the ground leading away from the camera with a fourth block on top of the third block. The lower left corner of the front face of that block is visibly darker than the rest of the block. In real life that face would be almost uniformly illuminated. From bill.hoffman at kitware.com Sat Jul 26 08:43:04 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Sat Jul 26 08:43:56 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488A99A9.7010802@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> Message-ID: <488B4608.6020801@kitware.com> Bill Hoffman wrote: >> be sufficient. >> > Suzhanna sent me a few binary files that I requested from her, and I > checked release out of svn. I found the issue, and have put a fix into > CMake CVS and on the 2.6 branch. I should have the next CMake 2.6.1 > release candidate with the fix ready by Monday so you folks can try it out. > > The Second Life CMake files are still broken for makefiles on the Mac > and Windows for any version of CMake. Full paths to libraries need to > include the extensions of the libraries. However, after this next patch > the same stuff should work with 2.4.8 as works with 2.6.1. OK, 2.6.1 RC 13 is here: http://www.cmake.org/files/v2.6/ Please give it a try. Should fix the Xcode error, and the visual studio link error. If it builds SecondLife, I will make it the official 2.6.1 release. Thanks. -Bill From qarl at lindenlab.com Sat Jul 26 09:17:53 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Sat Jul 26 09:17:55 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> Message-ID: <9C1287DA-7759-48B4-98DA-C934192BE095@lindenlab.com> always SO much negativity on this list! the ssoa work is being done by a student as a part of the google summer of code program. he's not "stealing" resources from anything else. trust me - when done correctly - ambient occlusion increases realism. the technique was invented/discovered in the film "pearl harbor" and has been used in EVERYTHING since. because it looks good. K. On Jul 26, 2008, at 6:50 AM, Argent Stonecutter wrote: > I think you're on a better path with shadowing. Getting shadowing > right is better than trying to fake it with 'ambient occlusion' > hacks. They lead to unnatural shadows in corners that just scream > "computer generated" to me. That pile of box is showing a bunch of > examples of that. If you count two blocks across from the bottom, > there's three blocks on the ground leading away from the camera with > a fourth block on top of the third block. The lower left corner of > the front face of that block is visibly darker than the rest of the > block. In real life that face would be almost uniformly illuminated. From carjay at gmx.net Sat Jul 26 12:00:32 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Jul 26 12:00:45 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488A99A9.7010802@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> Message-ID: <488B7450.80307@gmx.net> Bill Hoffman wrote: > Suzhanna sent me a few binary files that I requested from her, and I > checked release out of svn. I found the issue, and have put a fix > into CMake CVS and on the 2.6 branch. I should have the next CMake > 2.6.1 release candidate with the fix ready by Monday so you folks can > try it out. Hi, On the same note (but probably more a problem of the SL cmake files): I'm currently running into problems with both release cmake 2.6.0 and 2.6.1 patch 13 (from CVS CMake-2-6 branch) on a Linux x86_64 system (Kubuntu Gutsy). Since it is 64 bit, this is a standalone build. The issues I experience are due to dependencies of the library targets not being communicated to CMake so they only get added for the application but not for the target libraries against which the application is also linked. For example llcommon.a is dependent on the system provided APR-library but this is not stated in its subdirectory. It seems that 2.6.0 changed the way libraries are listed on the command line (probably related to the same policy change that was described on the list before?). This has the effect that during the final link e.g. ../llcommon/libllcommon.a appears on the command line only after -laprutil-1 -lapr-1 have already been stated (since they are only listed in the CMakeLists.txt for the application itself). Attached patch fixes this for me. Can anyone confirm that this is the correct approach for all relevant platforms? Carsten -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake_link_patch.diff Type: text/x-patch Size: 1479 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080726/f2517614/cmake_link_patch.bin From seg at haxxed.com Sat Jul 26 12:04:11 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jul 26 12:02:30 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> Message-ID: <1217099051.6667.2.camel@localhost> On Sat, 2008-07-26 at 08:50 -0500, Argent Stonecutter wrote: > I think you're on a better path with shadowing. Getting shadowing > right is better than trying to fake it with 'ambient occlusion' > hacks. They lead to unnatural shadows in corners that just scream > "computer generated" to me. Are you trying to tell me Second Life isn't real? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080726/a09b82b7/attachment.pgp From carjay at gmx.net Sat Jul 26 12:08:18 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Jul 26 12:08:22 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488B7450.80307@gmx.net> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B7450.80307@gmx.net> Message-ID: <488B7622.7070501@gmx.net> > Bill Hoffman wrote: >> Suzhanna sent me a few binary files that I requested from her, and I >> checked release out of svn. I found the issue, and have put a fix >> into CMake CVS and on the 2.6 branch. I should have the next CMake >> 2.6.1 release candidate with the fix ready by Monday so you folks can >> try it out. Oh, right, sorry, I failed to mention that CMake 2.6.1 Patch-13 fixed the undefined symbol to lscript_compile for me (seems this also happened on Linux systems). Carsten From aysz88 at gmail.com Sat Jul 26 12:10:50 2008 From: aysz88 at gmail.com (AySz88/Soup) Date: Sat Jul 26 12:10:53 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> Message-ID: SSAO is being done in the shadow branch; I don't think they'll be split from each other. And with shadows, interior areas will end up with everything in shadow (unless there are local lights), so you need something to enhance contrast and depth a bit, which AO does. While the screen-space part is a bit of a hack, AO itself is a real-world phenomenon unrelated to sun shadows, not "faking shadowing" at all. If you have a cluttered desk, shutter the windows and look at crevices and creases. :) I'm not sure of exactly what you're seeing. But it might be due to the fact that the data sampling area has to be capped (for performance reasons - sampling too far away on the screen misses the cache). Letting it sample arbitrarily far away creates a better result, but the cost of it balloons from 2-ish ms/frame to 12-ish. ~Cel On Sat, Jul 26, 2008 at 9:50 AM, Argent Stonecutter wrote: > I think you're on a better path with shadowing. Getting shadowing right is > better than trying to fake it with 'ambient occlusion' hacks. They lead to > unnatural shadows in corners that just scream "computer generated" to me. > That pile of box is showing a bunch of examples of that. If you count two > blocks across from the bottom, there's three blocks on the ground leading > away from the camera with a fourth block on top of the third block. The > lower left corner of the front face of that block is visibly darker than the > rest of the block. In real life that face would be almost uniformly > illuminated. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From bill.hoffman at kitware.com Sat Jul 26 12:23:17 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Sat Jul 26 12:24:08 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488B7450.80307@gmx.net> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B7450.80307@gmx.net> Message-ID: <488B79A5.2000406@kitware.com> Carsten Juttner wrote: > On the same note (but probably more a problem of the SL cmake files): > > I'm currently running into problems with both release cmake 2.6.0 and > 2.6.1 patch 13 (from CVS CMake-2-6 branch) on a Linux x86_64 system > (Kubuntu Gutsy). Since it is 64 bit, this is a standalone build. > > The issues I experience are due to dependencies of the library targets > not being communicated to CMake so they only get added for the > application but not for the target libraries against which the > application is also linked. > > For example llcommon.a is dependent on the system provided APR-library > but this is not stated in its subdirectory. It seems that 2.6.0 changed > the way libraries are listed on the command line (probably related to > the same policy change that was described on the list before?). > > This has the effect that during the final link e.g. > ../llcommon/libllcommon.a appears on the command line only after > -laprutil-1 -lapr-1 have already been stated (since they are only listed > in the CMakeLists.txt for the application itself). > So, this worked with 2.4.8? Can you send me the link line from a 2.4.8 build and a 2.6.1 RC 13 build? Use make VERBOSE=1 to see the full link line used. Thanks. -Bill From carjay at gmx.net Sat Jul 26 13:09:36 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Jul 26 13:09:41 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488B79A5.2000406@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B7450.80307@gmx.net> <488B79A5.2000406@kitware.com> Message-ID: <488B8480.1080204@gmx.net> Bill Hoffman wrote: > So, this worked with 2.4.8? Can you send me the link line from a > 2.4.8 build and a 2.6.1 RC 13 build? Use make VERBOSE=1 to see the > full link line used. Sure, actually when I wrote the mail I only assumed it would work with 2.4.8 (until now, I used a different - still scons based - branch of the SL viewer so my first experience with CMake and SL was only a few days ago with cmake 2.6.0 which I've been using for some time now due to my preference for Code::Blocks whose generator was not yet part of 2.4.8) But I have now built cmake 2.4.8 and verified that SL builds on my system with that version while it fails for 2.6.1-p13. Due to the time it takes to make the full build I'm only adding the link line for the Linux Crash Logger but the effect is the same (it links against both llcommon.a and llmessage.a). I also included the error lines but they should be obvious (unresolved symbols). I have attached all 3 versions, first 2.4.8, then 2.6.1-p13 without the patch from my previous mail and finally 2.6.1-p13 with that patch for the CMakeLists. As you can see, 2.4.8 used -llcommon while 2.6.1-p13 uses ../llcommon/libllcommon.a Regards, Carsten -------------- next part -------------- cd /home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/linux_crash_logger && /usr/bin/g++ -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -fno-inline -D_DEBUG -DLL_DEBUG=1 -fPIC -Wl,--as-needed "CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o" "CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o" -o linux-crash-logger -rdynamic -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llcrashlogger -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llvfs -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llxml -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llmessage -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llmath -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llcommon -L/usr/local/lib -Wl,-Bstatic -lllcrashlogger -lllvfs -lllxml -Wl,-Bdynamic -lexpat -Wl,-Bstatic -lllmessage -Wl,-Bdynamic -lcurl -Wl,-Bstatic -lcares -Wl,-Bdynamic -lssl -lcrypto -lxmlrpc-epi -Wl,-Bstatic -lllvfs -lllmath -lllcommon -Wl,-Bdynamic -laprutil-1 -lapr-1 -lexpat -lz -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lX11 -lXfixes -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lglib-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lX11 -lXfixes -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lpng12 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangoxft-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lSDL -lboost_signals-mt -ldb -------------- next part -------------- /usr/bin/g++ -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -fno-inline -D_DEBUG -DLL_DEBUG=1 -fPIC -Wl,--as-needed CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o -o linux-crash-logger -rdynamic -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llcrashlogger -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llvfs -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llxml -L/usr/local/lib -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llmessage -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llmath -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llcommon ../llcrashlogger/libllcrashlogger.a ../llvfs/libllvfs.a ../llxml/libllxml.a -lexpat -lcurl /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so -laprutil-1 -lapr-1 -lexpat -lcurl /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so -laprutil-1 -lapr-1 ../llmessage/libllmessage.a ../llmath/libllmath.a ../llcommon/libllcommon.a -lz -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lX11 -lXfixes -lgtk-x11-2.0 -lgthread-2.0 -lrt -lpng12 -lpangoft2-1.0 -lpangox-1.0 -lpangoxft-1.0 -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lX11 -lXfixes -lgtk-x11-2.0 -lgthread-2.0 -lrt -lpng12 -lpangoft2-1.0 -lpangox-1.0 -lpangoxft-1.0 -lSDL -lboost_signals-mt -ldb /usr/local/lib/libcares.a -lcrypto ../llvfs/libllvfs.a ../llmath/libllmath.a ../llcommon/libllcommon.a -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lX11 -lXfixes -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lglib-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lX11 -lXfixes -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lpng12 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangoxft-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lSDL -lboost_signals-mt ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::cleanupClass()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:1007: undefined reference to `curl_global_cleanup' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::initClass()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:988: undefined reference to `curl_global_init' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::strerror(CURLcode)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:656: undefined reference to `curl_easy_strerror' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Multi::addEasy(LLCurl::Easy*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:616: undefined reference to `curl_multi_add_handle' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:619: undefined reference to `curl_multi_strerror' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Multi::perform()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:546: undefined reference to `curl_multi_perform' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Multi::info_read(int*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:534: undefined reference to `curl_multi_info_read' ../llmessage/libllmessage.a(llcurl.o): In function `Multi': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:501: undefined reference to `curl_multi_init' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:505: undefined reference to `curl_multi_init' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:501: undefined reference to `curl_multi_init' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:505: undefined reference to `curl_multi_init' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::slist_append(char const*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:385: undefined reference to `curl_slist_append' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::setoptString(CURLoption, std::basic_string, std::allocator > const&)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:380: undefined reference to `curl_easy_setopt' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::setopt(CURLoption, char*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:371: undefined reference to `curl_easy_setopt' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::setopt(CURLoption, void*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:366: undefined reference to `curl_easy_setopt' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::setopt(CURLoption, int)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:361: undefined reference to `curl_easy_setopt' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::getTransferInfo(LLCurl::TransferInfo*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:327: undefined reference to `curl_easy_getinfo' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:328: undefined reference to `curl_easy_getinfo' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:329: undefined reference to `curl_easy_getinfo' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::resetState()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:276: undefined reference to `curl_easy_reset' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:280: undefined reference to `curl_slist_free_all' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::report(CURLcode)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:339: undefined reference to `curl_easy_getinfo' ../llmessage/libllmessage.a(llcurl.o): In function `~Easy': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:268: undefined reference to `curl_easy_cleanup' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:270: undefined reference to `curl_slist_free_all' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Multi::removeEasy(LLCurl::Easy*)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:642: undefined reference to `curl_multi_remove_handle' ../llmessage/libllmessage.a(llcurl.o): In function `~Multi': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:518: undefined reference to `curl_multi_remove_handle' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:528: undefined reference to `curl_multi_cleanup' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:518: undefined reference to `curl_multi_remove_handle' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:528: undefined reference to `curl_multi_cleanup' ../llmessage/libllmessage.a(llcurl.o): In function `~Easy': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:268: undefined reference to `curl_easy_cleanup' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:270: undefined reference to `curl_slist_free_all' ../llmessage/libllmessage.a(llcurl.o): In function `LLCurl::Easy::getEasy()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llcurl.cpp:254: undefined reference to `curl_easy_init' ../llmessage/libllmessage.a(llhttpclient.o): In function `LLHTTPClient::blockingGet(std::basic_string, std::allocator > const&)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:351: undefined reference to `curl_easy_init' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:360: undefined reference to `curl_easy_setopt' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:361: undefined reference to `curl_easy_setopt' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:363: undefined reference to `curl_easy_setopt' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:364: undefined reference to `curl_easy_setopt' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:365: undefined reference to `curl_easy_setopt' ../llmessage/libllmessage.a(llhttpclient.o):/home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:366: more undefined references to `curl_easy_setopt' follow ../llmessage/libllmessage.a(llhttpclient.o): In function `LLHTTPClient::blockingGet(std::basic_string, std::allocator > const&)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:371: undefined reference to `curl_easy_perform' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:374: undefined reference to `curl_easy_getinfo' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llhttpclient.cpp:390: undefined reference to `curl_easy_cleanup' ../llmessage/libllmessage.a(llpumpio.o): In function `LLPumpIO::cleanup()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:836: undefined reference to `apr_pollset_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:841: undefined reference to `apr_pool_destroy' ../llmessage/libllmessage.a(llpumpio.o): In function `LLPumpIO::rebuildPollset()': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:854: undefined reference to `apr_pollset_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:872: undefined reference to `apr_pool_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:878: undefined reference to `apr_pool_create_ex' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:886: undefined reference to `apr_pollset_create' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:893: undefined reference to `apr_pollset_add' ../llmessage/libllmessage.a(llpumpio.o): In function `LLPumpIO::pump(int const&)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llpumpio.cpp:517: undefined reference to `apr_pollset_poll' ../llmessage/libllmessage.a(llurlrequest.o): In function `LLURLRequest::useProxy(bool)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llurlrequest.cpp:168: undefined reference to `apr_pool_create_ex' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llurlrequest.cpp:169: undefined reference to `apr_env_get' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llurlrequest.cpp:172: undefined reference to `apr_env_get' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/llurlrequest.cpp:178: undefined reference to `apr_pool_destroy' ../llmessage/libllmessage.a(message.o): In function `LLMessageSystem::poll(float)': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/message.cpp:448: undefined reference to `apr_poll' ../llmessage/libllmessage.a(message.o): In function `LLMessageSystem': /home/carjay/sources/SL/linden_svn/release/indra/llmessage/message.cpp:341: undefined reference to `apr_os_sock_put' /home/carjay/sources/SL/linden_svn/release/indra/llmessage/message.cpp:341: undefined reference to `apr_os_sock_put' ../llcommon/libllcommon.a(llapp.o): In function `default_unix_signal_handler(int, siginfo*, void*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapp.cpp:602: undefined reference to `apr_signal_description_get' ../llcommon/libllcommon.a(llapp.o): In function `LLAtomic32::operator++(int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:114: undefined reference to `apr_atomic_inc32' ../llcommon/libllcommon.a(llapp.o): In function `LLAtomic32::operator unsigned int const()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:110: undefined reference to `apr_atomic_read32' ../llcommon/libllcommon.a(llapp.o): In function `LLAtomic32': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:107: undefined reference to `apr_atomic_set32' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_size(std::basic_string, std::allocator > const&, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:341: undefined reference to `apr_file_open' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:348: undefined reference to `apr_file_info_get' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:349: undefined reference to `apr_file_close' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_exists(std::basic_string, std::allocator > const&, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:323: undefined reference to `apr_file_open' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:330: undefined reference to `apr_file_close' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_seek(apr_file_t*, int, int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:272: undefined reference to `apr_file_seek' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:277: undefined reference to `apr_file_seek' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_open(std::basic_string, std::allocator > const&, int, int*, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:137: undefined reference to `apr_file_open' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:151: undefined reference to `apr_file_seek' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:156: undefined reference to `apr_file_seek' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_write(apr_file_t*, void const*, int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:221: undefined reference to `apr_file_write' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_write_ex(std::basic_string, std::allocator > const&, apr_pool_t*, void*, int, int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:260: undefined reference to `apr_file_close' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_read(apr_file_t*, void*, int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:179: undefined reference to `apr_file_read' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_read_ex(std::basic_string, std::allocator > const&, apr_pool_t*, void*, int, int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:213: undefined reference to `apr_file_close' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_warn_status(int)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:121: undefined reference to `apr_strerror' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_dir_remove(std::basic_string, std::allocator > const&, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:379: undefined reference to `apr_file_remove' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_dir_make(std::basic_string, std::allocator > const&, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:365: undefined reference to `apr_dir_make' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_rename(std::basic_string, std::allocator > const&, std::basic_string, std::allocator > const&, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:308: undefined reference to `apr_file_rename' ../llcommon/libllcommon.a(llapr.o): In function `ll_apr_file_remove(std::basic_string, std::allocator > const&, apr_pool_t*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:294: undefined reference to `apr_file_remove' ../llcommon/libllcommon.a(llapr.o): In function `LLScopedLock::unlock()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:106: undefined reference to `apr_thread_mutex_unlock' ../llcommon/libllcommon.a(llapr.o): In function `LLScopedLock': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:82: undefined reference to `apr_thread_mutex_lock' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:82: undefined reference to `apr_thread_mutex_lock' ../llcommon/libllcommon.a(llapr.o): In function `ll_cleanup_apr()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:64: undefined reference to `apr_thread_mutex_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:69: undefined reference to `apr_pool_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:72: undefined reference to `apr_terminate' ../llcommon/libllcommon.a(llapr.o): In function `ll_init_apr()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:46: undefined reference to `apr_initialize' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:47: undefined reference to `apr_pool_create_ex' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.cpp:50: undefined reference to `apr_thread_mutex_create' ../llcommon/libllcommon.a(llerror.o): In function `~LogLock': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llerror.cpp:931: undefined reference to `apr_thread_mutex_unlock' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llerror.cpp:931: undefined reference to `apr_thread_mutex_unlock' ../llcommon/libllcommon.a(llerror.o): In function `LogLock': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llerror.cpp:908: undefined reference to `apr_thread_mutex_trylock' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llerror.cpp:908: undefined reference to `apr_thread_mutex_trylock' ../llcommon/libllcommon.a(llsdserialize.o): In function `LLSDNotationParser::parseBinary(std::basic_istream >&, LLSD&) const': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llsdserialize.cpp:805: undefined reference to `apr_base64_decode_len' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llsdserialize.cpp:810: undefined reference to `apr_base64_decode_binary' ../llcommon/libllcommon.a(llsdserialize_xml.o): In function `LLSDXMLParser::Impl::endElementHandler(char const*)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llsdserialize_xml.cpp:724: undefined reference to `apr_base64_decode_len' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llsdserialize_xml.cpp:727: undefined reference to `apr_base64_decode_binary' ../llcommon/libllcommon.a(llsdserialize_xml.o): In function `LLSDXMLFormatter::format_impl(LLSD const&, std::basic_ostream >&, unsigned int, unsigned int) const': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llsdserialize_xml.cpp:203: undefined reference to `apr_base64_encode_len' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llsdserialize_xml.cpp:208: undefined reference to `apr_base64_encode_binary' ../llcommon/libllcommon.a(llthread.o): In function `LLCondition::broadcast()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:351: undefined reference to `apr_thread_cond_broadcast' ../llcommon/libllcommon.a(llthread.o): In function `LLCondition::signal()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:346: undefined reference to `apr_thread_cond_signal' ../llcommon/libllcommon.a(llthread.o): In function `LLCondition::wait()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:341: undefined reference to `apr_thread_cond_wait' ../llcommon/libllcommon.a(llthread.o): In function `LLMutex::isLocked()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:309: undefined reference to `apr_thread_mutex_trylock' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:316: undefined reference to `apr_thread_mutex_unlock' ../llcommon/libllcommon.a(llthread.o): In function `LLMutex::unlock()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:304: undefined reference to `apr_thread_mutex_unlock' ../llcommon/libllcommon.a(llthread.o): In function `LLMutex::lock()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:299: undefined reference to `apr_thread_mutex_lock' ../llcommon/libllcommon.a(llthread.o): In function `~LLMutex': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:288: undefined reference to `apr_thread_mutex_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:292: undefined reference to `apr_pool_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:288: undefined reference to `apr_thread_mutex_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:292: undefined reference to `apr_pool_destroy' ../llcommon/libllcommon.a(llthread.o): In function `~LLCondition': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:334: undefined reference to `apr_thread_cond_destroy' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:334: undefined reference to `apr_thread_cond_destroy' ../llcommon/libllcommon.a(llthread.o): In function `LLMutex': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:277: undefined reference to `apr_pool_create_ex' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:279: undefined reference to `apr_thread_mutex_create' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:277: undefined reference to `apr_pool_create_ex' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:279: undefined reference to `apr_thread_mutex_create' ../llcommon/libllcommon.a(llthread.o): In function `LLCondition': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:328: undefined reference to `apr_thread_cond_create' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:328: undefined reference to `apr_thread_cond_create' ../llcommon/libllcommon.a(llthread.o): In function `LLThread::currentID()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:233: undefined reference to `apr_os_thread_current' ../llcommon/libllcommon.a(llthread.o): In function `LLThread::start()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:163: undefined reference to `apr_thread_create' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:166: undefined reference to `apr_thread_detach' ../llcommon/libllcommon.a(llthread.o): In function `LLThread::shutdown()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:156: undefined reference to `apr_pool_destroy' ../llcommon/libllcommon.a(llthread.o): In function `LLThread': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:101: undefined reference to `apr_pool_create_ex' /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llthread.cpp:101: undefined reference to `apr_pool_create_ex' ../llcommon/libllcommon.a(lldate.o): In function `LLDate::fromStream(std::basic_istream >&)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/lldate.cpp:205: undefined reference to `apr_time_exp_gmt_get' ../llcommon/libllcommon.a(lldate.o): In function `LLDate::toStream(std::basic_ostream >&) const': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/lldate.cpp:133: undefined reference to `apr_time_exp_gmt' ../llcommon/libllcommon.a(lldate.o): In function `LLDate::toHTTPDateStream(std::basic_ostream >&) const': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/lldate.cpp:99: undefined reference to `apr_time_exp_gmt' ../llvfs/libllvfs.a(llvfile.o): In function `LLAtomic32::operator LLQueuedThread::status_t const()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:110: undefined reference to `apr_atomic_read32' ../llvfs/libllvfs.a(llvfs.o): In function `LLVFS::dumpFiles()': /home/carjay/sources/SL/linden_svn/release/indra/llvfs/llvfs.cpp:2074: undefined reference to `apr_file_close' ../llcommon/libllcommon.a(llqueuedthread.o): In function `LLAtomic32::operator int const()': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:110: undefined reference to `apr_atomic_read32' ../llcommon/libllcommon.a(llqueuedthread.o): In function `LLAtomic32::operator=(LLQueuedThread::status_t const&)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:111: undefined reference to `apr_atomic_set32' ../llcommon/libllcommon.a(llqueuedthread.o): In function `LLAtomic32': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:107: undefined reference to `apr_atomic_set32' ../llcommon/libllcommon.a(llqueuedthread.o): In function `LLAtomic32::operator=(int const&)': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:111: undefined reference to `apr_atomic_set32' ../llcommon/libllcommon.a(llqueuedthread.o): In function `LLAtomic32': /home/carjay/sources/SL/linden_svn/release/indra/llcommon/llapr.h:107: undefined reference to `apr_atomic_set32' collect2: ld returned 1 exit status make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 make[2]: Leaving directory `/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64' make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] Error 2 make[1]: Leaving directory `/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64' make: *** [all] Error 2 -------------- next part -------------- /usr/bin/g++ -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -fno-inline -D_DEBUG -DLL_DEBUG=1 -fPIC -Wl,--as-needed CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o -o linux-crash-logger -rdynamic -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llcrashlogger -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llvfs -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llxml -L/usr/local/lib -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llmessage -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llmath -L/home/carjay/sources/SL/linden_svn/release/indra/viewer-linux-x86_64/llcommon ../llcrashlogger/libllcrashlogger.a ../llvfs/libllvfs.a ../llxml/libllxml.a -lexpat /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so -lexpat /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so ../llmessage/libllmessage.a -lcurl ../llmath/libllmath.a ../llcommon/libllcommon.a -laprutil-1 -lapr-1 -lz -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lX11 -lXfixes -lgtk-x11-2.0 -lgthread-2.0 -lrt -lpng12 -lpangoft2-1.0 -lpangox-1.0 -lpangoxft-1.0 -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lX11 -lXfixes -lgtk-x11-2.0 -lgthread-2.0 -lrt -lpng12 -lpangoft2-1.0 -lpangox-1.0 -lpangoxft-1.0 -lSDL -lboost_signals-mt -ldb /usr/local/lib/libcares.a -lcrypto ../llvfs/libllvfs.a ../llmath/libllmath.a ../llcommon/libllcommon.a -latk-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lcairo -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lX11 -lXfixes -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lglib-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lfontconfig -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lpango-1.0 -lcairo -lX11 -lXfixes -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lpng12 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpangoxft-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lSDL -lboost_signals-mt From secret.argent at gmail.com Sat Jul 26 13:59:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 26 13:59:15 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> Message-ID: <4D595A46-5B6D-4403-B098-6119E97138BB@gmail.com> > While > the screen-space part is a bit of a hack, AO itself is a real-world > phenomenon unrelated to sun shadows, I'm not talking about just "sun shadows" here. > not "faking shadowing" at all. "Ambient Occlusion" is not a real world phenomenon. It is an approximation to the effect of shadowing in the presence of diffuse light. The result is that if you use AO to render a scene, you get dark shadows in corners, for example where walls meet the floor, in places where there's no shadowing in RL. It's got nothing to do with the quality of the implementation, it's purely a function of the fact that the adjacent wall or corner is seen as occluding the ambient light by the AO algorithm. I suppose you could apply second or third degree calculations and only treat surfaces that aren't fully illuminated in the absence of AO as being potential sources of shadows. Now I'm not saying that it's not a useful hack, I'm mostly objecting to the idea that it's some kind of gold standard for rendering. I'm mostly taking issue with Qarl's comment that "screen space ambient occlusion is the je-ne-sais-quoi of rendering realism". It's not, it's a clever approximation, but it's a long way from optical realism. From Celierra at gmail.com Sat Jul 26 16:00:52 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sat Jul 26 16:00:56 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: <4D595A46-5B6D-4403-B098-6119E97138BB@gmail.com> References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> <4D595A46-5B6D-4403-B098-6119E97138BB@gmail.com> Message-ID: On Sat, Jul 26, 2008 at 4:59 PM, Argent Stonecutter wrote: >> While >> the screen-space part is a bit of a hack, AO itself is a real-world >> phenomenon unrelated to sun shadows, > > I'm not talking about just "sun shadows" here. > >> not "faking shadowing" at all. > > > "Ambient Occlusion" is not a real world phenomenon. It is an approximation > to the effect of shadowing in the presence of diffuse light. I think the whole real world vs. approximation thing is just a difference in our terminologies. (offtopic: I tend to consider a first-order approximations "real", in the sense that Newton's gravity is imprecise but "real", but that's a topic of some debate.) > The result is that if you use AO to render a scene, you get dark shadows in > corners, for example where walls meet the floor, in places where there's no > shadowing in RL. It's got nothing to do with the quality of the > implementation, it's purely a function of the fact that the adjacent wall or > corner is seen as occluding the ambient light by the AO algorithm. I suppose > you could apply second or third degree calculations and only treat surfaces > that aren't fully illuminated in the absence of AO as being potential > sources of shadows. But I'm not sure why you're calling (for example) darkened corners unrealistic - I'm looking around my real-world room and seeing plenty of it, though I think it becomes more subtle when the surfaces aren't plain stark white. There is indeed a lot less ambient light reaching these corners, no? As for ignoring bright occluders, I might take a stab at it, but there might not be enough data in screen space - you see a lot of the "wrong side" of the occluders (and, it sounds rather slow...). ~Cel From asuter at ilm.com Sat Jul 26 17:12:51 2008 From: asuter at ilm.com (Alex Suter) Date: Sat Jul 26 17:12:53 2008 Subject: [sldev] screen space ambient occlusion In-Reply-To: <9C1287DA-7759-48B4-98DA-C934192BE095@lindenlab.com> References: <09A8AD6C-16D3-4794-9B0F-B85683AF631D@lindenlab.com> <9C1287DA-7759-48B4-98DA-C934192BE095@lindenlab.com> Message-ID: <488BBD83.9070803@ilm.com> I have to agree with Qarl and others. Ambient occlusion is great stuff. If you want approximately correct lighting done quickly, it's a perfect trick. Add in some direct shadowing and you're well on your way. Some day computers will be fast enough to do full radiosity/raytracing/ whatever at 60fps, but we're not there yet. Karl Stiefvater wrote: > always SO much negativity on this list! > > the ssoa work is being done by a student as a part of the google summer > of code program. he's not "stealing" resources from anything else. > > trust me - when done correctly - ambient occlusion increases realism. > the technique was invented/discovered in the film "pearl harbor" and has > been used in EVERYTHING since. because it looks good. > > > K. > > On Jul 26, 2008, at 6:50 AM, Argent Stonecutter wrote: > >> I think you're on a better path with shadowing. Getting shadowing >> right is better than trying to fake it with 'ambient occlusion' hacks. >> They lead to unnatural shadows in corners that just scream "computer >> generated" to me. That pile of box is showing a bunch of examples of >> that. If you count two blocks across from the bottom, there's three >> blocks on the ground leading away from the camera with a fourth block >> on top of the third block. The lower left corner of the front face of >> that block is visibly darker than the rest of the block. In real life >> that face would be almost uniformly illuminated. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sammy.frederix at gmail.com Sat Jul 26 18:23:16 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Sat Jul 26 18:23:32 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488B4608.6020801@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> Message-ID: <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> On 27/07/2008, at 1:43 AM, Bill Hoffman wrote: > OK, 2.6.1 RC 13 is here: http://www.cmake.org/files/v2.6/ > > Please give it a try. Should fix the Xcode error, and the visual > studio link error. If it builds SecondLife, I will make it the > official 2.6.1 release. using Xcode 3.1, I get the following build failure for building the (unpatched) release branch: i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/lljpeg: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/cares: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/apr-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/llmozlib2: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/cares: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/apr-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/llmozlib2: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/cares: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/apr-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/llmozlib2: No such file or directory With CMake 2.4.8, I get a different build error, but the build still works CopyPlistFile "/Users/home/SLOrig/release/indra/build-darwin-i386/ newview/Release/Second Life.app/Contents/Resources/Info.plist" Info.plist mkdir "/Users/home/SLOrig/release/indra/build-darwin-i386/newview/ Release/Second Life.app/Contents/Resources" cd /Users/home/SLOrig/release/indra/build-darwin-i386 /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/ Contents/Resources/copyplist Info.plist --outdir "/Users/home/SLOrig/ release/indra/build-darwin-i386/newview/Release/Second Life.app/ Contents/Resources" cp: Info.plist: No such file or directory ** BUILD FAILED ** The following build commands failed: Second Life: CopyPlistFile "/Users/home/SLOrig/release/indra/build-darwin-i386/ newview/Release/Second Life.app/Contents/Resources/Info.plist" Info.plist (1 failure) From sheet.spotter at gmail.com Sat Jul 26 19:56:43 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sat Jul 26 20:03:04 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com><488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> Message-ID: <34B55F5919F242688043989A17E773BB@kenb> VS2005 and VS2008 now build without linker errors. The VS2008 build seems to go into an infinite loop while loading. I think it's an incompatibility between the boost libraries and the VS2008 libraries, not a CMake issue. Sheet Spotter -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Sammy Frederix Sent: July 26, 2008 8:23 PM To: Bill Hoffman Cc: Second Life Developer Mailing List Subject: Re: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares,apr inMac build) On 27/07/2008, at 1:43 AM, Bill Hoffman wrote: > OK, 2.6.1 RC 13 is here: http://www.cmake.org/files/v2.6/ > > Please give it a try. Should fix the Xcode error, and the visual > studio link error. If it builds SecondLife, I will make it the > official 2.6.1 release. using Xcode 3.1, I get the following build failure for building the (unpatched) release branch: i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/lljpeg: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/cares: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/apr-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/llmozlib2: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/cares: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/apr-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/llmozlib2: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/cares: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/aprutil-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/apr-1: No such file or directory i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ libraries/universal-darwin/lib_release/llmozlib2: No such file or directory With CMake 2.4.8, I get a different build error, but the build still works CopyPlistFile "/Users/home/SLOrig/release/indra/build-darwin-i386/ newview/Release/Second Life.app/Contents/Resources/Info.plist" Info.plist mkdir "/Users/home/SLOrig/release/indra/build-darwin-i386/newview/ Release/Second Life.app/Contents/Resources" cd /Users/home/SLOrig/release/indra/build-darwin-i386 /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/ Contents/Resources/copyplist Info.plist --outdir "/Users/home/SLOrig/ release/indra/build-darwin-i386/newview/Release/Second Life.app/ Contents/Resources" cp: Info.plist: No such file or directory ** BUILD FAILED ** The following build commands failed: Second Life: CopyPlistFile "/Users/home/SLOrig/release/indra/build-darwin-i386/ newview/Release/Second Life.app/Contents/Resources/Info.plist" Info.plist (1 failure) _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From suzhanna.rossini at balsaestates.com Sun Jul 27 04:49:24 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sun Jul 27 04:50:06 2008 Subject: SV: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488B4608.6020801@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> Message-ID: <001c01c8efde$d5c5d730$81518590$@rossini@balsaestates.com> > Bill Hoffman wrote: > > >> be sufficient. > >> > > Suzhanna sent me a few binary files that I requested from her, and I > > checked release out of svn. I found the issue, and have put a fix > into > > CMake CVS and on the 2.6 branch. I should have the next CMake 2.6.1 > > release candidate with the fix ready by Monday so you folks can try > it out. > > > > The Second Life CMake files are still broken for makefiles on the Mac > > and Windows for any version of CMake. Full paths to libraries need > to > > include the extensions of the libraries. However, after this next > patch > > the same stuff should work with 2.4.8 as works with 2.6.1. > > OK, 2.6.1 RC 13 is here: http://www.cmake.org/files/v2.6/ > > Please give it a try. Should fix the Xcode error, and the visual > studio > link error. If it builds SecondLife, I will make it the official 2.6.1 > release. > > Thanks. > > -Bill > Verified, builds fine with VS2003 and VS2008, however I still can't get the VS2008 built exe file to run, but that isn't related to cmake.. ;-) /Alexandra. From bill.hoffman at kitware.com Sun Jul 27 08:21:24 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Sun Jul 27 08:22:17 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488B8480.1080204@gmx.net> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B7450.80307@gmx.net> <488B79A5.2000406@kitware.com> <488B8480.1080204@gmx.net> Message-ID: <488C9274.4070009@kitware.com> Carsten Juttner wrote: > I have attached all 3 versions, first 2.4.8, then 2.6.1-p13 without the > patch from my previous mail and finally 2.6.1-p13 with that patch for > the CMakeLists. > > As you can see, 2.4.8 used -llcommon while 2.6.1-p13 uses > ../llcommon/libllcommon.a > That is not the problem. The problem is that the order of the libraries has changed from 2.4.8. 2.4.8 has this: -lexpat -Wl,-Bstatic -lllmessage -Wl,-Bdynamic -lcurl 2.6.1 has this: -lcurl /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so -laprutil-1 -lapr-1 -lexpat -lcurl /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so -laprutil-1 -lapr-1 ../llmessage/libllmessage.a Curl has to come after llmessage.a for a static link to work. So, the patch should most likely make sure that llmessage links to curl. target_link_libraries(llmessage curl) should fix the problem. However, I will have to figure out why this was working for 2.4.8.... :( -Bill From marinekelley at gmail.com Sun Jul 27 08:23:53 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Jul 27 08:24:12 2008 Subject: [sldev] SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp Message-ID: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> Hello all, For hours now I've been hunting a crash that occurs when clicking on a link on the login page. Other crashes in the same flavor are occurring in-world when using the All tab of the Search window (especially when clicking on Page 2 or so, but that's another story I think). Thinking it may come from my own code after patching, I've spent time trying to figure it out, to no avail. Just tried the freshly-compiled-after-downloading-source from the "source downloads" page, and having the same crash. No change made to that code whatsoever. It seems to come from this method : void LLMediaImplLLMozLib::onClickLinkHref( const EventType& eventIn ) { LLMediaEvent event( this, eventIn.getStringValue(), eventIn.getStringValue2() ); mEventEmitter.update( &LLMediaObserver::onClickLinkHref, event ); } where eventIn seems to be uninitialized, leading to a null pointer evaluation. The same action does work perfectly in the binary downloaded from the SL download page. So I wonder where the difference is coming from. Anyone has an idea and/or experienced this too ? Thanks ! Marine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080727/3a1b87a3/attachment.htm From hawk.carter at unix-dev.de Sun Jul 27 08:53:48 2008 From: hawk.carter at unix-dev.de (hawk.carter@unix-dev.de) Date: Sun Jul 27 08:53:51 2008 Subject: [sldev] SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp In-Reply-To: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> References: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> Message-ID: Same problem here + that the Viewer crashes directly on startup, when i leave the llkdu.dll in the Folder.. anyone ? Greetings Hawk > Hello all, > > For hours now I've been hunting a crash that occurs when clicking on a > link > on the login page. Other crashes in the same flavor are occurring in-world > when using the All tab of the Search window (especially when clicking on > Page 2 or so, but that's another story I think). Thinking it may come from > my own code after patching, I've spent time trying to figure it out, to no > avail. > ............. From tao.takashi at googlemail.com Mon Jul 28 02:06:47 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Mon Jul 28 02:06:50 2008 Subject: [sldev] Compile problem on Mac Message-ID: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> Hi there! Today I was trying to compile the interop4-branch of the viewer but I ran into a problem. I followed the instructions on http://wiki.secondlife.com/wiki/CMake but it fails already when doing the develop.py step. What I do: $ svn co ... $ cd indra $ python2.5 develop.py It then says: Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in 'build-darwin-i386' -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PythonInterp: /usr/bin/python2.5 Found matching package: /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 Extracting /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4 Writing state to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/installed.xml and hangs, nothing seems to happen anymore. I tried to debug this as far as I can with no CMake knowledge and the problem seems to be in the FMOD part. With --debug-output I get: -- Found PythonInterp: /usr/bin/python2.5 Called from: [5] /Applications/CMake 2.6-0.app/Contents/share/cmake-2.6/Modules/FindPythonInterp.cmake [4] /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Python.cmake [3] /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Prebuilt.cmake [2] /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Audio.cmake [1] /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/llaudio/CMakeLists.txt And the next line in the CMakeLists.txt seems to be FMOD. When moving this up it also hangs earlier. My OS is Mac OSX 10.5.4 on an Intel Macbook Pro. Any idea what the problem might be? Thanks, Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From soft at lindenlab.com Mon Jul 28 05:55:39 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 05:55:42 2008 Subject: [sldev] Compile problem on Mac In-Reply-To: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> References: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> Message-ID: On Mon, Jul 28, 2008 at 4:06 AM, Christian Scholz / Tao Takashi (SL) wrote: > Hi there! > > Today I was trying to compile the interop4-branch of the viewer but I > ran into a problem. > I followed the instructions on http://wiki.secondlife.com/wiki/CMake > but it fails already when > doing the develop.py step. What I do: > > $ svn co ... > $ cd indra > $ python2.5 develop.py > > It then says: > > Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO > -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" > \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in > 'build-darwin-i386' > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/g++ > -- Check for working CXX compiler: /usr/bin/g++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Found PythonInterp: /usr/bin/python2.5 > Found matching package: > /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 > Extracting /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 > to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4 > Writing state to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/installed.xml > > and hangs, nothing seems to happen anymore. > > I tried to debug this as far as I can with no CMake knowledge and the problem > seems to be in the FMOD part. With --debug-output I get: > > -- Found PythonInterp: /usr/bin/python2.5 > Called from: [5] /Applications/CMake > 2.6-0.app/Contents/share/cmake-2.6/Modules/FindPythonInterp.cmake > [4] > /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Python.cmake > [3] > /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Prebuilt.cmake > [2] > /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Audio.cmake > [1] > /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/llaudio/CMakeLists.txt > > And the next line in the CMakeLists.txt seems to be FMOD. When moving > this up it also hangs earlier. > > My OS is Mac OSX 10.5.4 on an Intel Macbook Pro. > > Any idea what the problem might be? Would you please try with cmake 2.4.8? 2.6.x is not yet supported. From tao.takashi at googlemail.com Mon Jul 28 06:30:25 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Mon Jul 28 06:30:56 2008 Subject: [sldev] Compile problem on Mac In-Reply-To: References: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> Message-ID: <23bbb49e0807280630v67e631c7tc7ebad8245037067@mail.gmail.com> Ok, now that you mention it I also saw that note. Thanks. It does not help though, now the output with --debug-output is: $ python develop.py Running 'cmake --debug-output -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in 'build-darwin-i386' Running with debug output on. -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works I deleted and re-downloaded the source again and I also deleted the CMake-2.6 in /Applications/ Any further ideas maybe? Also maybe on how to get more debugging output? Thanks, Tao On Mon, Jul 28, 2008 at 2:55 PM, Soft wrote: > On Mon, Jul 28, 2008 at 4:06 AM, Christian Scholz / Tao Takashi (SL) > wrote: >> Hi there! >> >> Today I was trying to compile the interop4-branch of the viewer but I >> ran into a problem. >> I followed the instructions on http://wiki.secondlife.com/wiki/CMake >> but it fails already when >> doing the develop.py step. What I do: >> >> $ svn co ... >> $ cd indra >> $ python2.5 develop.py >> >> It then says: >> >> Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >> \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in >> 'build-darwin-i386' >> -- The C compiler identification is GNU >> -- The CXX compiler identification is GNU >> -- Check for working C compiler: /usr/bin/gcc >> -- Check for working C compiler: /usr/bin/gcc -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Check for working CXX compiler: /usr/bin/g++ >> -- Check for working CXX compiler: /usr/bin/g++ -- works >> -- Detecting CXX compiler ABI info >> -- Detecting CXX compiler ABI info - done >> -- Found PythonInterp: /usr/bin/python2.5 >> Found matching package: >> /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >> Extracting /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >> to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4 >> Writing state to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/installed.xml >> >> and hangs, nothing seems to happen anymore. >> >> I tried to debug this as far as I can with no CMake knowledge and the problem >> seems to be in the FMOD part. With --debug-output I get: >> >> -- Found PythonInterp: /usr/bin/python2.5 >> Called from: [5] /Applications/CMake >> 2.6-0.app/Contents/share/cmake-2.6/Modules/FindPythonInterp.cmake >> [4] >> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Python.cmake >> [3] >> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Prebuilt.cmake >> [2] >> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Audio.cmake >> [1] >> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/llaudio/CMakeLists.txt >> >> And the next line in the CMakeLists.txt seems to be FMOD. When moving >> this up it also hangs earlier. >> >> My OS is Mac OSX 10.5.4 on an Intel Macbook Pro. >> >> Any idea what the problem might be? > > > Would you please try with cmake 2.4.8? 2.6.x is not yet supported. > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From soft at lindenlab.com Mon Jul 28 06:45:24 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 06:45:28 2008 Subject: [sldev] Compile problem on Mac In-Reply-To: <23bbb49e0807280630v67e631c7tc7ebad8245037067@mail.gmail.com> References: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> <23bbb49e0807280630v67e631c7tc7ebad8245037067@mail.gmail.com> Message-ID: Hopefully someone else will reply back with information on how to get more debug information. I'm very new to cmake myself. For the current problem though - I just did an export set against release and I'm not getting this pause. You say that the problem happens around the fmod point. Is it possible that you haven't copied fmod into place, and that our cmake scripts don't do a proper job of detecting this and halting? Per the wiki, we don't distribute fmod ourselves because of license concerns. At current, those have to be copied in place manually. We should probably add a standard place where those can be installed and checked as part of the cmake process. On Mon, Jul 28, 2008 at 8:30 AM, Christian Scholz / Tao Takashi (SL) wrote: > Ok, now that you mention it I also saw that note. Thanks. > > It does not help though, now the output with --debug-output is: > > $ python develop.py > Running 'cmake --debug-output -G \'Xcode\' > -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE > -DUNATTENDED:BOOL=FALSE "" > \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in > 'build-darwin-i386' > Running with debug output on. > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Check size of void* > -- Check size of void* - done > -- Check for working CXX compiler: /usr/bin/g++ > -- Check for working CXX compiler: /usr/bin/g++ -- works > > I deleted and re-downloaded the source again and I also deleted the > CMake-2.6 in /Applications/ > > Any further ideas maybe? Also maybe on how to get more debugging output? > > > On Mon, Jul 28, 2008 at 2:55 PM, Soft wrote: >> >> Would you please try with cmake 2.4.8? 2.6.x is not yet supported. >> >> On Mon, Jul 28, 2008 at 4:06 AM, Christian Scholz / Tao Takashi (SL) >> wrote: >>> Hi there! >>> >>> Today I was trying to compile the interop4-branch of the viewer but I >>> ran into a problem. >>> I followed the instructions on http://wiki.secondlife.com/wiki/CMake >>> but it fails already when >>> doing the develop.py step. What I do: >>> >>> $ svn co ... >>> $ cd indra >>> $ python2.5 develop.py >>> >>> It then says: >>> >>> Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >>> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >>> \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in >>> 'build-darwin-i386' >>> -- The C compiler identification is GNU >>> -- The CXX compiler identification is GNU >>> -- Check for working C compiler: /usr/bin/gcc >>> -- Check for working C compiler: /usr/bin/gcc -- works >>> -- Detecting C compiler ABI info >>> -- Detecting C compiler ABI info - done >>> -- Check for working CXX compiler: /usr/bin/g++ >>> -- Check for working CXX compiler: /usr/bin/g++ -- works >>> -- Detecting CXX compiler ABI info >>> -- Detecting CXX compiler ABI info - done >>> -- Found PythonInterp: /usr/bin/python2.5 >>> Found matching package: >>> /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >>> Extracting /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >>> to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4 >>> Writing state to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/installed.xml >>> >>> and hangs, nothing seems to happen anymore. >>> >>> I tried to debug this as far as I can with no CMake knowledge and the problem >>> seems to be in the FMOD part. With --debug-output I get: >>> >>> -- Found PythonInterp: /usr/bin/python2.5 >>> Called from: [5] /Applications/CMake >>> 2.6-0.app/Contents/share/cmake-2.6/Modules/FindPythonInterp.cmake >>> [4] >>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Python.cmake >>> [3] >>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Prebuilt.cmake >>> [2] >>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Audio.cmake >>> [1] >>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/llaudio/CMakeLists.txt >>> >>> And the next line in the CMakeLists.txt seems to be FMOD. When moving >>> this up it also hangs earlier. >>> >>> My OS is Mac OSX 10.5.4 on an Intel Macbook Pro. >>> >>> Any idea what the problem might be? From tao.takashi at googlemail.com Mon Jul 28 06:51:08 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Mon Jul 28 06:51:11 2008 Subject: [sldev] Compile problem on Mac In-Reply-To: References: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> <23bbb49e0807280630v67e631c7tc7ebad8245037067@mail.gmail.com> Message-ID: <23bbb49e0807280651n7956df0dt5fa2d57be02ed4a2@mail.gmail.com> Hi! On Mon, Jul 28, 2008 at 3:45 PM, Soft wrote: > Hopefully someone else will reply back with information on how to get > more debug information. I'm very new to cmake myself. > > For the current problem though - I just did an export set against > release and I'm not getting this pause. You say that the problem > happens around the fmod point. Is it possible that you haven't copied > fmod into place, and that our cmake scripts don't do a proper job of > detecting this and halting? Well, I did not copy anything as http://wiki.secondlife.com/wiki/CMake does not say so (or I missed this, too. At least there is no link to some fmod site). So I will look into this and try to get fmod into place. > Per the wiki, we don't distribute fmod ourselves because of license > concerns. At current, those have to be copied in place manually. We > should probably add a standard place where those can be installed and > checked as part of the cmake process. Where is that wiki page which explains this? I was mostly following the link to that cmake page. And maybe the release source is different than the interop4 branch in that regard? Thanks for your help! Tao > > > On Mon, Jul 28, 2008 at 8:30 AM, Christian Scholz / Tao Takashi (SL) > wrote: >> Ok, now that you mention it I also saw that note. Thanks. >> >> It does not help though, now the output with --debug-output is: >> >> $ python develop.py >> Running 'cmake --debug-output -G \'Xcode\' >> -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE >> -DUNATTENDED:BOOL=FALSE "" >> \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in >> 'build-darwin-i386' >> Running with debug output on. >> -- Check for working C compiler: /usr/bin/gcc >> -- Check for working C compiler: /usr/bin/gcc -- works >> -- Check size of void* >> -- Check size of void* - done >> -- Check for working CXX compiler: /usr/bin/g++ >> -- Check for working CXX compiler: /usr/bin/g++ -- works >> >> I deleted and re-downloaded the source again and I also deleted the >> CMake-2.6 in /Applications/ >> >> Any further ideas maybe? Also maybe on how to get more debugging output? >> >> >> On Mon, Jul 28, 2008 at 2:55 PM, Soft wrote: >>> >>> Would you please try with cmake 2.4.8? 2.6.x is not yet supported. >>> >>> On Mon, Jul 28, 2008 at 4:06 AM, Christian Scholz / Tao Takashi (SL) >>> wrote: >>>> Hi there! >>>> >>>> Today I was trying to compile the interop4-branch of the viewer but I >>>> ran into a problem. >>>> I followed the instructions on http://wiki.secondlife.com/wiki/CMake >>>> but it fails already when >>>> doing the develop.py step. What I do: >>>> >>>> $ svn co ... >>>> $ cd indra >>>> $ python2.5 develop.py >>>> >>>> It then says: >>>> >>>> Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >>>> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >>>> \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in >>>> 'build-darwin-i386' >>>> -- The C compiler identification is GNU >>>> -- The CXX compiler identification is GNU >>>> -- Check for working C compiler: /usr/bin/gcc >>>> -- Check for working C compiler: /usr/bin/gcc -- works >>>> -- Detecting C compiler ABI info >>>> -- Detecting C compiler ABI info - done >>>> -- Check for working CXX compiler: /usr/bin/g++ >>>> -- Check for working CXX compiler: /usr/bin/g++ -- works >>>> -- Detecting CXX compiler ABI info >>>> -- Detecting CXX compiler ABI info - done >>>> -- Found PythonInterp: /usr/bin/python2.5 >>>> Found matching package: >>>> /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >>>> Extracting /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >>>> to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4 >>>> Writing state to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/installed.xml >>>> >>>> and hangs, nothing seems to happen anymore. >>>> >>>> I tried to debug this as far as I can with no CMake knowledge and the problem >>>> seems to be in the FMOD part. With --debug-output I get: >>>> >>>> -- Found PythonInterp: /usr/bin/python2.5 >>>> Called from: [5] /Applications/CMake >>>> 2.6-0.app/Contents/share/cmake-2.6/Modules/FindPythonInterp.cmake >>>> [4] >>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Python.cmake >>>> [3] >>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Prebuilt.cmake >>>> [2] >>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Audio.cmake >>>> [1] >>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/llaudio/CMakeLists.txt >>>> >>>> And the next line in the CMakeLists.txt seems to be FMOD. When moving >>>> this up it also hangs earlier. >>>> >>>> My OS is Mac OSX 10.5.4 on an Intel Macbook Pro. >>>> >>>> Any idea what the problem might be? > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From soft at lindenlab.com Mon Jul 28 07:51:00 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 07:51:04 2008 Subject: [sldev] Compile problem on Mac In-Reply-To: <23bbb49e0807280651n7956df0dt5fa2d57be02ed4a2@mail.gmail.com> References: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> <23bbb49e0807280630v67e631c7tc7ebad8245037067@mail.gmail.com> <23bbb49e0807280651n7956df0dt5fa2d57be02ed4a2@mail.gmail.com> Message-ID: The instructions at the CMake URL are incomplete. We're beginning to consolidate and squash these branched versions of the build documentation now that the viewer RC branch is about to be based off of a cmake branch. The old main instruction page includes the fmod download and copy step: http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Mac_OS_X) Additionally, if you're working off of interop, you may need to convert the downloaded fmod libraries into a universal library. You can find help for that here: https://lists.secondlife.com/pipermail/sldev/2008-July/011067.html The above will go into the wiki as well if that's necessary at the point where the new viewer RC branches. I'm asking the cmake guys if we can automate that. On Mon, Jul 28, 2008 at 8:51 AM, Christian Scholz / Tao Takashi (SL) wrote: > > Well, I did not copy anything as > > http://wiki.secondlife.com/wiki/CMake > > does not say so (or I missed this, too. At least there is no link to > some fmod site). > > So I will look into this and try to get fmod into place. > >> Per the wiki, we don't distribute fmod ourselves because of license >> concerns. At current, those have to be copied in place manually. We >> should probably add a standard place where those can be installed and >> checked as part of the cmake process. > > Where is that wiki page which explains this? I was mostly following > the link to that cmake page. > And maybe the release source is different than the interop4 branch in > that regard? > > Thanks for your help! > > On Mon, Jul 28, 2008 at 3:45 PM, Soft wrote: >> Hopefully someone else will reply back with information on how to get >> more debug information. I'm very new to cmake myself. >> >> For the current problem though - I just did an export set against >> release and I'm not getting this pause. You say that the problem >> happens around the fmod point. Is it possible that you haven't copied >> fmod into place, and that our cmake scripts don't do a proper job of >> detecting this and halting? >> >> >> On Mon, Jul 28, 2008 at 8:30 AM, Christian Scholz / Tao Takashi (SL) >> wrote: >>> Ok, now that you mention it I also saw that note. Thanks. >>> >>> It does not help though, now the output with --debug-output is: >>> >>> $ python develop.py >>> Running 'cmake --debug-output -G \'Xcode\' >>> -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE >>> -DUNATTENDED:BOOL=FALSE "" >>> \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in >>> 'build-darwin-i386' >>> Running with debug output on. >>> -- Check for working C compiler: /usr/bin/gcc >>> -- Check for working C compiler: /usr/bin/gcc -- works >>> -- Check size of void* >>> -- Check size of void* - done >>> -- Check for working CXX compiler: /usr/bin/g++ >>> -- Check for working CXX compiler: /usr/bin/g++ -- works >>> >>> I deleted and re-downloaded the source again and I also deleted the >>> CMake-2.6 in /Applications/ >>> >>> Any further ideas maybe? Also maybe on how to get more debugging output? >>> >>> >>> On Mon, Jul 28, 2008 at 2:55 PM, Soft wrote: >>>> >>>> Would you please try with cmake 2.4.8? 2.6.x is not yet supported. >>>> >>>> On Mon, Jul 28, 2008 at 4:06 AM, Christian Scholz / Tao Takashi (SL) >>>> wrote: >>>>> Hi there! >>>>> >>>>> Today I was trying to compile the interop4-branch of the viewer but I >>>>> ran into a problem. >>>>> I followed the instructions on http://wiki.secondlife.com/wiki/CMake >>>>> but it fails already when >>>>> doing the develop.py step. What I do: >>>>> >>>>> $ svn co ... >>>>> $ cd indra >>>>> $ python2.5 develop.py >>>>> >>>>> It then says: >>>>> >>>>> Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >>>>> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >>>>> \'/Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra\'' in >>>>> 'build-darwin-i386' >>>>> -- The C compiler identification is GNU >>>>> -- The CXX compiler identification is GNU >>>>> -- Check for working C compiler: /usr/bin/gcc >>>>> -- Check for working C compiler: /usr/bin/gcc -- works >>>>> -- Detecting C compiler ABI info >>>>> -- Detecting C compiler ABI info - done >>>>> -- Check for working CXX compiler: /usr/bin/g++ >>>>> -- Check for working CXX compiler: /usr/bin/g++ -- works >>>>> -- Detecting CXX compiler ABI info >>>>> -- Detecting CXX compiler ABI info - done >>>>> -- Found PythonInterp: /usr/bin/python2.5 >>>>> Found matching package: >>>>> /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >>>>> Extracting /private/var/tmp/cs/install.cache/ogg-vorbis-1.03-1.1.2-darwin-20080613.tar.bz2 >>>>> to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4 >>>>> Writing state to /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/installed.xml >>>>> >>>>> and hangs, nothing seems to happen anymore. >>>>> >>>>> I tried to debug this as far as I can with no CMake knowledge and the problem >>>>> seems to be in the FMOD part. With --debug-output I get: >>>>> >>>>> -- Found PythonInterp: /usr/bin/python2.5 >>>>> Called from: [5] /Applications/CMake >>>>> 2.6-0.app/Contents/share/cmake-2.6/Modules/FindPythonInterp.cmake >>>>> [4] >>>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Python.cmake >>>>> [3] >>>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Prebuilt.cmake >>>>> [2] >>>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/cmake/Audio.cmake >>>>> [1] >>>>> /Users/cs/prj/secondlife/pyogp/llviewer/interop-4/indra/llaudio/CMakeLists.txt >>>>> >>>>> And the next line in the CMakeLists.txt seems to be FMOD. When moving >>>>> this up it also hangs earlier. >>>>> >>>>> My OS is Mac OSX 10.5.4 on an Intel Macbook Pro. >>>>> >>>>> Any idea what the problem might be? >> > > > > -- > Christian Scholz > Tao Takashi (Second Life name) > taotakashi@gmail.com > Blog/Podcast: http://mrtopf.de/blog > Planet: http://worldofsl.com > > Company: http://comlounge.net > Tech Video Blog: http://comlounge.tv > IRC: MrTopf/Tao_T > From alissa_sabre at yahoo.co.jp Mon Jul 28 08:03:42 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Jul 28 08:03:51 2008 Subject: [sldev] Better build instructions In-Reply-To: References: Message-ID: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> > I see no problem with a new build page for each viewer release. > Re-editing the same page over and over for each release means that > historical build information may become lost or overwritten as time > passes. I don't think so. We are using Mediawiki, so all past versions of a page are always available through _history_ tab. Historical build informations are never lost. We "re-edit the same page over and over", keeping older versions. I primarily support just rewriting a same instruction page over and over to synchronize with the latest source. That's what I've been doing in the past. One problem of using Mediawiki history is that it is unclear which wiki version corresponds to which source version. I'm trying to add some words on source version when editing build instruction pages (e.g., "in version X.X", "after version X.X", or "this doesn't apply X.X or later", etc.). I have once added an explicit link to an older version of the page (something like "This page is on version X.X or later; see XXX for previous versions," with XXX is a link to an older version of the page.) It may be my fault that I didn't say it explicitly since then, and this policy is not widely accepted by the community. (Although it is possible that many people recognized my convention and they simply don't like it.) > It takes about 30 seconds to edit the current (old) build page, copy > the text, make a new page for the next viewer, paste, and then update > this new page to make note of any changes. Please don't do it, even if it is handy for you, because: - If you edit an existing page, Mediawiki's built-in compare function shows your changes very easily. However, if you copy the content and rewrite slightly, it will be very hard for other people to find what change you made over the previous version. It is especially true for a developer who has build previous versions and wants to know what is the difference for the latest version. - It makes maintaining other language versions (translations) of the page very hard, partly because it is hard to find changes (see above), and partly because you probably don't copy the corresponding translated pages. On the other hand, a big disadvantage of using Mediawiki history feature for the build instruction for past versions of viewer source is that Mediawiki doesn't allow editing of the history; editing of a page is always on the latest version. (Mediawiki's version control mechanism provides no _branching_.) So, it is hard (or almost impossible) to keep both pre cmake instructions and cmake instructions up-to-date during the transition period (and both the pre and post cmake build process are changing...) Under this situation, I have no objection to have two separate pages, e.g., building instructions for traditional and cmake-based environments. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From soft at lindenlab.com Mon Jul 28 08:23:27 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 08:23:29 2008 Subject: [sldev] Better build instructions In-Reply-To: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> References: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> Message-ID: On Mon, Jul 28, 2008 at 10:03 AM, Alissa Sabre wrote: > > One problem of using Mediawiki history is that it is unclear which > wiki version corresponds to which source version. I'm trying to add > some words on source version when editing build instruction pages > (e.g., "in version X.X", "after version X.X", or "this doesn't apply > X.X or later", etc.). I have once added an explicit link to an older > version of the page (something like "This page is on version X.X or > later; see XXX for previous versions," with XXX is a link to an older > version of the page.) And this is the killer. The viewer source gets a lot of first-time attention once an RC becomes an official release. This is where the most edits traditionally come in. Meanwhile, senior source users are starting to document the new RC. > It may be my fault that I didn't say it explicitly since then, and > this policy is not widely accepted by the community. (Although it is > possible that many people recognized my convention and they simply > don't like it.) The problem is that we've had different people writing with different approaches. Looking back through history, I see competing edits to bring it into line with release/, the RC/ branch, and even past viewer releases. >> It takes about 30 seconds to edit the current (old) build page, copy >> the text, make a new page for the next viewer, paste, and then update >> this new page to make note of any changes. > > - It makes maintaining other language versions (translations) of the > page very hard, partly because it is hard to find changes (see > above), and partly because you probably don't copy the corresponding > translated pages. Anyone have suggestions on how to handle this? > On the other hand, a big disadvantage of using Mediawiki history > feature for the build instruction for past versions of viewer source > is that Mediawiki doesn't allow editing of the history; editing of a > page is always on the latest version. (Mediawiki's version control > mechanism provides no _branching_.) So, it is hard (or almost > impossible) to keep both pre cmake instructions and cmake instructions > up-to-date during the transition period (and both the pre and post > cmake build process are changing...) > > Under this situation, I have no objection to have two separate pages, > e.g., building instructions for traditional and cmake-based > environments. That's fair. We can make a decision about branching each time an RC is created. I suspect that most of the time it won't be needed. cmake was a major disruption, as will be the VS2003 to VS2005 migration. More often there will be a single library added or removed, or an environment setting to tweak. From bill.hoffman at kitware.com Mon Jul 28 08:41:47 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon Jul 28 08:42:40 2008 Subject: [sldev] Second Life Dashboard Message-ID: <488DE8BB.2030201@kitware.com> What would be neat is if you folks would setup a CDash dashboard for this stuff: www.cdash.org. I could create one for Second Life if you folks would use it. I could also help folks setup client build machines to submit to the dashboard. It would be neat if at least one build for each of your major architectures were to track CVS CMake. That way the CMake team would know right away when we break your stuff. :) Would you be interested in having a SecondLife dashboard hosted here: www.cdash.org/CDash? The clients run ctest scripts something like this: http://www.cdash.org/CDash/viewNotes.php?buildid=131088 You would put that in a cronjob or schedule task, and run it once a night. -Bill From soft at lindenlab.com Mon Jul 28 08:52:02 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 08:52:05 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: <488A4074.4090701@lindenlab.com> References: <4887CFF6.9030004@gmail.com> <4887DDD0.8030504@lindenlab.com> <4888A763.4060301@watson.ibm.com> <488A4074.4090701@lindenlab.com> Message-ID: If the release notes for each server or viewer release could include a list of merged branches, volunteers would have enough information to close or reopen fixed-internally issues on their own. On Fri, Jul 25, 2008 at 4:07 PM, Joshua Bell wrote: > This should be indicated by setting the Fix Version as soon as it's in an > RC. No Fix Version should imply that it's not folded into any particular > release yet. That's how we track fixes internally. > > Odds are there will be some lag, since correct representation of issue > status in JIRA is important but not a blocker for releases. > > (Once I get that cloning machine up and running for my team, though...) > > Matthew Dowd wrote: >> >> Is it possible to (easily) distinguish between a "fixed pending" which is >> in the RC cycle, and a "fixed pending" which is still in some internal >> branch yet to be folded into the RC cycle at some as yet undecided stage? >> Matthew >> >> >> > Date: Thu, 24 Jul 2008 15:54:44 -0700 >> > From: ramzi@lindenlab.com >> > To: monkowsk@watson.ibm.com >> > Subject: Re: [sldev] Fixed Internally resolution. >> > CC: sldev@lists.secondlife.com; rdw@lindenlab.com >> > >> > Yes, it's probably not being applied well uniformly. Another wrinkle is >> > that the reporter may Resolve/Close the issue of their own accord, the >> > very moment that a fix appears in an RC build. (Mike- I think this >> > explains much of that number.) >> > >> > 1. My operative has been to set the status as (still) "Fixed Pending" >> > while the fix is propagating through the RC cycle. (Depending on the >> > person changing it, only some of these have their 'Fix Version' is set >> > too.) >> > 2. When the bug fix appears in an official viewer (to ALL residents), >> > its status can be moved to "Fixed." (And if it has no Fix Version at >> > this point, I'm sure to set it then.) >> > >> > With the official release of viewer 1.20 today, it was on my list to >> > move Fixed Pending->Fixed for the tasks in the 1.20 release notes. I >> > just accomplished this, but the delta was only 28 issues from their >> > status as of this morning... So I may not have made such a big dent in >> > the number Jason mentions at the top of the thread. >> > -Ramzi >> > >> > >> > Mike Monkowski wrote: >> > > I don't think that's being done uniformly. There are 166 VWR bugs >> > > with Fix Version "1.20 Release Candidate". Only six of those have >> > > Status "Fix Pending". >> > > >> > > Mike >> > > >> > > >> > > Ryan Williams (Which) wrote: >> > >> Jason Giglio wrote: >> > >> >> > >>> "Fixed Internally" number is ballooning again. Is there a process to >> > >>> reconcile shipped code? >> > >>> >> > >>> Is code that is released in a RC branch considered fixed, or fixed >> > >>> internally? >> > >> >> > >> I've been treating RC as fixed internally. Perhaps that's wrong? >> > > _ >> > >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> >> ------------------------------------------------------------------------ >> Get Hotmail on your Mobile! Try it Now! >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From soft at lindenlab.com Mon Jul 28 08:59:29 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 08:59:33 2008 Subject: [sldev] Fixed Internally resolution. In-Reply-To: References: <4887CFF6.9030004@gmail.com> <4887DDD0.8030504@lindenlab.com> <4888A763.4060301@watson.ibm.com> <488A4074.4090701@lindenlab.com> Message-ID: If anyone's got an itch on these, my time's tight as anyone's, but I could meet half-way... For existing issues - if someone wants to volunteer to collect a list of the branches currently in question, I'll chase down the release status of each. You should be able to do a query for all fixed-internally issues, massaged to include the fixed internally branch as a report column. Just make a list of the branches you saw and post it here. If you see fixed-internally branches without a branch listed, some Linden has been naughty. Add a comment asking them to finish their homework, or make a list and post here if a role account ("WorkingOnIt Linden") owns it. On Mon, Jul 28, 2008 at 10:52 AM, Soft wrote: > If the release notes for each server or viewer release could include a > list of merged branches, volunteers would have enough information to > close or reopen fixed-internally issues on their own. > > On Fri, Jul 25, 2008 at 4:07 PM, Joshua Bell wrote: >> This should be indicated by setting the Fix Version as soon as it's in an >> RC. No Fix Version should imply that it's not folded into any particular >> release yet. That's how we track fixes internally. >> >> Odds are there will be some lag, since correct representation of issue >> status in JIRA is important but not a blocker for releases. >> >> (Once I get that cloning machine up and running for my team, though...) >> >> Matthew Dowd wrote: >>> >>> Is it possible to (easily) distinguish between a "fixed pending" which is >>> in the RC cycle, and a "fixed pending" which is still in some internal >>> branch yet to be folded into the RC cycle at some as yet undecided stage? >>> Matthew >>> >>> >>> > Date: Thu, 24 Jul 2008 15:54:44 -0700 >>> > From: ramzi@lindenlab.com >>> > To: monkowsk@watson.ibm.com >>> > Subject: Re: [sldev] Fixed Internally resolution. >>> > CC: sldev@lists.secondlife.com; rdw@lindenlab.com >>> > >>> > Yes, it's probably not being applied well uniformly. Another wrinkle is >>> > that the reporter may Resolve/Close the issue of their own accord, the >>> > very moment that a fix appears in an RC build. (Mike- I think this >>> > explains much of that number.) >>> > >>> > 1. My operative has been to set the status as (still) "Fixed Pending" >>> > while the fix is propagating through the RC cycle. (Depending on the >>> > person changing it, only some of these have their 'Fix Version' is set >>> > too.) >>> > 2. When the bug fix appears in an official viewer (to ALL residents), >>> > its status can be moved to "Fixed." (And if it has no Fix Version at >>> > this point, I'm sure to set it then.) >>> > >>> > With the official release of viewer 1.20 today, it was on my list to >>> > move Fixed Pending->Fixed for the tasks in the 1.20 release notes. I >>> > just accomplished this, but the delta was only 28 issues from their >>> > status as of this morning... So I may not have made such a big dent in >>> > the number Jason mentions at the top of the thread. >>> > -Ramzi >>> > >>> > >>> > Mike Monkowski wrote: >>> > > I don't think that's being done uniformly. There are 166 VWR bugs >>> > > with Fix Version "1.20 Release Candidate". Only six of those have >>> > > Status "Fix Pending". >>> > > >>> > > Mike >>> > > >>> > > >>> > > Ryan Williams (Which) wrote: >>> > >> Jason Giglio wrote: >>> > >> >>> > >>> "Fixed Internally" number is ballooning again. Is there a process to >>> > >>> reconcile shipped code? >>> > >>> >>> > >>> Is code that is released in a RC branch considered fixed, or fixed >>> > >>> internally? >>> > >> >>> > >> I've been treating RC as fixed internally. Perhaps that's wrong? >>> > > _ >>> > >>> > _______________________________________________ >>> > Policies and (un)subscribe information available here: >>> > http://wiki.secondlife.com/wiki/SLDev >>> > Please read the policies before posting to keep unmoderated posting >>> > privileges >>> >>> ------------------------------------------------------------------------ >>> Get Hotmail on your Mobile! Try it Now! >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From bill.hoffman at kitware.com Mon Jul 28 09:53:07 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon Jul 28 09:54:03 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> Message-ID: <488DF973.3030001@kitware.com> Sammy Frederix wrote: > > On 27/07/2008, at 1:43 AM, Bill Hoffman wrote: > >> OK, 2.6.1 RC 13 is here: http://www.cmake.org/files/v2.6/ >> >> Please give it a try. Should fix the Xcode error, and the visual >> studio link error. If it builds SecondLife, I will make it the >> official 2.6.1 release. > > using Xcode 3.1, I get the following build failure for building the > (unpatched) release branch: > > i686-apple-darwin9-g++-4.0.1: > /Users/home/SLOrig/release/indra/../libraries/universal-darwin/lib_release/lljpeg: > No such file or directory OK, I did not merge in all the fixes for this problem into the 2.6 branch. I have an RC 14 (for Mac only) here: http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14-Darwin-universal.tar.gz http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14-Darwin-universal.dmg Please give it a try. -Bill From soft at lindenlab.com Mon Jul 28 12:12:30 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 12:12:34 2008 Subject: [sldev] Making cmake do the fmod copy Message-ID: Anyone want a swing at making cmake copy the fmod libs into the tree if an environment variable is set to the location of the untarred/unpacked/unzipped fmod SDK? This would get the last bit of manual ugliness out of the build process on all three platforms. I previously said I'd ping the cmake team about this, but then realized someone on-list might already have the interest and know-how. I JIRAd this as https://jira.secondlife.com/browse/VWR-8393 and imported. If I see a patch appear on jira.secondlife.com before anything's ready internally, I'll gladly fast-track import it. From aimee at ama-zing.co.uk Mon Jul 28 12:32:47 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Jul 28 12:33:16 2008 Subject: [sldev] Making cmake do the fmod copy References: <956F6B51-C986-416C-A2E2-20018A071CCC@ama-zing.co.uk> Message-ID: Someone could even go as far as making it auto-download it if it can't find it? Which then gets round the issue of not being able to redistribute it :D Aimee. On Jul 28, 2008, at 20:12, Soft wrote: > Anyone want a swing at making cmake copy the fmod libs into the tree > if an environment variable is set to the location of the > untarred/unpacked/unzipped fmod SDK? This would get the last bit of > manual ugliness out of the build process on all three platforms. I > previously said I'd ping the cmake team about this, but then realized > someone on-list might already have the interest and know-how. From kf6kjg at gmail.com Mon Jul 28 12:43:27 2008 From: kf6kjg at gmail.com (Ricky) Date: Mon Jul 28 12:43:32 2008 Subject: [sldev] Better build instructions In-Reply-To: References: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> Message-ID: <3bb9647e0807281243jee759etd3aa581d25045dac@mail.gmail.com> Alissia's comments are exactly what I was talking about. Just I wasn't quite so eloquent. :D I'm ok with branching a new page only for complete re-structures of the build system. Should keep the page count down, and still allow us to use the history features of MediaWiki. Just so long as we link to the archived edition of the page just before where a given incompatibility was introduced, and/or mark such changes explicitly in the comments. Ricky On Mon, Jul 28, 2008 at 8:23 AM, Soft wrote: > On Mon, Jul 28, 2008 at 10:03 AM, Alissa Sabre > wrote: > > > > One problem of using Mediawiki history is that it is unclear which > > wiki version corresponds to which source version. I'm trying to add > > some words on source version when editing build instruction pages > > (e.g., "in version X.X", "after version X.X", or "this doesn't apply > > X.X or later", etc.). I have once added an explicit link to an older > > version of the page (something like "This page is on version X.X or > > later; see XXX for previous versions," with XXX is a link to an older > > version of the page.) > > And this is the killer. The viewer source gets a lot of first-time > attention once an RC becomes an official release. This is where the > most edits traditionally come in. Meanwhile, senior source users are > starting to document the new RC. > > > > It may be my fault that I didn't say it explicitly since then, and > > this policy is not widely accepted by the community. (Although it is > > possible that many people recognized my convention and they simply > > don't like it.) > > The problem is that we've had different people writing with different > approaches. Looking back through history, I see competing edits to > bring it into line with release/, the RC/ branch, and even past viewer > releases. > > > >> It takes about 30 seconds to edit the current (old) build page, copy > >> the text, make a new page for the next viewer, paste, and then update > >> this new page to make note of any changes. > > > > - It makes maintaining other language versions (translations) of the > > page very hard, partly because it is hard to find changes (see > > above), and partly because you probably don't copy the corresponding > > translated pages. > > Anyone have suggestions on how to handle this? > > > > On the other hand, a big disadvantage of using Mediawiki history > > feature for the build instruction for past versions of viewer source > > is that Mediawiki doesn't allow editing of the history; editing of a > > page is always on the latest version. (Mediawiki's version control > > mechanism provides no _branching_.) So, it is hard (or almost > > impossible) to keep both pre cmake instructions and cmake instructions > > up-to-date during the transition period (and both the pre and post > > cmake build process are changing...) > > > > Under this situation, I have no objection to have two separate pages, > > e.g., building instructions for traditional and cmake-based > > environments. > > That's fair. We can make a decision about branching each time an RC is > created. I suspect that most of the time it won't be needed. cmake was > a major disruption, as will be the VS2003 to VS2005 migration. More > often there will be a single library added or removed, or an > environment setting to tweak. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080728/573673f5/attachment.htm From bill.hoffman at kitware.com Mon Jul 28 15:11:09 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon Jul 28 15:12:03 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488C9274.4070009@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B7450.80307@gmx.net> <488B79A5.2000406@kitware.com> <488B8480.1080204@gmx.net> <488C9274.4070009@kitware.com> Message-ID: <488E43FD.9020604@kitware.com> Bill Hoffman wrote: > Carsten Juttner wrote: >> I have attached all 3 versions, first 2.4.8, then 2.6.1-p13 without >> the patch from my previous mail and finally 2.6.1-p13 with that patch >> for the CMakeLists. >> >> As you can see, 2.4.8 used -llcommon while 2.6.1-p13 uses >> ../llcommon/libllcommon.a >> > That is not the problem. The problem is that the order of the > libraries has changed from 2.4.8. > > 2.4.8 has this: > -lexpat -Wl,-Bstatic -lllmessage -Wl,-Bdynamic -lcurl > > > 2.6.1 has this: > -lcurl /usr/local/lib/libcares.a -lssl -lcrypto > /usr/local/lib/libxmlrpc-epi.so -laprutil-1 -lapr-1 -lexpat -lcurl > /usr/local/lib/libcares.a -lssl -lcrypto /usr/local/lib/libxmlrpc-epi.so > -laprutil-1 -lapr-1 ../llmessage/libllmessage.a > Carsten, I am having a hard time reproducing this one. I went on a linux box and ran cmake 2.6 on an svn checkout of second life: svn co http://svn.secondlife.com/svn/linden/release/ I did not have all the required software, so I hacked up the cmake cache with bogus entries. However, I was able to get cmake to produce a link line like this: /usr/bin/c++ -Wall -Wno-sign-compare -Wno-trigraphs -Werror -Wno-reorder -DLL_RELEASE=1 -DNDEBUG -DLL_RELEASE_WITH_DEBUG_INFO=1 -fPIC -Wl,--as-needed CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o -o linux-crash-logger -rdynamic -L/home/hoffman/second/release/indra-build/llcrashlogger -L/home/hoffman/second/release/indra-build/llvfs -L/home/hoffman/second/release/indra-build/llxml -L/usr -L/home/hoffman/second/release/indra-build/llmessage -L/home/hoffman/second/release/indra-build/llmath -L/home/hoffman/second/release/indra-build/llcommon ../llcrashlogger/libllcrashlogger.a ../llvfs/libllvfs.a ../llxml/libllxml.a -lexpat -lcurl -lssl -lcrypto /usr/libxml.a -lexpat -lcurl -lssl -lcrypto /usr/libxml.a ../llmessage/libllmessage.a ../llmath/libllmath.a ../llcommon/libllcommon.a -lz -lglib-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lpng12 -lboost_signals-mt -lcurl -lcrypto /usr/libxml.a ../llvfs/libllvfs.a ../llmath/libllmath.a ../llcommon/libllcommon.a -lglib-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lpng12 -lboost_signals-mt Not that there is a -lcurl that comes after ../llmessage/libllmessage.a, and that is key for getting this to work. On your system where it does not work, can you add a few message commands to the CMakeLists.txt files, and rerun cmake, and send me the output? 1. indra/cmake/LLMessage.cmake message{"LLMESSAGE_LIBRARIES = ${LLMESSAGE_LIBRARIES}") 2. In indra/linux_crash_logger/CMakeLists.txt: message(" target link libraries for linux-crash-logger ${LLCRASHLOGGER_LIBRARIES} ${LLVFS_LIBRARIES} ${LLXML_LIBRARIES} ${LLMESSAGE_LIBRARIES} ${LLVFS_LIBRARIES} ${LLMATH_LIBRARIES} ${LLCOMMON_LIBRARIES} ${UI_LIBRARIES} ${BOOST_SIGNALS_LIBRARY} ${DB_LIBRARIES} ") Also, if you could send me the CMakeCache.txt file from your binary tree, that would be helpful in figuring out what is wrong. I think this is the last issue with 2.6.1. Thanks. -Bill From dmahalko at gmail.com Mon Jul 28 15:50:46 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Jul 28 15:50:47 2008 Subject: [sldev] Better build instructions In-Reply-To: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> References: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> Message-ID: On Mon, Jul 28, 2008 at 10:03 AM, Alissa Sabre wrote: > We are using Mediawiki, so all past versions of a page are always > available through _history_ tab. Historical build informations are > never lost. We "re-edit the same page over and over", keeping older > versions. Since history pages cannot be edited as branches of the current page it is difficult to impossible to update an old version of a page which just so happens to be incorrect and needs to be fixed because the build information was wrong way back when, or new information needs to be added. >> It takes about 30 seconds to edit the current (old) build page, copy >> the text, make a new page for the next viewer, paste, and then update >> this new page to make note of any changes. > > Please don't do it, even if it is handy for you, because: > > - If you edit an existing page, Mediawiki's built-in compare function > shows your changes very easily. However, if you copy the content > and rewrite slightly, it will be very hard for other people to find > what change you made over the previous version. It is especially > true for a developer who has build previous versions and wants to > know what is the difference for the latest version. > > - It makes maintaining other language versions (translations) of the > page very hard, partly because it is hard to find changes (see > above), and partly because you probably don't copy the corresponding > translated pages. If this software has the full capabilities of Wikipedia, then common elements that repeat over and over can be handled with templates. This way you can easily have 20 separate build pages which all refer to the same particular build tool or library version, and encapsulate the info for the tools or libraries inside templates. Changing the template auto-updates all other pages using it. If a new tool or library release will need different instructions, make a new template to be used for future versions of the page. {{Common_Compile_Intro-Viewer_Series_1.22}} For this particular version you need to blah blah blah. {{Intro-Compiling_With_VS2005}} Tools used to compile this viewer: {{BuildTool-Cygwin_x.x.x}} {{BuildTool-CMake_x.x.x}} Libraries used to compile this viewer: {{BuildLibrary-FMod x.x.x}} {{Intro-Compiling_With_VS2008}} Tools used to compile this viewer: {{BuildTool-Cygwin_x.x.x}} {{BuildTool-CMake_x.x.x}} Libraries used to compile this viewer: {{BuildLibrary-FMod x.x.x}} By doing this, the majority of the page may just be template links with just a few sentences describing the specific details of this release, and each release can have its own custom page which can be easily updated separately of others. - Scalar Tardis / Dale Mahalko From sheet.spotter at gmail.com Mon Jul 28 16:06:58 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Mon Jul 28 16:07:03 2008 Subject: [sldev] Building the viewer for Windows, without QuickTime Message-ID: Previously the wiki described how to build the Windows version of the viewer without support for QuickTime. This information is important for developers that have not registered as an Apple developer. To build the viewer for Windows without support for QuickTime: 1. Check out the source code from SVN. 2. Edit the "linden/indra/cmake/LLMedia.cmake" file to delete the line that mentions "$(QUICKTIME_LIBRARY)". 3. Type develop.py to generate the solution and project files for VisualStudio. 4. Use VisualStudio to build the viewer. The only new step is editing the CMake file (in step 2). Is there a better way of handling this? Or should I add the extra step to these instructions http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake ? Sheet Spotter P.S. it might be time to add a "subject line keyword" of "[BUILD]" to http://wiki.secondlife.com/wiki/SLDev , since there is a high volume of build related questions and comments. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080728/8fb710ae/attachment-0001.htm From carjay at gmx.net Mon Jul 28 16:50:00 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Jul 28 16:50:07 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488E43FD.9020604@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B7450.80307@gmx.net> <488B79A5.2000406@kitware.com> <488B8480.1080204@gmx.net> <488C9274.4070009@kitware.com> <488E43FD.9020604@kitware.com> Message-ID: <488E5B28.6090107@gmx.net> Bill Hoffman wrote: > On your system where it does not work, can you add a few message > commands to the CMakeLists.txt files, and rerun cmake, and send me the > output? Sure, I'll send the files off-list in a separate mail since they are probably of no interest to anyone else. Thanks for your efforts! Regards, Carsten From tao.takashi at googlemail.com Mon Jul 28 17:06:19 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Mon Jul 28 17:06:20 2008 Subject: Fwd: [sldev] Compile problem on Mac In-Reply-To: <23bbb49e0807281705s469506fs6b4f28ed56e3e1a2@mail.gmail.com> References: <23bbb49e0807280206h5dacdc8bkb689c654ce9571c3@mail.gmail.com> <23bbb49e0807280630v67e631c7tc7ebad8245037067@mail.gmail.com> <23bbb49e0807280651n7956df0dt5fa2d57be02ed4a2@mail.gmail.com> <23bbb49e0807281705s469506fs6b4f28ed56e3e1a2@mail.gmail.com> Message-ID: <23bbb49e0807281706w5f5dd9b5g90efc59b0eedb6c7@mail.gmail.com> I forgot the list reply ;-) ---------- Forwarded message ---------- From: Christian Scholz / Tao Takashi (SL) Date: Tue, Jul 29, 2008 at 2:05 AM Subject: Re: [sldev] Compile problem on Mac To: Soft Hi! On Mon, Jul 28, 2008 at 4:51 PM, Soft wrote: > The instructions at the CMake URL are incomplete. We're beginning to > consolidate and squash these branched versions of the build > documentation now that the viewer RC branch is about to be based off > of a cmake branch. The old main instruction page includes the fmod > download and copy step: > http://wiki.secondlife.com/wiki/Compiling_the_viewer_(Mac_OS_X) Ok, I did that and also the lipo part. Now it stops even earlier though: Labertasche:indra cs$ python develop.py Running 'cmake --debug-output -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" \'/Users/cs/prj/secondlife/pyogp/llviewer/linden/indra\'' in 'build-darwin-i386' Running with debug output on. -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works or it does not create as much output as 2.6 I will try again on a different machine tomorrow. It also happens with the release btw. -- Tao -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From aimee at ama-zing.co.uk Mon Jul 28 17:33:35 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Jul 28 17:34:05 2008 Subject: [sldev] llDetectedTouch* causing problems with HUDs possibly? Message-ID: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> Is anyone else having problems clicking buttons on HUDs when running the latest release SVN? The coordinates seem to be getting scaled wrong when clicking them, so HUDs at my bottom left work fine, while ones further towards the top or right I have to click to the right of or above them to make them work, which obviously isn't possible when they're at the edge. I suspect this may be to do with the new touch position detection stuff that's just gone in? Though this is just with my ordinary existing HUDs. Aimee. From aimee at ama-zing.co.uk Mon Jul 28 17:38:35 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Jul 28 17:39:05 2008 Subject: [sldev] Re: llDetectedTouch* causing problems with HUDs possibly? In-Reply-To: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> References: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> Message-ID: <051B18F7-CFD5-4164-9C20-3A18B3C1C517@ama-zing.co.uk> Ah! The click position on the HUD layer is getting scaled with the UI scaling setting, I always run with it at between 0.9 and 0.95ish. Works fine at 1.0 but clicks are detected off position with different scaling, so yeah, definite bug. AImee. On Jul 29, 2008, at 01:33, Aimee Walton wrote: > Is anyone else having problems clicking buttons on HUDs when > running the latest release SVN? The coordinates seem to be getting > scaled wrong when clicking them, so HUDs at my bottom left work > fine, while ones further towards the top or right I have to click > to the right of or above them to make them work, which obviously > isn't possible when they're at the edge. > > I suspect this may be to do with the new touch position detection > stuff that's just gone in? Though this is just with my ordinary > existing HUDs. > > Aimee. From soft at lindenlab.com Mon Jul 28 18:13:51 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 18:13:54 2008 Subject: [sldev] Re: llDetectedTouch* causing problems with HUDs possibly? In-Reply-To: <051B18F7-CFD5-4164-9C20-3A18B3C1C517@ama-zing.co.uk> References: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> <051B18F7-CFD5-4164-9C20-3A18B3C1C517@ama-zing.co.uk> Message-ID: Ha! That's definitely a bug. If you want to put that in a JIRA, Qarl would want to know about that. I'm pretty sure that was his baby. On Mon, Jul 28, 2008 at 7:38 PM, Aimee Walton wrote: > Ah! The click position on the HUD layer is getting scaled with the UI > scaling setting, I always run with it at between 0.9 and 0.95ish. Works fine > at 1.0 but clicks are detected off position with different scaling, so yeah, > definite bug. > > AImee. > > On Jul 29, 2008, at 01:33, Aimee Walton wrote: > >> Is anyone else having problems clicking buttons on HUDs when running the >> latest release SVN? The coordinates seem to be getting scaled wrong when >> clicking them, so HUDs at my bottom left work fine, while ones further >> towards the top or right I have to click to the right of or above them to >> make them work, which obviously isn't possible when they're at the edge. >> >> I suspect this may be to do with the new touch position detection stuff >> that's just gone in? Though this is just with my ordinary existing HUDs. >> >> Aimee. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sammy.frederix at gmail.com Mon Jul 28 19:09:16 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Mon Jul 28 19:09:23 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488DF973.3030001@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> <488DF973.3030001@kitware.com> Message-ID: On 29/07/2008, at 2:53 AM, Bill Hoffman wrote: > Sammy Frederix wrote: >> On 27/07/2008, at 1:43 AM, Bill Hoffman wrote: >>> OK, 2.6.1 RC 13 is here: http://www.cmake.org/files/v2.6/ >>> >>> Please give it a try. Should fix the Xcode error, and the visual >>> studio link error. If it builds SecondLife, I will make it the >>> official 2.6.1 release. >> using Xcode 3.1, I get the following build failure for building the >> (unpatched) release branch: >> i686-apple-darwin9-g++-4.0.1: /Users/home/SLOrig/release/indra/../ >> libraries/universal-darwin/lib_release/lljpeg: No such file or >> directory > > > OK, I did not merge in all the fixes for this problem into the 2.6 > branch. I have an RC 14 (for Mac only) here: > > http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14-Darwin-universal.tar.gz > http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14-Darwin-universal.dmg > > Please give it a try. > > -Bill Bill, SL now builds, but doesn't run: ** BUILD SUCCEEDED ** xcodebuild -target Second Life -configuration Release $ open "build-darwin-i386/newview/Release/Second Life.app" LSOpenFromURLSpec() failed with error -10661 for the file /Users/home/ SLOrig/release/indra/build-darwin-i386/newview/Release/Second Life.app. Looking into /Users/home/SLOrig/release/indra/build-darwin-i386/newview/Release/ Second Life.app/Contents/MacOS/ it looks like the actual executable is missing I built cmake from http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14.tar.gz From aimee at ama-zing.co.uk Mon Jul 28 19:17:08 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Jul 28 19:17:41 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <488DF973.3030001@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> <488DF973.3030001@kitware.com> Message-ID: <64D83770-AFA5-4BD4-8E30-B257ECD125E8@ama-zing.co.uk> On Jul 28, 2008, at 17:53, Bill Hoffman wrote: > OK, I did not merge in all the fixes for this problem into the 2.6 > branch. I have an RC 14 (for Mac only) here: > > http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14-Darwin- > universal.tar.gz > http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-14-Darwin-universal.dmg OK, ran develop.py, so far so good (though gives warnings about the things we need to put right, fair enough). Run Xcode, builds perfectly ... but then ... it deletes the executables it's just built! :D Rerunning the link line manually gave a fully working product. It does this right after running viewer_manifest.py ... echo "Depend check for xcode" Depend check for xcode cd /Users/aimee/Documents/Second-Life/Source/release-clean/indra/ build-darwin-i386 && make -C /Users/aimee/Documents/Second-Life/ Source/release-clean/indra/build-darwin-i386 -f /Users/aimee/ Documents/Second-Life/Source/release-clean/indra/build-darwin-i386/ CMakeScripts/XCODE_DEPEND_HELPER.make all.RelWithDebInfo /bin/rm -f /Users/aimee/Documents/Second-Life/Source/release-clean/ indra/build-darwin-i386/mac_crash_logger/RelWithDebInfo/mac-crash-logger /bin/rm -f /Users/aimee/Documents/Second-Life/Source/release-clean/ indra/build-darwin-i386/mac_updater/RelWithDebInfo/mac-updater /bin/rm -f /Users/aimee/Documents/Second-Life/Source/release-clean/ indra/build-darwin-i386/newview/RelWithDebInfo/Second\ Life.app/ Contents/MacOS/Second\ Life echo "Depend check for xcode" Depend check for xcode cd /Users/aimee/Documents/Second-Life/Source/release-clean/indra/ build-darwin-i386/newview && make -C /Users/aimee/Documents/Second- Life/Source/release-clean/indra/build-darwin-i386/newview -f /Users/ aimee/Documents/Second-Life/Source/release-clean/indra/build-darwin- i386/newview/CMakeScripts/XCODE_DEPEND_HELPER.make all.RelWithDebInfo /bin/rm -f /Users/aimee/Documents/Second-Life/Source/release-clean/ indra/build-darwin-i386/newview/RelWithDebInfo/Second\ Life.app/ Contents/MacOS/Second\ Life From gbrandon at gmail.com Mon Jul 28 20:05:12 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Jul 28 20:05:17 2008 Subject: [sldev] Re: llDetectedTouch* causing problems with HUDs possibly? In-Reply-To: References: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> <051B18F7-CFD5-4164-9C20-3A18B3C1C517@ama-zing.co.uk> Message-ID: Link it up, please! I use 0.875 UI Size, am a huge UI Size reduction advocate, and would hate to see a problem with it and the new functionality :P On Mon, Jul 28, 2008 at 9:13 PM, Soft wrote: > Ha! That's definitely a bug. If you want to put that in a JIRA, Qarl > would want to know about that. I'm pretty sure that was his baby. > > On Mon, Jul 28, 2008 at 7:38 PM, Aimee Walton > wrote: > > Ah! The click position on the HUD layer is getting scaled with the UI > > scaling setting, I always run with it at between 0.9 and 0.95ish. Works > fine > > at 1.0 but clicks are detected off position with different scaling, so > yeah, > > definite bug. > > > > AImee. > > > > On Jul 29, 2008, at 01:33, Aimee Walton wrote: > > > >> Is anyone else having problems clicking buttons on HUDs when running the > >> latest release SVN? The coordinates seem to be getting scaled wrong when > >> clicking them, so HUDs at my bottom left work fine, while ones further > >> towards the top or right I have to click to the right of or above them > to > >> make them work, which obviously isn't possible when they're at the edge. > >> > >> I suspect this may be to do with the new touch position detection stuff > >> that's just gone in? Though this is just with my ordinary existing HUDs. > >> > >> Aimee. > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080728/6f549b34/attachment-0001.htm From aimee at ama-zing.co.uk Mon Jul 28 20:09:44 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Jul 28 20:10:12 2008 Subject: [sldev] Re: llDetectedTouch* causing problems with HUDs possibly? In-Reply-To: References: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> <051B18F7-CFD5-4164-9C20-3A18B3C1C517@ama-zing.co.uk> Message-ID: On Jul 29, 2008, at 04:05, Brandon Lockaby wrote: > Link it up, please! I use 0.875 UI Size, am a huge UI Size > reduction advocate, and would hate to see a problem with it and the > new functionality :P https://jira.secondlife.com/browse/VWR-8400 UI scaling affects position of clicks received by HUDs in latest build from SVN. There ya go :) Aimee. From soft at lindenlab.com Mon Jul 28 20:28:30 2008 From: soft at lindenlab.com (Soft) Date: Mon Jul 28 20:28:33 2008 Subject: [sldev] Re: llDetectedTouch* causing problems with HUDs possibly? In-Reply-To: References: <861E5276-4F50-4F76-B75E-7D11C20BB775@ama-zing.co.uk> <051B18F7-CFD5-4164-9C20-3A18B3C1C517@ama-zing.co.uk> Message-ID: On Mon, Jul 28, 2008 at 10:09 PM, Aimee Walton wrote: > On Jul 29, 2008, at 04:05, Brandon Lockaby wrote: > >> Link it up, please! I use 0.875 UI Size, am a huge UI Size reduction >> advocate, and would hate to see a problem with it and the new functionality >> :P > > https://jira.secondlife.com/browse/VWR-8400 UI scaling affects position of > clicks received by HUDs in latest build from SVN. > > There ya go :) Thanks! Importd't. From marinekelley at gmail.com Mon Jul 28 22:22:34 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Mon Jul 28 22:22:39 2008 Subject: [sldev] SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp In-Reply-To: References: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> Message-ID: <9e52a8c10807282222q15994d9ap91644c60e761b3b5@mail.gmail.com> Hi again, I'm at a loss here, sorry to insist but has anybody found any clue about that crash ? People are constantly messaging me believing I introduced that bug with my own code... Someone who downloads the source code for Windows from the Source Downloads webpage (not svn) should experience that bug too. After a fresh compile, run and click on a weblink on the login page (no need to even log on), and the viewer should crash. Any help would be greatly appreciated, thanks ! PS : sorry for the double email hawk, I hit Reply instead of Reply to All 2008/7/27 > Same problem here + that the Viewer crashes directly on startup, when i > leave the llkdu.dll in the Folder.. > > anyone ? > > > Greetings > > Hawk > > > Hello all, > > > > For hours now I've been hunting a crash that occurs when clicking on a > > link > > on the login page. Other crashes in the same flavor are occurring > in-world > > when using the All tab of the Search window (especially when clicking on > > Page 2 or so, but that's another story I think). Thinking it may come > from > > my own code after patching, I've spent time trying to figure it out, to > no > > avail. > > > ............. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080729/24c127b2/attachment.htm From danteferret at gmail.com Mon Jul 28 23:42:29 2008 From: danteferret at gmail.com (Dante Tucker) Date: Mon Jul 28 23:42:32 2008 Subject: [sldev] SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp In-Reply-To: <9e52a8c10807282222q15994d9ap91644c60e761b3b5@mail.gmail.com> References: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> <9e52a8c10807282222q15994d9ap91644c60e761b3b5@mail.gmail.com> Message-ID: <4d211a610807282342o7fd39da1q296fe7ad8f3a7454@mail.gmail.com> I get that problem with the "cool viewer" Which I believe includes your code. However I have also built the client in question from the source download page, it did not have the same problem. lol, I also hit reply, sorry. On Tue, Jul 29, 2008 at 1:22 AM, Marine Kelley wrote: > Hi again, > > I'm at a loss here, sorry to insist but has anybody found any clue about > that crash ? People are constantly messaging me believing I introduced that > bug with my own code... Someone who downloads the source code for Windows > from the Source Downloads webpage (not svn) should experience that bug too. > After a fresh compile, run and click on a weblink on the login page (no need > to even log on), and the viewer should crash. > > Any help would be greatly appreciated, thanks ! > > PS : sorry for the double email hawk, I hit Reply instead of Reply to All > > > > 2008/7/27 > >> Same problem here + that the Viewer crashes directly on startup, when i >> leave the llkdu.dll in the Folder.. >> >> anyone ? >> >> >> Greetings >> >> Hawk >> >> > Hello all, >> > >> > For hours now I've been hunting a crash that occurs when clicking on a >> > link >> > on the login page. Other crashes in the same flavor are occurring >> in-world >> > when using the All tab of the Search window (especially when clicking on >> > Page 2 or so, but that's another story I think). Thinking it may come >> from >> > my own code after patching, I've spent time trying to figure it out, to >> no >> > avail. >> > >> ............. >> >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080729/29c4d892/attachment.htm From robin.cornelius at gmail.com Tue Jul 29 02:47:24 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 29 02:47:26 2008 Subject: [sldev] Making cmake do the fmod copy In-Reply-To: References: Message-ID: On Mon, Jul 28, 2008 at 8:12 PM, Soft wrote: > Anyone want a swing at making cmake copy the fmod libs into the tree > if an environment variable is set to the location of the > untarred/unpacked/unzipped fmod SDK? This would get the last bit of > manual ugliness out of the build process on all three platforms. I > previously said I'd ping the cmake team about this, but then realized > someone on-list might already have the interest and know-how. > > I JIRAd this as https://jira.secondlife.com/browse/VWR-8393 and > imported. If I see a patch appear on jira.secondlife.com before > anything's ready internally, I'll gladly fast-track import it. The FMOD.cmake, already has the provision for this and if it cannot find the fmod libs in the prebuild location it searches under FMOD_SDK_DIR. Now the problem i have is how do i set FMOD_SDK_DIR, i can modify develop.py to add a -DFMOD_SDK_DIR:STRING= etc but i am not sure what is desired or welcome wrt modifying the develop.py. Robin From robin.cornelius at gmail.com Tue Jul 29 04:31:22 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 29 04:31:25 2008 Subject: [sldev] [VWR] cmake flags Message-ID: The previous post relating to the location of the FMOD api has got be thinking and documenting too. There are many flags than can be passed to the cmake process to control the operation and build. When invoking cmake via develop.py these are all hidden and not possible to get to. I have started listing them at http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake-flags Some of these are particularly useful for distributors on linux as it gives access to the unix makefile options. But others just may help configure things and could be of use to someone (and probably could do with listing). Now have i missed something fundamental with cmake? is it possible to invoke cmake to set one of these variables (I think they are all cached type anyway) so that i could run for example :- cmake set -DFMOD_SDK_DIR:STRING=/path/to/fmod/ and then the complete run of develop.py would then bootstrap cmake and pick up my set variables from the cache? or should develop.py have a method for passing through custom parameters to cmake? or is it assumed anyone wanting to pass custom parameters can pass all the parameters required and just will not be using develop.py anyway and the particular fmod case is unique? Also drifting off original topic slightly..... i have also been trying to update the cmake build instructions and based on the current state of the release branch i have updated https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake and i think the builds are pretty complete for windows, and close for linux, any differences for mac (mainly Prerequisites, i have not got a clue, so if some one can flesh out or merge with the windows section if approprate etc, that would be great). Robin From aimee at ama-zing.co.uk Tue Jul 29 04:47:13 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Jul 29 04:47:44 2008 Subject: [sldev] Making cmake do the fmod copy In-Reply-To: References: Message-ID: <2DAEC3F5-E4F1-4BAE-B8A2-D05FE07C7B82@ama-zing.co.uk> On Jul 29, 2008, at 10:47, Robin Cornelius wrote: > The FMOD.cmake, already has the provision for this and if it cannot > find the fmod libs in the prebuild location it searches under > FMOD_SDK_DIR. viewer_manifest.py won't copy it from the right location though on Window and Linux, on OS X it will need an additional step to build the fat library. Aimee. From bill.hoffman at kitware.com Tue Jul 29 06:53:55 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Jul 29 06:54:49 2008 Subject: [sldev] CMake library depend tracking Message-ID: <488F20F3.7020001@kitware.com> In debugging one of the issues with cmake 2.6.1 I found that the Second Life CMakeLists.txt files are not handling library dependencies correctly. CMake has the ability to keep track of libraries that depend on other libraries. However, you have to tell CMake what each library depends on for this to work. For example, if you create a library A that links to libcurl.a you should do something like this: include(FindCURL) add_library(A ...) target_link_libraries(A ${CURL_LIBRARIES}) The idea is that any library that is "directly" used by A, should be linked into A, in the correct order. Then if any other target links to A, it will know to link in A and all of its dependent libraries. Now when any other executable or library links to A, it will automatically get the curl library. For example: add_executable(B ...) target_link_libraries(B A) # the link line for B will have A and curl in that order. In Second Life, variables are being used to list dependent libraries. For example, the current SL CMakeLists have this: set(LLMESSAGE_LIBRARIES llmessage ${CURL_LIBRARIES} ${CARES_LIBRARIES} ${OPENSSL_LIBRARIES} ${CRYPTO_LIBRARIES} ${XMLRPCEPI_LIBRARIES} ) And any target that links to llmessage will do something like this: target_link_libraries(linux-crash-logger ${LLCRASHLOGGER_LIBRARIES} ${LLVFS_LIBRARIES} ${LLXML_LIBRARIES} ${LLMESSAGE_LIBRARIES} <<-------- ${LLVFS_LIBRARIES} ${LLMATH_LIBRARIES} ${LLCOMMON_LIBRARIES} ${UI_LIBRARIES} ${BOOST_SIGNALS_LIBRARY} ${DB_LIBRARIES} ) The right way to do that in CMake, is to tell CMake what libraries llmessage depends on. So you would have something like this: add_library (llmessage ${llmessage_SOURCE_FILES}) target_link_libraries(llmessage ${CURL_LIBRARIES} ${CARES_LIBRARIES} ${OPENSSL_LIBRARIES} ${CRYPTO_LIBRARIES} ${XMLRPCEPI_LIBRARIES}) After that is done, CMake will always make sure that those libraries are linked after llmessage. So, you would just need to do this: target_link_libraries(linux-crash-logger llmessage ...) -Bill From bos at lindenlab.com Tue Jul 29 09:19:35 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jul 29 09:20:03 2008 Subject: [sldev] CMake library depend tracking In-Reply-To: <488F20F3.7020001@kitware.com> References: <488F20F3.7020001@kitware.com> Message-ID: On Tue, Jul 29, 2008 at 6:53 AM, Bill Hoffman wrote: > In debugging one of the issues with cmake 2.6.1 I found that the Second > Life CMakeLists.txt files are not handling library dependencies correctly. Bill, thanks for pointing this out. I really appreciate your volunteering to help to such an extent with the transition to the latest version of CMake. This further emphasizes how worthwhile the switch has been for us. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080729/3d187adf/attachment.htm From DrScofield at xyzzyxyzzy.net Tue Jul 29 10:20:29 2008 From: DrScofield at xyzzyxyzzy.net (Dr Scofield) Date: Tue Jul 29 10:20:36 2008 Subject: [sldev] FYI: OpenSim GridInfo protocol Message-ID: <488F515D.7010905@xyzzyxyzzy.net> OpenSim, as of subversion 5692, has implemented a GridInfo protocol that allows a sufficiently smart client or launcher to obtain parameters such as loginuri, loginpage, helperuri but also (future use) "about grid" page URL, help page URL, create account URL, etc. and configure the client automatically: - the OpenSim wiki has more information at http://opensimulator.org/wiki/GridInfo - there's also a write-up at http://xyzzyxyzzy.net/2008/07/28/gridinfoor-client-auto-configuration/ - and there's a sample launcher script in OpenSim's share/python/matrix directory with a write up at http://xyzzyxyzzy.net/2008/07/29/making-use-of-gridinfo-a-launcher-for-the-secondlife%c2%ae-client/ cheers, dr scofield -- dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ From bos at lindenlab.com Tue Jul 29 10:53:27 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jul 29 10:53:29 2008 Subject: [sldev] Making cmake do the fmod copy In-Reply-To: References: Message-ID: On Tue, Jul 29, 2008 at 2:47 AM, Robin Cornelius wrote: > Now the problem i have is how do i set FMOD_SDK_DIR, i can modify > develop.py to add a -DFMOD_SDK_DIR:STRING= etc but i am not sure what > is desired or welcome wrt modifying the develop.py. > I don't think I've expressed this directly, but it has never been my attention to make every tweakable cmake variable available through some develop.py interface. If you need to modify this, there are two simple ways to do so: you can either pass the -D flag to develop.py's configure command, or you can run ccmake in the build directory and edit the setting there. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080729/0c321477/attachment.htm From bill.hoffman at kitware.com Tue Jul 29 11:12:10 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Jul 29 11:13:06 2008 Subject: [sldev] Making cmake do the fmod copy In-Reply-To: References: Message-ID: <488F5D7A.2030507@kitware.com> Bryan O'Sullivan wrote: > On Tue, Jul 29, 2008 at 2:47 AM, Robin Cornelius > > wrote: > > > Now the problem i have is how do i set FMOD_SDK_DIR, i can modify > develop.py to add a -DFMOD_SDK_DIR:STRING= etc but i am not sure what > is desired or welcome wrt modifying the develop.py. > > > I don't think I've expressed this directly, but it has never been my > attention to make every tweakable cmake variable available through some > develop.py interface. If you need to modify this, there are two simple > ways to do so: you can either pass the -D flag to develop.py's configure > command, or you can run ccmake in the build directory and edit the > setting there. > Or when we have cmake2.6 working, you can run cmake-gui, or on windows you can run CMakeSetup. cmake-gui is a Qt based interface to the cmake cache which is quite nice. -Bill From robin.cornelius at gmail.com Tue Jul 29 11:31:00 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 29 11:31:07 2008 Subject: [sldev] Making cmake do the fmod copy In-Reply-To: References: Message-ID: <488F61E4.6000109@gmail.com> Bryan O'Sullivan wrote: > On Tue, Jul 29, 2008 at 2:47 AM, Robin Cornelius > > wrote: > > > Now the problem i have is how do i set FMOD_SDK_DIR, i can modify > develop.py to add a -DFMOD_SDK_DIR:STRING= etc but i am not sure what > is desired or welcome wrt modifying the develop.py. > > > I don't think I've expressed this directly, but it has never been my > attention to make every tweakable cmake variable available through some > develop.py interface. If you need to modify this, there are two simple > ways to do so: you can either pass the -D flag to develop.py's configure > command, or you can run ccmake in the build directory and edit the > setting there. Hi Bryan, I did have the impression that adding more flags etc into develop.py was probably not what was wanted, which is why i asked. I was unaware of the ability to pass the -D flags via the configure command, that for sure is useful enough for any custom builds. I though that there probably was a way of setting the flags, but i had clearly missed this. I should add that to the wiki with my other cmake notes. Thanks Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080729/7ae649dd/signature.pgp From monkowsk at watson.ibm.com Wed Jul 30 06:03:32 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jul 30 06:04:27 2008 Subject: [sldev] SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp In-Reply-To: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> References: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> Message-ID: <489066A4.2090405@watson.ibm.com> Marine, I get the same behavior. Your analysis is pretty close. It crashes in eventIn.getStringValue2() because that value is not set in the event passed by LLEmbeddedBrowserWindowEmitter::update(), which is in llmozlib2-vc80 in my case, since I'm using VS2005. eventIn.getStringValue() has the target URL, so the event has been initialized, but the particular field associated with getStringValue2 has not. I could trace this deeper inside llmozlib2-vc80, but my guess is that it's just an outdated version of the library that's being distributed. This has happened before. The official release uses llmozlib2 since VS2003 is still the official build platform. I would predict that those who build with VS2003 do not get the crash. So add this to the JIRA issue if you've opened one. If you haven't, now would be a good time. :-) Mike Marine Kelley wrote: > Hello all, > > For hours now I've been hunting a crash that occurs when clicking on a > link on the login page. Other crashes in the same flavor are occurring > in-world when using the All tab of the Search window (especially when > clicking on Page 2 or so, but that's another story I think). Thinking it > may come from my own code after patching, I've spent time trying to > figure it out, to no avail. > > Just tried the freshly-compiled-after-downloading-source from the > "source downloads" page, and having the same crash. No change made to > that code whatsoever. It seems to come from this method : > > void LLMediaImplLLMozLib::onClickLinkHref( const EventType& eventIn ) > { > LLMediaEvent event( this, eventIn.getStringValue(), > eventIn.getStringValue2() ); > mEventEmitter.update( &LLMediaObserver::onClickLinkHref, event ); > } > > where eventIn seems to be uninitialized, leading to a null pointer > evaluation. > > The same action does work perfectly in the binary downloaded from the SL > download page. So I wonder where the difference is coming from. > > Anyone has an idea and/or experienced this too ? > > Thanks ! > > Marine From marinekelley at gmail.com Wed Jul 30 08:56:27 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Wed Jul 30 08:56:31 2008 Subject: [sldev] SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp In-Reply-To: <489066A4.2090405@watson.ibm.com> References: <9e52a8c10807270823y64497847tae51e42c518b3015@mail.gmail.com> <489066A4.2090405@watson.ibm.com> Message-ID: <9e52a8c10807300856w6149ef72ye07d63b9b8499e34@mail.gmail.com> hi Mike and Michael (to whom I answered directly without sending to the list, my bad again), That makes it clearer now, since a friend of mine compiled a viewer without any custom code, on windows, and didn't crash. I know she's using VS2003. I followed your advice and introduced VWR-8428, and took the liberty of pasting your answer there as well. Thanks a lot for your help, it seems we are getting somewhere :) Marine 2008/7/30 Mike Monkowski > Marine, > I get the same behavior. Your analysis is pretty close. It crashes in > eventIn.getStringValue2() because that value is not set in the event passed > by > LLEmbeddedBrowserWindowEmitter::update(), > which is in llmozlib2-vc80 in my case, since I'm using VS2005. > eventIn.getStringValue() has the target URL, so the event has been > initialized, but the particular field associated with getStringValue2 has > not. > > I could trace this deeper inside llmozlib2-vc80, but my guess is that it's > just an outdated version of the library that's being distributed. This has > happened before. The official release uses llmozlib2 since VS2003 is still > the official build platform. I would predict that those who build with > VS2003 do not get the crash. > > So add this to the JIRA issue if you've opened one. If you haven't, now > would be a good time. :-) > > Mike > > > > Marine Kelley wrote: > >> Hello all, >> >> For hours now I've been hunting a crash that occurs when clicking on a >> link on the login page. Other crashes in the same flavor are occurring >> in-world when using the All tab of the Search window (especially when >> clicking on Page 2 or so, but that's another story I think). Thinking it may >> come from my own code after patching, I've spent time trying to figure it >> out, to no avail. >> >> Just tried the freshly-compiled-after-downloading-source from the "source >> downloads" page, and having the same crash. No change made to that code >> whatsoever. It seems to come from this method : >> >> void LLMediaImplLLMozLib::onClickLinkHref( const EventType& eventIn ) >> { >> LLMediaEvent event( this, eventIn.getStringValue(), >> eventIn.getStringValue2() ); >> mEventEmitter.update( &LLMediaObserver::onClickLinkHref, event ); >> } >> >> where eventIn seems to be uninitialized, leading to a null pointer >> evaluation. >> >> The same action does work perfectly in the binary downloaded from the SL >> download page. So I wonder where the difference is coming from. >> >> Anyone has an idea and/or experienced this too ? >> >> Thanks ! >> >> Marine >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080730/b1b9b32b/attachment.htm From robla at lindenlab.com Wed Jul 30 10:03:04 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jul 30 10:03:26 2008 Subject: [sldev] Second Life Dashboard In-Reply-To: <488DE8BB.2030201@kitware.com> References: <488DE8BB.2030201@kitware.com> Message-ID: <48909EC8.6050409@lindenlab.com> Hi Bill, There's been a little chatter on our internal mailing list on this subject. Since I'm not personally in a position to write test cases, I shouldn't be the one to say "yes, do this", but I've at least got it on the radar of our build tools team. Rob On 7/28/08 8:41 AM, Bill Hoffman wrote: > What would be neat is if you folks would setup a CDash dashboard for > this stuff: www.cdash.org. I could create one for Second Life if > you folks would use it. I could also help folks setup client build > machines to submit to the dashboard. It would be neat if at least one > build for each of your major architectures were to track CVS CMake. > That way the CMake team would know right away when we break your > stuff. :) > > Would you be interested in having a SecondLife dashboard hosted here: > www.cdash.org/CDash? > > The clients run ctest scripts something like this: > http://www.cdash.org/CDash/viewNotes.php?buildid=131088 > > You would put that in a cronjob or schedule task, and run it once a > night. > > > -Bill > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tateru.nino at gmail.com Wed Jul 30 10:16:46 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 30 10:18:32 2008 Subject: [sldev] FYI: OpenSim GridInfo protocol In-Reply-To: <488F515D.7010905@xyzzyxyzzy.net> References: <488F515D.7010905@xyzzyxyzzy.net> Message-ID: <4890A1FE.4050501@weblogsinc.com> I'll have to add that into my launcher. Looks nicely straightforward. Dr Scofield wrote: > OpenSim, as of subversion 5692, has implemented a GridInfo protocol > that allows a sufficiently smart client or launcher to obtain > parameters such as loginuri, loginpage, helperuri but also (future > use) "about grid" page URL, help page URL, create account URL, etc. > and configure the client automatically: > > - the OpenSim wiki has more information at > http://opensimulator.org/wiki/GridInfo > > - there's also a write-up at > http://xyzzyxyzzy.net/2008/07/28/gridinfoor-client-auto-configuration/ > > - and there's a sample launcher script in OpenSim's > share/python/matrix directory with a write up at > > http://xyzzyxyzzy.net/2008/07/29/making-use-of-gridinfo-a-launcher-for-the-secondlife%c2%ae-client/ > > > cheers, > dr scofield > -- Tateru Nino http://www.massively.com/ From bill.hoffman at kitware.com Wed Jul 30 10:19:46 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Jul 30 10:20:44 2008 Subject: [sldev] Second Life Dashboard In-Reply-To: <48909EC8.6050409@lindenlab.com> References: <488DE8BB.2030201@kitware.com> <48909EC8.6050409@lindenlab.com> Message-ID: <4890A2B2.4000907@kitware.com> Rob Lanphier wrote: > Hi Bill, > > There's been a little chatter on our internal mailing list on this > subject. Since I'm not personally in a position to write test cases, I > shouldn't be the one to say "yes, do this", but I've at least got it on > the radar of our build tools team. > You don't even need test cases to get started. The first order of business would be to make sure it builds. My main concern is that it keeps building with CVS CMake, so that we don't break your stuff with the next release of CMake. For you folks it would be a good way to make sure the cross platform build continues to build everywhere. -Bill From bill.hoffman at kitware.com Wed Jul 30 14:12:38 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Jul 30 14:13:37 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <64D83770-AFA5-4BD4-8E30-B257ECD125E8@ama-zing.co.uk> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> <488DF973.3030001@kitware.com> <64D83770-AFA5-4BD4-8E30-B257ECD125E8@ama-zing.co.uk> Message-ID: <4890D946.2070700@kitware.com> Aimee Walton wrote: > /bin/rm -f > /Users/aimee/Documents/Second-Life/Source/release-clean/indra/build-darwin-i386/newview/RelWithDebInfo/Second\ > Life.app/Contents/MacOS/Second\ Life > > OK, I have a new RC out, RC 15. It can be found here: http://www.cmake.org/files/v2.6/ Quick links here: http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-15-win32-x86.exe http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-15-Linux-i386.tar.gz http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-15-Darwin-universal.dmg http://www.cmake.org/files/v2.6/cmake-2.6.1-RC-15-Darwin-universal.tar.gz This should fix the Xcode issue, and the link issue that Carsten had on linux with standalone, and the visual studio stuff should still be fixed. If you folks could test this I would appreciate it. If all that works we should be ready for 2.6.1 and it should support building Second Life. :) Thanks. -Bill From carjay at gmx.net Wed Jul 30 16:03:07 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed Jul 30 16:03:14 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <4890D946.2070700@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> <488DF973.3030001@kitware.com> <64D83770-AFA5-4BD4-8E30-B257ECD125E8@ama-zing.co.uk> <4890D946.2070700@kitware.com> Message-ID: <4890F32B.2000606@gmx.net> Bill Hoffman wrote: > This should fix the Xcode issue, and the link issue that Carsten had > on linux with standalone, and the visual studio stuff should still be > fixed. If you folks could test this I would appreciate it. If all > that works we should be ready for 2.6.1 and it should support building > Second Life. :) Yeah, linking works now without the patch (both linux-crash-logger and the final executable). Thanks for the hard work! Carsten From tao.takashi at googlemail.com Wed Jul 30 16:09:41 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Wed Jul 30 16:09:44 2008 Subject: [sldev] Second Life Dashboard In-Reply-To: <4890A2B2.4000907@kitware.com> References: <488DE8BB.2030201@kitware.com> <48909EC8.6050409@lindenlab.com> <4890A2B2.4000907@kitware.com> Message-ID: <23bbb49e0807301609m6f459438ide6129fffaa224c7@mail.gmail.com> I would be very happy if there would be some nightly builds available or so, esp. after I didn't get it to compile on Mac or Windows myself.. -- Tao On Wed, Jul 30, 2008 at 7:19 PM, Bill Hoffman wrote: > Rob Lanphier wrote: >> >> Hi Bill, >> >> There's been a little chatter on our internal mailing list on this >> subject. Since I'm not personally in a position to write test cases, I >> shouldn't be the one to say "yes, do this", but I've at least got it on the >> radar of our build tools team. >> > > You don't even need test cases to get started. The first order of business > would be to make sure it builds. My main concern is that it keeps building > with CVS CMake, so that we don't break your stuff with the next release of > CMake. For you folks it would be a good way to make sure the cross platform > build continues to build everywhere. > > -Bill > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From aimee at ama-zing.co.uk Wed Jul 30 17:24:03 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Jul 30 17:24:39 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <4890D946.2070700@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> <488DF973.3030001@kitware.com> <64D83770-AFA5-4BD4-8E30-B257ECD125E8@ama-zing.co.uk> <4890D946.2070700@kitware.com> Message-ID: <3F4F7E02-86A5-469C-BA83-CB247373C3F6@ama-zing.co.uk> On Jul 30, 2008, at 22:12, Bill Hoffman wrote: > Aimee Walton wrote: > >> /bin/rm -f /Users/aimee/Documents/Second-Life/Source/release-clean/ >> indra/build-darwin-i386/newview/RelWithDebInfo/Second\ Life.app/ >> Contents/MacOS/Second\ Life > > OK, I have a new RC out, RC 15. > This should fix the Xcode issue, and the link issue that Carsten > had on linux with standalone, and the visual studio stuff should > still be fixed. If you folks could test this I would appreciate > it. If all that works we should be ready for 2.6.1 and it should > support building Second Life. :) That's working fine with Xcode :) Thanks! Aimee. From boy.lane at yahoo.com Wed Jul 30 18:29:43 2008 From: boy.lane at yahoo.com (Boy Lane) Date: Wed Jul 30 18:29:46 2008 Subject: [sldev] Re: SL viewer 1.20.15 crashing in llmediaimplllmozlib.cpp Message-ID: <138058.28610.qm@web63801.mail.re1.yahoo.com> > This has happened before. The official release uses llmozlib2 since > VS2003 is still the official build platform. I would predict that those > who build with VS2003 do not get the crash. Yes, I can confirm this. I built the Cool Viewer, including Marines RLV patches, with the old VS and it doesn't crash. Similar reports from Mo Noel who built RLV for Mac and also doesn't have crashes. Seems indeed to be compiler related. Boy From thordain at thordain.com Wed Jul 30 20:57:20 2008 From: thordain at thordain.com (Thordain Curtis) Date: Wed Jul 30 20:57:23 2008 Subject: [sldev] Physical Object Prim Limitation Message-ID: As anyone who's tried to develop a vehicle well knows, the 32 prim limit (31 prim if you're planning on letting somebody sit on it) limitation for physical objects can be a bit of an irritation. The limit is hit pretty quickly when trying to create anything that actually looks compelling and realistic. Vehicles supporting more than one passenger are left w/ an even smaller prim limit. Add in particle emitters for special effects and you run out of prims _really_ fast. The 32 prim limit is a good thing, IMHO. Nobody wants physical objects floating around their sim composed of 256 cut tori colliding with things all the time (Well, I can't think of anyone who would want that, anyways). The limit is an effective limitation on how much havok (pun intended) a single object can inflict upon a simulator. That still leaves people trying to create compelling physical content in an undesirable position. An interesting solution would be to allow all linksets to become physical, but only use the first 32 prims as the actual collision model. The designer will generally be able to flesh out the basic shape of the object in 32 prims or less....everything else is usually just decoration. Add in a function like llSetObjectCollisionPrimCount() and physical objects could have even _less_ impact on a sim when designed properly. A car, for instance, could use the 4 wheels plus an arbitrary (invisible) box for the collision model, bringing the objects physical complexity down to a mere 5 prims. The designer now has up to 251 prims (depending on the amount of desired passengers) to add detail to their vehicle, and the simulator is even happier than it was before with a 32 prim car. This solution is also backwards compatible with all existsing physical link sets, and would require zero scripting changes. Designers who wished to make their vehicles more collision "friendly" could do so, but all existing content should continue to work unmodified. Anybody have any thoughts on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080730/38dcd6d5/attachment.htm From soft at lindenlab.com Wed Jul 30 21:15:50 2008 From: soft at lindenlab.com (Soft) Date: Wed Jul 30 21:15:53 2008 Subject: [sldev] Physical Object Prim Limitation In-Reply-To: References: Message-ID: On Wed, Jul 30, 2008 at 10:57 PM, Thordain Curtis wrote: > As anyone who's tried to develop a vehicle well knows, the 32 prim limit (31 > prim if you're planning on letting somebody sit on it) limitation for > physical objects can be a bit of an irritation. The limit is hit pretty > quickly when trying to create anything that actually looks compelling and > realistic. Vehicles supporting more than one passenger are left w/ an even > smaller prim limit. Add in particle emitters for special effects and you > run out of prims _really_ fast. > > The 32 prim limit is a good thing, IMHO. Nobody wants physical objects > floating around their sim composed of 256 cut tori colliding with things all > the time (Well, I can't think of anyone who would want that, anyways). The > limit is an effective limitation on how much havok (pun intended) a single > object can inflict upon a simulator. That still leaves people trying to > create compelling physical content in an undesirable position. > > An interesting solution would be to allow all linksets to become physical, > but only use the first 32 prims as the actual collision model. The designer > will generally be able to flesh out the basic shape of the object in 32 > prims or less....everything else is usually just decoration. Add in a > function like llSetObjectCollisionPrimCount() and physical objects could > have even _less_ impact on a sim when designed properly. A car, for > instance, could use the 4 wheels plus an arbitrary (invisible) box for the > collision model, bringing the objects physical complexity down to a mere 5 > prims. The designer now has up to 251 prims (depending on the amount of > desired passengers) to add detail to their vehicle, and the simulator is > even happier than it was before with a 32 prim car. > > This solution is also backwards compatible with all existsing physical link > sets, and would require zero scripting changes. Designers who wished to > make their vehicles more collision "friendly" could do so, but all existing > content should continue to work unmodified. > > Anybody have any thoughts on this? That, or something like it sounds pretty cool. A lot of more complicated vehicles come with part as an attachment the rider wears, which accomplishes much the same thing, but in a more roundabout way. It might also be useful if seated avatars worked as phantom objects as well. This way vehicles wouldn't stop when too many people sit on them. Given that avatars register as prims on the end of link sets, it could ease implementation as well. A good way to go forward would be to write up a JIRA proposing this and to drum up votes. You might also try stopping by the havok office hours if those are still running. There's a list of all the active office hours in the wiki. From dahliatrimble at gmail.com Wed Jul 30 21:16:21 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Jul 30 21:16:26 2008 Subject: [sldev] Physical Object Prim Limitation In-Reply-To: References: Message-ID: How about allowing phantom and non-phantom prims to coexist in the same link set, and only have the 32 prim limit apply to non-phantom prims and avatars? Or better yet, have the avatar proxy become phantom so it wouldn't count either? I have no idea how difficult this would be to implement, but there seems to be some precidence for phantom and non-phantom prims to share a linkset when flexible and non-flexible are linked together, assuming flexible and phantom are processed the same way for physics. On Wed, Jul 30, 2008 at 8:57 PM, Thordain Curtis wrote: > As anyone who's tried to develop a vehicle well knows, the 32 prim limit > (31 prim if you're planning on letting somebody sit on it) limitation for > physical objects can be a bit of an irritation. The limit is hit pretty > quickly when trying to create anything that actually looks compelling and > realistic. Vehicles supporting more than one passenger are left w/ an even > smaller prim limit. Add in particle emitters for special effects and you > run out of prims _really_ fast. > > The 32 prim limit is a good thing, IMHO. Nobody wants physical objects > floating around their sim composed of 256 cut tori colliding with things all > the time (Well, I can't think of anyone who would want that, anyways). The > limit is an effective limitation on how much havok (pun intended) a single > object can inflict upon a simulator. That still leaves people trying to > create compelling physical content in an undesirable position. > > An interesting solution would be to allow all linksets to become physical, > but only use the first 32 prims as the actual collision model. The designer > will generally be able to flesh out the basic shape of the object in 32 > prims or less....everything else is usually just decoration. Add in a > function like llSetObjectCollisionPrimCount() and physical objects could > have even _less_ impact on a sim when designed properly. A car, for > instance, could use the 4 wheels plus an arbitrary (invisible) box for the > collision model, bringing the objects physical complexity down to a mere 5 > prims. The designer now has up to 251 prims (depending on the amount of > desired passengers) to add detail to their vehicle, and the simulator is > even happier than it was before with a 32 prim car. > > This solution is also backwards compatible with all existsing physical link > sets, and would require zero scripting changes. Designers who wished to > make their vehicles more collision "friendly" could do so, but all existing > content should continue to work unmodified. > > Anybody have any thoughts on this? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080730/a6092586/attachment-0001.htm From sammy.frederix at gmail.com Wed Jul 30 20:25:45 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Wed Jul 30 21:35:41 2008 Subject: SV: [sldev] Re: CMake 2.4.8 vs 2.6 (Re: Missing cares, apr inMac build) In-Reply-To: <4890D946.2070700@kitware.com> References: <4880D832.6070205@lindenlab.com> <4880ED55.3010705@kitware.com> <48848D24.7060909@kitware.com> <488631A9.2030404@kitware.com> <48893302.50306@kitware.com> <488A99A9.7010802@kitware.com> <488B4608.6020801@kitware.com> <105BFC07-07FB-4712-B9EE-B43124ED4F02@gmail.com> <488DF973.3030001@kitware.com> <64D83770-AFA5-4BD4-8E30-B257ECD125E8@ama-zing.co.uk> <4890D946.2070700@kitware.com> Message-ID: <80994DE4-58B0-4692-862E-A620B1F5D2BE@gmail.com> On 31/07/2008, at 7:12 AM, Bill Hoffman wrote: >> /bin/rm -f /Users/aimee/Documents/Second-Life/Source/release-clean/ >> indra/build-darwin-i386/newview/RelWithDebInfo/Second\ Life.app/ >> Contents/MacOS/Second\ Life > > OK, I have a new RC out, RC 15. It can be found here: > > This should fix the Xcode issue, and the link issue that Carsten had > on linux with standalone, and the visual studio stuff should still > be fixed. If you folks could test this I would appreciate it. If > all that works we should be ready for 2.6.1 and it should support > building Second Life. :) It seems to work for Xcode 3.1 too. Thanks for your help, Bill. From sammy.frederix at gmail.com Wed Jul 30 20:31:58 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Wed Jul 30 21:35:47 2008 Subject: [sldev] OSX release branch not installing AutoUpdater.app and crashreporter.app Message-ID: Hi all, Using Xcode 3.1, building the release branch doesn't add AutoUpdater.app and crashreporter.app to Second Life.app. This happens with both cmake 2.4.8 and cmake 2.6.1 RC 15. I'm not sure if it's a cmake bug or a source problem. Is anyone else seeing this under other versions of Xcode, or even 3.1? Sammy From robin.cornelius at gmail.com Thu Jul 31 03:55:26 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Jul 31 03:55:30 2008 Subject: [sldev] [VWR] Heap checkers Message-ID: Following on from last thursdays meeting (Rob's Hours), an action point to ping sldev with this was raised, so here goes. We currently know there is some memory/heap corruption occurring with in the viewer, I for one see this as random crashes which can often include new() or malloc() operators crashing or double free errors. I also know that the corruption is difficult to track down and the end results depend on the compiler used, the arch 32/64 bit etc and are all related to the padding at the start/end of a allocated heap block and the arch alignment and also what happens to be next in memory. 2 such issues have been identified so far but this was done the hard way:- Issue 1) The abstracted gl system (llrender.cpp) has two function calls that can and do over run the array. LLRender::color4ub() and LLRender::texCoord2f() both can write to element 4096 of a 4096 element array, LLRender::vertex3f() causes the issue by setting the array index to 4096, but protects itself from this (and typically all 3 are called as a group). Big thanks to Carjay for that one . This issue is triggered for tortured prims and sculpties but due to memory alignment etc does not seem to cause much problems on i386 but can be critical to the GL context on 64 bit builds. Issue 2) creating 2 XUI input events, For instance managing to click the "Teleport" button twice can cause the xui event to be triggered twice. Two do so takes a broken mouse (yay mine does this from time to time) which generates 2 very close click events. or hitting enter and clicking Teleport at the same time. Despite this being an obvious attempt to break something there is an uncaught use of a freeed memory block in the teleport code as the xui handler passes a pointer (by value) to an asset which is used to make a message then freeed. Teh 2nd entry uses the same pointer (which now points to a free memory location) and tries to run the code again. Strangely this causes a crash not there but on the next new() or malloc() operator as the memory allocation code barfs up due to heap corruption. The point here is that a good heap checking utility could catch these, so we started a discussion of possible utilites that may be of use last week and thinks like duma,tcmalloc,valgrind to name a few linux ones of the top of my head. I also found that there is a windows heap utility that can be enabled with the gflags tool on a per process basis. So the questions remain, any other good utilities that people know of, even platform dependent ones?, as 98% of the code is common anyway so an error caught somewhere is probably effecting more that one system. The issues with the utilities are run time speed, the really through checkers which put pages boundaries between allocs are very very slow and use lots and lots of memory. I have not so far been able to get duma to even get to the viewer logon screen. tcmalloc runs with out heapcheck but with heap check gtk threads barfs and the viewer will not start. The other issue is that if the run time speed IS that bad the viewer will never hold a connection to the server and getting fully in world is really a requirement, any ideas here on how to resolve this? the Microsoft heap checker has so far not caught anything, including case study 1 above and also fails to get in/stay in world (due to viewer execution speed) 4/5 times. tcmalloc's heap monitor does produce some interesting info that could help catch memory leaks or profile the viewers memory usage, see output at http://www.byteme.org.uk/heap/ Regards Robin From aimee at ama-zing.co.uk Thu Jul 31 04:26:55 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Jul 31 04:27:32 2008 Subject: [sldev] OSX release branch not installing AutoUpdater.app and crashreporter.app In-Reply-To: References: Message-ID: On Jul 31, 2008, at 04:31, Sammy Frederix wrote: > Hi all, > Using Xcode 3.1, building the release branch doesn't add > AutoUpdater.app and crashreporter.app to Second Life.app. This > happens with both cmake 2.4.8 and cmake 2.6.1 RC 15. I'm not sure > if it's a cmake bug or a source problem. Without checking, I'd say that's probably by design for open source builds. Crash reports from modified viewers would be unreliable information (I know I've caused plenty of my own crashes working on stuff :) and I would assume most people wouldn't want their own modified build auto-updated to the latest official release. They only really become relevant for an open source build for people redistributing their own version wanting to use them to send crash reports back to themself and do updates from their own server, which is a minority at the moment? Regards. Aimee. From aimee at ama-zing.co.uk Thu Jul 31 05:17:25 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Jul 31 05:17:58 2008 Subject: [sldev] Physical Object Prim Limitation In-Reply-To: References: Message-ID: On Jul 31, 2008, at 05:16, Dahlia Trimble wrote: > How about allowing phantom and non-phantom prims to coexist in the > same link set, and only have the 32 prim limit apply to non-phantom > prims and avatars? Or better yet, have the avatar proxy become > phantom so it wouldn't count either? I have no idea how difficult > this would be to implement, but there seems to be some precidence > for phantom and non-phantom prims to share a linkset when flexible > and non-flexible are linked together, assuming flexible and phantom > are processed the same way for physics. That was my first thought too, allowing phantom and non-phantom prims to be linked would also solve other problems, such as making buildings easier to package when they contain phantom parts. How many times have you walked solid into a curtain or flower prim linked to a building? :) On Jul 31, 2008, at 05:15, Soft wrote: > It might also be useful if seated avatars worked as phantom objects as > well. This way vehicles wouldn't stop when too many people sit on > them. Given that avatars register as prims on the end of link sets, it > could ease implementation as well. Need to be careful about making avatars phantom though, stopping that was previously a hotly debated deliberate change back in 2005, there's lots of old discussion on it. http://forums.secondlife.com/showthread.php?t=29561 http://forums.secondlife.com/showthread.php?t=58338 http://jira.secondlife.com/browse/SVC-264 Although a lot has changed since then. Andrew Linden suggests in one of those posts sitting on a non-physical prim to move through stuff was considered a bug to be fixed then, while 'fixing' it now would break just about every teleporter in SL. Aimee. From tofu.linden at lindenlab.com Thu Jul 31 05:18:57 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Jul 31 05:18:40 2008 Subject: [sldev] OSX release branch not installing AutoUpdater.app andcrashreporter.app In-Reply-To: References: Message-ID: <4891ADB1.8080304@lindenlab.com> If I remember correctly, this is a genuine bug and the fix should be hitting the release branch after some QA is finished, which is in progress as we speak. maint-viewer should have the fix already; perhaps you could try that branch and let us know if it helps. Thanks for noticing! Sammy Frederix wrote: > Hi all, > Using Xcode 3.1, building the release branch doesn't add AutoUpdater.app > and crashreporter.app to Second Life.app. This happens with both cmake > 2.4.8 and cmake 2.6.1 RC 15. I'm not sure if it's a cmake bug or a > source problem. > > Is anyone else seeing this under other versions of Xcode, or even 3.1? > > Sammy From secret.argent at gmail.com Thu Jul 31 05:38:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jul 31 05:38:08 2008 Subject: [sldev] Physical Object Prim Limitation In-Reply-To: References: Message-ID: <7F67ABB0-46B2-431C-B29E-ADFCE5326490@gmail.com> I would say it might even be reasonable to have the collision envelope be restricted to the root prim: avatars use a collision ellipsoid, and for vehicles you could do the same thing... define a collision ellipsoid in the root prim and call "llSetStatus (STATUS_PHYSICAL_SIMPLE, TRUE);". From tateru.nino at gmail.com Thu Jul 31 06:26:25 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jul 31 06:28:12 2008 Subject: [sldev] [VWR] Heap checkers In-Reply-To: References: Message-ID: <4891BD81.2040009@gmail.com> Issues like XUI events and other such asynchrony that could suffer from bei