From jan.ciger at gmail.com Sun Mar 1 12:22:57 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun Mar 1 12:23:33 2009 Subject: [sldev] Please help testing the SL Viewer with integrated universal translation In-Reply-To: <20090226004412.e2a4ddcf.sldev@free.fr> References: <49A5A054.1020001@cs.cmu.edu> <20090226004412.e2a4ddcf.sldev@free.fr> Message-ID: <49AAEEA1.6050704@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henri Beauchamp wrote: > Automatic translators are utterly useless and totally unable to translate > properly from simple languages such as English into more complex and subtle > languages such as French, German, Chinese, Japanese... > > My advice is therefore: don't bother. Most people will mute you rather > than enduring the clueless translators. Henri, this sounds very much like a French elitism to me, sorry. And that is even though English is only my second or third language (btw, je parle fran?ais aussi ...) English can be equally subtle and complex as French is, if used by a skilled speaker/writer. Translations from French to English can be equally comical. However, to the point of the translators - I have a Brazilian friend who speaks no English and I speak no Portuguese, but we can communicate quite well using one. It will certainly not do to translate Moli?re or Hemingway, but it beats not being able to communicate at all. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD4DBQFJqu6Mn11XseNj94gRAinNAKDNYnnkrpkGKgREpGpbY3xp7VhzpwCYjWaE Nko/jl+jyCIU1dqtwBSACw== =bscs -----END PGP SIGNATURE----- From open at autistici.org Mon Mar 2 10:36:34 2009 From: open at autistici.org (Opensource Obscure) Date: Mon Mar 2 10:36:36 2009 Subject: [sldev] Please help testing the SL Viewer with integrated universal translation In-Reply-To: <49A5A054.1020001@cs.cmu.edu> References: <49A5A054.1020001@cs.cmu.edu> Message-ID: <8f0176f20b035574c981ff0fb6453870@localhost> I think that a viewer with an integrated language translation function is a smart idea. As an Italian speaker, I confirm that automated translation is usually lower-than-good right now. However this can only get better in the future, so I still find it's a good path. Also: some languages are easier than others to get translated by machines. YMMV. On a different topic, I'm sorry but I couldn't give a try to this viewer because it's a Windows-only download - I'm on Linux. Also, it puzzles me a bit that two Lindens commented this proposal without inviting Joy to respect their own copyright + the GPL license on the SL viewer. If I'm not wrong, sources should be provided when you publish binaries of modified version of the SL viewer. Let me clearly state that I heartily welcome third-part viewers and I'm aware that complying with all legal and formal aspects of software publishing can be a PITA. I'm not asking at all for a Reprimand By Linden Gods :) I just think that these issues are difficult to handle and could be easily resolved with a short and polite reminder by Lindens better than other people; last time I saw this matter being handled privately, it didn't end happily: http://bit.ly/aR93 or http://nwn.blogs.com/nwn/2009/01/kirsten-quits-citing-gpl-enforcementrelated-stress-groundbreaking-open-source-developer-quits-viewer.html See also http://www.massively.com/2009/02/21/linden-lab-invites-reports-of-viewer-license-violations Jim, please note that I'm not asking you to provide a Linux build: I just hope you could share your code with the community, so that (hopefully) builds for different operating systems will be made available. I'll be glad to test your viewer and provide feedback. Ciao, Opensource Obscure -- http://twitter.com/oobscure http://friendfeed.com/oobscure http://friendfeed.com/rooms/secondlife From gigstaggart at gmail.com Mon Mar 2 10:58:56 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Mar 2 10:59:00 2009 Subject: [sldev] Please help testing the SL Viewer with integrated universal translation In-Reply-To: <8f0176f20b035574c981ff0fb6453870@localhost> References: <49A5A054.1020001@cs.cmu.edu> <8f0176f20b035574c981ff0fb6453870@localhost> Message-ID: <49AC2C70.2090802@gmail.com> Opensource Obscure wrote: > Also, it puzzles me a bit that two Lindens commented this proposal > without inviting Joy to respect their own copyright + the GPL license > on the SL viewer. If I'm not wrong, sources should be provided > when you publish binaries of modified version of the SL viewer. Rob did suggest that publishing source code would be the polite thing to do. -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/20090302/19ba08ec/smime.bin From open at autistici.org Mon Mar 2 11:09:41 2009 From: open at autistici.org (Opensource Obscure) Date: Mon Mar 2 11:09:44 2009 Subject: [sldev] Please help testing the SL Viewer with =?UTF-8?Q?integrated?= =?UTF-8?Q?=09universal=20translation?= In-Reply-To: <49AC2C70.2090802@gmail.com> References: <49A5A054.1020001@cs.cmu.edu> <8f0176f20b035574c981ff0fb6453870@localhost> <49AC2C70.2090802@gmail.com> Message-ID: <9fe843133c1ad4cae17ff321863620a8@localhost> On Mon, 02 Mar 2009 13:58:56 -0500, Jason Giglio wrote: > Opensource Obscure wrote: >> Also, it puzzles me a bit that two Lindens commented this proposal >> without inviting Joy to respect their own copyright + the GPL license >> on the SL viewer. If I'm not wrong, sources should be provided >> when you publish binaries of modified version of the SL viewer. > > Rob did suggest that publishing source code would be the polite thing to > do. Thanks Jason. That's true, I missed Rob's message https://lists.secondlife.com/pipermail/sldev/2009-February/012963.html ...please ignore everything I wrote with regard to that. Ciao, Opensource Obscure From robla at lindenlab.com Mon Mar 2 13:53:27 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Mar 2 13:53:53 2009 Subject: [sldev] Deprecated protocol feature: stray colon in 500 response Message-ID: <49AC5557.9010603@lindenlab.com> Hi folks, The current version of our server infrastructure for capabilities has a misfeature in it, where 500 responses have a stray colon in them. Capabilities are meant to be HTTP-compliant, but this stray colon is not. However, that incompatibility is required to maintain compatibility with 1.20.17 and earlier viewers (and their derivatives). Maintaining this situation is a pain, because coercing standards-based infrastructure (like Apache) to do the wrong thing is a major pain. We eventually would like to eliminate this aberration from our infrastructure, but that would mean that older viewers would stop working. We'll give you plenty of warning before actually changing this infrastructure, but we figured it's best to get the technical information out now so that this will hopefully be a moot point by the time we announce a timeline. We're asking that everyone who has a viewer based on 1.20.17 and older to either upgrade to a newer base revision of the viewer (e.g. 1.21 or later) or apply a fix as described here: https://wiki.secondlife.com/wiki/Deprecated_Protocol_Features#Deprecated_protocol_feature:__stray_colon_in_HTTP_500_responses_.28viewers_1.20.17_and_earlier.29 ...with patches attached here: https://jira.secondlife.com/browse/VWR-12248 Thanks! Rob From tigrospottystripes at gmail.com Mon Mar 2 15:17:40 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon Mar 2 15:17:50 2009 Subject: [sldev] Deprecated protocol feature: stray colon in 500 response In-Reply-To: <49AC5557.9010603@lindenlab.com> References: <49AC5557.9010603@lindenlab.com> Message-ID: <49AC6914.8050403@Gmail.com> would it be an option to have the servers talk differently based on the version of the client connecting to it? and would that help with the issues present now? (like, wouldn't this make it so newer version have to do it right while still allowing olders to do it wrong for a longer while? ) Rob Lanphier escreveu: > Hi folks, > > The current version of our server infrastructure for capabilities has a > misfeature in it, where 500 responses have a stray colon in them. > Capabilities are meant to be HTTP-compliant, but this stray colon is > not. However, that incompatibility is required to maintain > compatibility with 1.20.17 and earlier viewers (and their derivatives). > > Maintaining this situation is a pain, because coercing standards-based > infrastructure (like Apache) to do the wrong thing is a major pain. We > eventually would like to eliminate this aberration from our > infrastructure, but that would mean that older viewers would stop > working. We'll give you plenty of warning before actually changing this > infrastructure, but we figured it's best to get the technical > information out now so that this will hopefully be a moot point by the > time we announce a timeline. > > We're asking that everyone who has a viewer based on 1.20.17 and older > to either upgrade to a newer base revision of the viewer (e.g. 1.21 or > later) or apply a fix as described here: > https://wiki.secondlife.com/wiki/Deprecated_Protocol_Features#Deprecated_protocol_feature:__stray_colon_in_HTTP_500_responses_.28viewers_1.20.17_and_earlier.29 > > ...with patches attached here: > https://jira.secondlife.com/browse/VWR-12248 > > Thanks! > 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 > > From kelly at lindenlab.com Mon Mar 2 15:31:58 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Mon Mar 2 15:32:10 2009 Subject: [sldev] Deprecated protocol feature: stray colon in 500 response In-Reply-To: <49AC6914.8050403@Gmail.com> References: <49AC5557.9010603@lindenlab.com> <49AC6914.8050403@Gmail.com> Message-ID: <49AC6C6E.7030404@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090302/7220524f/attachment.htm From tigrospottystripes at gmail.com Mon Mar 2 15:37:11 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon Mar 2 15:37:23 2009 Subject: [sldev] Deprecated protocol feature: stray colon in 500 response In-Reply-To: <49AC6C6E.7030404@lindenlab.com> References: <49AC5557.9010603@lindenlab.com> <49AC6914.8050403@Gmail.com> <49AC6C6E.7030404@lindenlab.com> Message-ID: <49AC6DA7.2000500@Gmail.com> hm, I think I see, ok Kelly Linden escreveu: > Unfortunately no. What you are asking for is essentially what we > already have - both old and new viewers work because of a special > coded server. We simply can not maintain this state. > > The issue is our capabilities server used to run on a web service > platform that had a bug in it, and our old viewers relied on this > bug. We have since switched to using Apache as our platform for the > capabilities server. To support older viewers we are currently > running a slightly modified version of Apache to also have this bug. > The modified Apache is a problem though - it makes keeping up to date > difficult and complicates our future development. We must stop > maintaining this modified version of Apache and to do that we must > stop supporting these old viewers. > > - Kelly > > From lists.secondlife.com at trap.wereanimal.net Mon Mar 2 22:54:49 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com@trap.wereanimal.net) Date: Mon Mar 2 22:55:01 2009 Subject: [sldev] CURL error 60 with gnutls 2.6.4 Message-ID: <200903030154.49820.lists.secondlife.com@trap.wereanimal.net> This is just a heads up on a problem that I found. I went to log in today and got this error: WARNING: process: LLXMLRPCTransaction CURL error 60: server certificate verification failed. CAfile: /usr/share/games/secondlife/app_settings/CA.pem CRLfile: none After a couple hours tracing the problem down, it turns out that when I downgraded to gnutls 2.6.3, the error went away. gnutls was upgraded to 2.6.4 the day before. I do standalone builds on a amd64 gentoo box. -- Techwolf Lupindo From robin.cornelius at gmail.com Tue Mar 3 02:50:13 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Mar 3 02:50:18 2009 Subject: [sldev] CURL error 60 with gnutls 2.6.4 In-Reply-To: <200903030154.49820.lists.secondlife.com@trap.wereanimal.net> References: <200903030154.49820.lists.secondlife.com@trap.wereanimal.net> Message-ID: On Tue, Mar 3, 2009 at 6:54 AM, wrote: > This is just a heads up on a problem that I found. > After a couple hours tracing the problem down, it turns out that when I > downgraded to gnutls 2.6.3, the error went away. gnutls was upgraded to 2.6.4 > the day before. > Ah thanks, Someone using the omvviewer source had been having this trouble too and i was scratching my head as to why as i could not reproduce on my system because i do not use gnutls curl which leads to another point... Do you get viewer hickups and pauses from this curl configuration, We have found and verified that curl that is not linked with libc-ares and configured with --non-blocking can pause frames for up to 100s of ms whist DNS blocks. It appeared to be that the libc-ares/non-blocking was not possible when linking with gnutls and required openssl. Robin From lenglish5 at cox.net Tue Mar 3 07:02:25 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue Mar 3 07:02:28 2009 Subject: [sldev] [META][AWG] Tuesday meetings and new mmox document Message-ID: <49AD4681.20807@cox.net> Tuesday, March 3, we are having another mmox-oriented meeting at ThornBridgeTown Island in Second Life. IM Saijanai Kuhn, Tree Kyomoon or Zha Ewry in-world for the group invite to get to the meeting place. http://slurl.com/secondlife/ThorneBridgeTown/156/129/25 One topic of discussion will be: http://www.ietf.org/proceedings/staging/draft-ietf-mmox-problem-00.txt This will be followed by the monthly meeting at Zero Linden's office hours at 1PM Tuesday. Two hours are blocked out for this meeting. http://slurl.com/secondlife/Grasmere/171/112/27 A reminder: the IETF meeting will be March 24th, 3:20 -5PM Pacific Coast Time in San Francisco. We plan on having [hope to have] 2-way media and chat streaming between the live meeting and meetings in Second Life, OpenSim, Qwaq/Croquet, Forterra as well as a Metanomics style interactive webpage and irc/jabber groups linked to the local chat of each world/sim. See you there. Lawson Saijanai Kuhn in Second Life From lists.secondlife.com at trap.wereanimal.net Tue Mar 3 11:08:33 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com@trap.wereanimal.net) Date: Tue Mar 3 11:08:50 2009 Subject: [sldev] CURL error 60 with gnutls 2.6.4 In-Reply-To: References: <200903030154.49820.lists.secondlife.com@trap.wereanimal.net> Message-ID: <200903031408.33258.lists.secondlife.com@trap.wereanimal.net> On Tuesday 03 March 2009 05:50:13 am Robin Cornelius wrote: > Do you get viewer hickups and pauses from this curl configuration, We > have found and verified that curl that is not linked with libc-ares > and configured with --non-blocking can pause frames for up to 100s of > ms whist DNS blocks. It appeared to be that the libc-ares/non-blocking > was not possible when linking with gnutls and required openssl. > I remember a while back I was having DNS lookup problems on another program. After pulling my fur out for a while, turns out the problem was related to curl and c-ares. I can't remember the fix. I will do some searching and see what I can find. -- Techwolf Lupindo From colin.kern at gmail.com Tue Mar 3 12:19:39 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue Mar 3 12:21:30 2009 Subject: [sldev] Please help testing the SL Viewer with integrated universal translation In-Reply-To: <8f0176f20b035574c981ff0fb6453870@localhost> References: <49A5A054.1020001@cs.cmu.edu> <8f0176f20b035574c981ff0fb6453870@localhost> Message-ID: The GPL doesn't require the source code to be distributed with binaries, it just requires the code be available on request. So the original poster was within their rights to not include the source. However, now that you've requested it, they must deliver ;) Colin On Mar 2, 2009, at 1:36 PM, Opensource Obscure wrote: > > I think that a viewer with an integrated language translation > function is a smart idea. > > As an Italian speaker, I confirm that automated translation is > usually lower-than-good right now. However this can only > get better in the future, so I still find it's a good path. > > Also: some languages are easier than others to get translated by > machines. YMMV. > > > On a different topic, I'm sorry but I couldn't give a try to > this viewer because it's a Windows-only download - I'm on Linux. > > Also, it puzzles me a bit that two Lindens commented this proposal > without inviting Joy to respect their own copyright + the GPL license > on the SL viewer. If I'm not wrong, sources should be provided > when you publish binaries of modified version of the SL viewer. > > Let me clearly state that I heartily welcome third-part viewers > and I'm aware that complying with all legal and formal aspects > of software publishing can be a PITA. > I'm not asking at all for a Reprimand By Linden Gods :) > I just think that these issues are difficult to handle and could be > easily resolved with a short and polite reminder by Lindens better > than other people; last time I saw this matter being handled > privately, it didn't end happily: > http://bit.ly/aR93 or > http://nwn.blogs.com/nwn/2009/01/kirsten-quits-citing-gpl-enforcementrelated-stress-groundbreaking-open-source-developer-quits-viewer.html > > See also > http://www.massively.com/2009/02/21/linden-lab-invites-reports-of-viewer-license-violations > > Jim, please note that I'm not asking you to provide a Linux build: > I just hope you could share your code with the community, so that > (hopefully) builds for different operating systems will be made > available. I'll be glad to test your viewer and provide feedback. > > > Ciao, > Opensource Obscure > -- > http://twitter.com/oobscure > http://friendfeed.com/oobscure > http://friendfeed.com/rooms/secondlife > _______________________________________________ > 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 lenglish5 at cox.net Tue Mar 3 12:37:22 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue Mar 3 12:37:45 2009 Subject: [sldev] [META][AWG] Tuesday meetings and new mmox document In-Reply-To: <49AD4681.20807@cox.net> References: <49AD4681.20807@cox.net> Message-ID: <49AD9502.1000808@cox.net> Lawson English wrote: > Tuesday, March 3, we are having another mmox-oriented meeting at > ThornBridgeTown Island in Second Life. IM Saijanai Kuhn, Tree Kyomoon > or Zha Ewry in-world for the group invite to get to the meeting place. > Chat log for this morning's meeting. Don't forget to attend Zero's Office hour(s) as well: https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2009-03-03 > > This will be followed by the monthly meeting at Zero Linden's office > hours at 1PM Tuesday. Two hours are blocked out for this meeting. > > http://slurl.com/secondlife/Grasmere/171/112/27 > Lawson From rgwells at techno-logix.com Tue Mar 3 16:58:02 2009 From: rgwells at techno-logix.com (Russell G. Wells) Date: Tue Mar 3 16:58:18 2009 Subject: [sldev] [HELP] Skipping incompatible lllmozlib2 library Message-ID: <200903031658.02673.rgwells@techno-logix.com> I'm having trouble getting the linux viewer RC 1.22.10 to link. (I hope this is the right place to post this) I want to contribute to the viewer development, specifically on the linux code base. I figure this this is a dependency issues on my side, but I don't see it. The following error is being generated: Linking CXX executable secondlife-bin master: http://secondlife.com/app/message_template/master_message_template.msg current: /home/rgwells/projects/slv-1.22.10/linden/scripts/messages/message_template.msg Refreshing master cache from http://secondlife.com/app/message_template/master_message_template.msg --- PASS --- Older missing message RezRestoreToWorld, did you mean to deprecate? in message RegionHandshake: missing 1 extra blocks in message RegionInfo: missing 1 extra blocks /usr/bin/ld: skipping incompatible /home/rgwells/projects/slv-1.22.10/linden/indra/../libraries/x86_64-linux/lib_release_client/libllmozlib2.a when searching for -lllmozlib2 /usr/bin/ld: cannot find -lllmozlib2 collect2: ld returned 1 exit status make[2]: *** [newview/secondlife-bin] Error 1 make[1]: *** [newview/CMakeFiles/secondlife-bin.dir/all] Error 2 make: *** [all] Error 2 System info: ------------------- Distribution: Kubuntu 8.04 Kernel version: 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009 x86_64 GNU/Linux CPU: AMD Phenom 9850 Quad-Core @ 2.5 Ghz GPU: GeForce 9500 GT NVidia driver: 173.14.12 General compiling notes: ------------------------ I won't go into all the dependencies I needed to install compile, as I should reproduce the list on a clean install of my distribution. But here is the short list of steps I took after I installed the missing stuff. 1. unpacked the source code, linux libs, and artwork into a working directory. 2, ran the /linden/indra/develop.py to generate linux makefiles. 3. copy header files for the following elements into the /linden/libraries//include directory. cp -a /usr/include/atk-1.0 ${TARGETDIR}/include/ # linux GUI framework cp -a /usr/include/gtk-2.0 ${TARGETDIR}/include/ cp -a /usr/lib/gtk-2.0/include/* ${TARGETDIR}/include/gtk-2.0/ # general support framework cp -a /usr/include/glib-2.0 ${TARGETDIR}/include/ cp -a /usr/lib/glib-2.0/include/* ${TARGETDIR}/include/glib-2.0/ # text layout with emphasis on internationalization cp -a /usr/include/pango-1.0 ${TARGETDIR}/include/ # 2D vector graphics support cp -a /usr/include/cairo/* ${TARGETDIR}/include # IPC support cp -a /usr/include/dbus-1.0/dbus/ ${TARGETDIR}/include/ # ELF file format debugging support (Stack trace) mkdir ${TARGETDIR}/include/ELFIO cp ${ELFIO}/ELFIO/*.h ${TARGETDIR}/include/ELFIO/ cp ${ELFIO}/ELFIO/libELFIO.a ${TARGETDIR}/lib_release_client/ NOTE: This is the minimal set I needed to compile (tried lots more as suggested for older builds on the wiki). 4. ran a compile. * had to fix error in /linden/indra/newview/llappviewerlinux.cpp line 258 needed to change from fprintf(StraceFile, "%d:\t", btpos); to fprintf(StraceFile, "%lu:\t", btpos); 5. compile again * compile completes OK, but the link step generates the error listed above. Other thoughts: -------------------- I saw in aan old post, that version FL-1.13.3.58185 would not compile on linux unless LL_LIBXUL_ENABLED was defined to 0. Is this still true? I tried it, but still got the link error. Russell G. Wells From rgwells at techno-logix.com Tue Mar 3 17:23:22 2009 From: rgwells at techno-logix.com (Russell G. Wells) Date: Tue Mar 3 17:23:40 2009 Subject: [sldev] [HELP] Skipping incompatible lllmozlib2 library In-Reply-To: <200903031658.02673.rgwells@techno-logix.com> References: <200903031658.02673.rgwells@techno-logix.com> Message-ID: <200903031723.22764.rgwells@techno-logix.com> As a follow up, i checked the installed.xml file generated by the develop python script. It showed that the llmozlib was retrieved from http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/llmozlib-linux64-20080909.tar.bz2 That lok right to me. Russell From khyota at redhyena.net Tue Mar 3 18:54:48 2009 From: khyota at redhyena.net (Khyota) Date: Tue Mar 3 18:54:54 2009 Subject: [sldev] [HELP] Skipping incompatible lllmozlib2 library In-Reply-To: <200903031658.02673.rgwells@techno-logix.com> References: <200903031658.02673.rgwells@techno-logix.com> Message-ID: <200903032154.49201.khyota@redhyena.net> On Tuesday 03 March 2009 7:58:02 Russell G. Wells wrote: > General compiling notes: > ------------------------ > > I won't go into all the dependencies I needed to install compile, as I > should reproduce the list on a clean install of my distribution. But here > is the short list of steps I took after I installed the missing stuff. > > 1. unpacked the source code, linux libs, and artwork into a working > directory. > > 2, ran the /linden/indra/develop.py to generate linux makefiles. > > 3. copy header files for the following elements into the > /linden/libraries//include directory. > > cp -a /usr/include/atk-1.0 ${TARGETDIR}/include/ > > # linux GUI framework > cp -a /usr/include/gtk-2.0 ${TARGETDIR}/include/ > cp -a /usr/lib/gtk-2.0/include/* ${TARGETDIR}/include/gtk-2.0/ > > # general support framework > cp -a /usr/include/glib-2.0 ${TARGETDIR}/include/ > cp -a /usr/lib/glib-2.0/include/* ${TARGETDIR}/include/glib-2.0/ > > # text layout with emphasis on internationalization > cp -a /usr/include/pango-1.0 ${TARGETDIR}/include/ > > # 2D vector graphics support > cp -a /usr/include/cairo/* ${TARGETDIR}/include > > # IPC support > cp -a /usr/include/dbus-1.0/dbus/ ${TARGETDIR}/include/ > > # ELF file format debugging support (Stack trace) > mkdir ${TARGETDIR}/include/ELFIO > cp ${ELFIO}/ELFIO/*.h ${TARGETDIR}/include/ELFIO/ > cp ${ELFIO}/ELFIO/libELFIO.a ${TARGETDIR}/lib_release_client/ > > NOTE: This is the minimal set I needed to compile (tried lots more as > suggested for older builds on the wiki). > > > 4. ran a compile. > * had to fix error in /linden/indra/newview/llappviewerlinux.cpp > line 258 needed to change from > > fprintf(StraceFile, "%d:\t", btpos); > > to > fprintf(StraceFile, "%lu:\t", btpos); > > > 5. compile again > * compile completes OK, but the link step generates the error listed above. > > Other thoughts: > -------------------- > > I saw in aan old post, that version FL-1.13.3.58185 would not compile on > linux unless LL_LIBXUL_ENABLED was defined to 0. Is this still true? > I tried it, but still got the link error. > > Russell G. Wells > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges It looks like your trying to compile non-standalone which isnt supported on x86_64 yet, most of the libs are missing, run develop.py configure with --standalone to get it to use your system libs. The libraries/ directory is not used during standalone builds. > The following error is being generated: > > Linking CXX executable secondlife-bin > master: > http://secondlife.com/app/message_template/master_message_template.msg > current: > /home/rgwells/projects/slv-1.22.10/linden/scripts/messages/message_template >.msg Refreshing master cache from > http://secondlife.com/app/message_template/master_message_template.msg > --- PASS --- > Older > missing message RezRestoreToWorld, did you mean to deprecate? > in message RegionHandshake: missing 1 extra blocks > in message RegionInfo: missing 1 extra blocks > > /usr/bin/ld: skipping > incompatible > /home/rgwells/projects/slv-1.22.10/linden/indra/../libraries/x86_64-linux/l >ib_release_client/libllmozlib2.a when searching for -lllmozlib2 > /usr/bin/ld: cannot find -lllmozlib2 > collect2: ld returned 1 exit status > make[2]: *** [newview/secondlife-bin] Error 1 > make[1]: *** [newview/CMakeFiles/secondlife-bin.dir/all] Error 2 > make: *** [all] Error 2 I usualy see this error when a library is actually compiled for i686 rather then x86_64 but i dont know how to find out if thats true. You can turn llmozlib off by adding to the -DMOZLIB:BOOL=FALSE to the develop.py configure line, download the source and compile it yourself, or grab the ubuntu package from Terrex's repository http://omvviewer.byteme.org.uk/ubuntu_binary.shtml Hope this helps! Khyota From kf6kjg at gmail.com Tue Mar 3 19:16:28 2009 From: kf6kjg at gmail.com (Ricky) Date: Tue Mar 3 19:16:35 2009 Subject: [sldev] [HELP] Skipping incompatible lllmozlib2 library In-Reply-To: <200903032154.49201.khyota@redhyena.net> References: <200903031658.02673.rgwells@techno-logix.com> <200903032154.49201.khyota@redhyena.net> Message-ID: <3bb9647e0903031916m228818e4n414e7b370355d6d7@mail.gmail.com> I wrote a series of step on my wiki userpage ( http://wiki.secondlife.com/wiki/User:Cron_Stardust ) that might be of use to you. I wrote it for compiling trunk on Gentoo x86_64, but it should apply to most 64bit Linux... Hope you are successful, Cron Stardust On Tue, Mar 3, 2009 at 6:54 PM, Khyota wrote: > - Show quoted text - > On Tuesday 03 March 2009 7:58:02 Russell G. Wells wrote: > > > > General compiling notes: > > ------------------------ > > > > I won't go into all the dependencies I needed to install compile, as I > > should reproduce the list on a clean install of my distribution. But here > > is the short list of steps I took after I installed the missing stuff. > > > > 1. unpacked the source code, linux libs, and artwork into a working > > directory. > > > > 2, ran the /linden/indra/develop.py to generate linux > makefiles. > > > > 3. copy header files for the following elements into the > > /linden/libraries//include directory. > > > > cp -a /usr/include/atk-1.0 ${TARGETDIR}/include/ > > > > # linux GUI framework > > cp -a /usr/include/gtk-2.0 ${TARGETDIR}/include/ > > cp -a /usr/lib/gtk-2.0/include/* ${TARGETDIR}/include/gtk-2.0/ > > > > # general support framework > > cp -a /usr/include/glib-2.0 ${TARGETDIR}/include/ > > cp -a /usr/lib/glib-2.0/include/* ${TARGETDIR}/include/glib-2.0/ > > > > # text layout with emphasis on internationalization > > cp -a /usr/include/pango-1.0 ${TARGETDIR}/include/ > > > > # 2D vector graphics support > > cp -a /usr/include/cairo/* ${TARGETDIR}/include > > > > # IPC support > > cp -a /usr/include/dbus-1.0/dbus/ ${TARGETDIR}/include/ > > > > # ELF file format debugging support (Stack trace) > > mkdir ${TARGETDIR}/include/ELFIO > > cp ${ELFIO}/ELFIO/*.h ${TARGETDIR}/include/ELFIO/ > > cp ${ELFIO}/ELFIO/libELFIO.a ${TARGETDIR}/lib_release_client/ > > > > NOTE: This is the minimal set I needed to compile (tried lots more as > > suggested for older builds on the wiki). > > > > > > 4. ran a compile. > > * had to fix error in > /linden/indra/newview/llappviewerlinux.cpp > > line 258 needed to change from > > > > fprintf(StraceFile, "%d:\t", btpos); > > > > to > > fprintf(StraceFile, "%lu:\t", btpos); > > > > > > 5. compile again > > * compile completes OK, but the link step generates the error listed > above. > > > > Other thoughts: > > -------------------- > > > > I saw in aan old post, that version FL-1.13.3.58185 would not compile on > > linux unless LL_LIBXUL_ENABLED was defined to 0. Is this still true? > > I tried it, but still got the link error. > > > > Russell G. Wells > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > It looks like your trying to compile non-standalone which isnt supported on > x86_64 yet, most of the libs are missing, run develop.py configure > with --standalone to get it to use your system libs. The libraries/ > directory > is not used during standalone builds. > > > The following error is being generated: > > > > Linking CXX executable secondlife-bin > > master: > > http://secondlife.com/app/message_template/master_message_template.msg > > current: > > > /home/rgwells/projects/slv-1.22.10/linden/scripts/messages/message_template > >.msg Refreshing master cache from > > http://secondlife.com/app/message_template/master_message_template.msg > > --- PASS --- > > Older > > missing message RezRestoreToWorld, did you mean to deprecate? > > in message RegionHandshake: missing 1 extra blocks > > in message RegionInfo: missing 1 extra blocks > > > > /usr/bin/ld: skipping > > incompatible > > > /home/rgwells/projects/slv-1.22.10/linden/indra/../libraries/x86_64-linux/l > >ib_release_client/libllmozlib2.a when searching for -lllmozlib2 > > /usr/bin/ld: cannot find -lllmozlib2 > > collect2: ld returned 1 exit status > > make[2]: *** [newview/secondlife-bin] Error 1 > > make[1]: *** [newview/CMakeFiles/secondlife-bin.dir/all] Error 2 > > make: *** [all] Error 2 > > I usualy see this error when a library is actually compiled for i686 rather > then x86_64 but i dont know how to find out if thats true. You can turn > llmozlib off by adding to the -DMOZLIB:BOOL=FALSE to the develop.py > configure > line, download the source and compile it yourself, or grab the ubuntu > package > from Terrex's repository > http://omvviewer.byteme.org.uk/ubuntu_binary.shtml > > Hope this helps! > > Khyota > - Show quoted text - > _______________________________________________ > 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/20090303/4b7a8f5f/attachment-0001.htm From vector at leafpile.com Wed Mar 4 02:25:16 2009 From: vector at leafpile.com (Vector Hastings) Date: Wed Mar 4 02:25:43 2009 Subject: [sldev] Help with setting up Shadow Build Message-ID: I'm a real newb to the branch environment, so even basic advise could be helpful. I downloaded from http://svn.secondlife.com/trac/linden/browser/branches/2008/shadow-draft-2 and set about trying to use the CMake instructions from http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds I tried: C:\SL_SD2_trunk\branches\2008\shadow-draft-2\indra>c:\python25\python develop.py -G VC80 Initially, it downloaded a bunch of tarballs, but always ends with the following errors: Traceback (most recent call last): md5 File "install.py", line 1075, in mismatch: c:\docume~1\...\locals~1\temp\install.cache....\GL-windows-2008061 3.tar.bz2 Downloading http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-wind ows-20080613.tar.bz2 to local file c:\docume~1\...\locals~1\temp\install.cache ....\GL-windows-20080613.tar.bz2 sys.exit(main()) File "install.py", line 1066, in main options.cache_dir) File "install.py", line 560, in install ifile.fetch_local() File "install.py", line 114, in fetch_local raise RuntimeError("Error matching md5 for %s" % self.url) RuntimeError: Error matching md5 for http://s3.amazonaws.com/viewer-source-downl oads/install_pkgs/GL-windows-20080613.tar.bz2 CMake Error: Failed to download or unpack prebuilt 'GL'. Process returned 1. -- Configuring done Cleaning 'build-VC80' 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 519, in run_cmake PlatformSetup.run_cmake(self, args) File "develop.py", line 155, in run_cmake self.run(cmd, 'cmake') File "develop.py", line 515, in run (name, ret)) __main__.CommandError: the command 'cmake' exited with -1 C:\SL_SD2_trunk\branches\2008\shadow-draft-2\indra> I can actually download from the site in question, but I don't know how to make the script continue. Any advice? Thanks to all, Vector -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090304/e3a0f3d7/attachment.htm From chaosstar at gmail.com Wed Mar 4 03:28:37 2009 From: chaosstar at gmail.com (Ambrosia) Date: Wed Mar 4 03:28:41 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: References: Message-ID: <9bb32d430903040328x78efa471i9d90af642cc22970@mail.gmail.com> Hokay, first off, don't grab the shadow-draft-2 branch. Grab normal trunk instead. The shadow code got merged into it, and it's basically the base for the 1.23 viewer. Any further changes in the shadow code will probably take place in that one. After doing so, just run the python configure -G VC80, and it should work without a hinch. Altho: A question, do you use Visual Studio 2005, or Visual Studio 2005 Express? The latter needs a little registry entry so the generator finds it without problems. On Wed, Mar 4, 2009 at 11:25, Vector Hastings wrote: > I'm a real newb to the branch environment, so even basic advise could be > helpful. > > I downloaded from > http://svn.secondlife.com/trac/linden/browser/branches/2008/shadow-draft-2?and > set about trying to use the CMake instructions from > http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds > Any advice? > > Thanks to all, > > Vector From soft at lindenlab.com Wed Mar 4 09:34:56 2009 From: soft at lindenlab.com (Soft) Date: Wed Mar 4 09:34:58 2009 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From davymaltz at gmail.com Wed Mar 4 12:28:34 2009 From: davymaltz at gmail.com (Davy Maltz) Date: Wed Mar 4 12:28:57 2009 Subject: [sldev] Problem compiling Windows crash logger from SVN trunk. Message-ID: <3f823e4f0903041228u195cfc5aw4686db5943fd666b@mail.gmail.com> System: Windows XP Visual Studio: Microsoft Visual C++ Studio Express Edition (With applied SP1) - When I compile, I do it via the GUI, using the Release build configuration. Source Code: http://svn.secondlife.com/trac/linden/browser/trunk I tried compiling the viewer from SVN today and got an unexpected error. I built one from the last snapshot and didn't get this error, which is why it surprised me. I pasted the error below. As you can see, the compiler finishes compiling windows-updater, but then errors for almost every item on the crash logger, then begins compiling secondlife-bin without any error. I assume it has to do with missing files, or something to that extent..but if anyone knows what's missing from the source, help would be appreciated~ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 23>Build log was saved at "file://c:\linden\indra\build-VC80\win_updater\windows-updater.dir\Release\BuildLog.htm" 23>windows-updater - 0 error(s), 0 warning(s) 25>------ Rebuild All started: Project: secondlife-bin, Configuration: Release Win32 ------ 25>Deleting intermediate and output files for project 'secondlife-bin', configuration 'Release|Win32' 24>Compiling... 24>win_crash_logger.cpp 24>Compiling resources... 24>Linking... 25>Setting the secondlife-bin working directory for debugging. 25>Editing solution: C:/linden/indra/build-VC80/SecondLife.sln 25>Looking for existing VisualStudio instance... 25> Didn't find open solution, starting new background VisualStudio instance... 25> Reading .sln file version... 25> Using version: VC80... 25>Value cannot be null. 25>Parameter name: type 25>Quitting do to error opening: C:\linden\indra\build-VC80\SecondLife.sln 25>Compiling... 25>llviewerprecompiledheaders.cpp 24>aprutil-1.lib(apr_base64.obj) : warning LNK4099: PDB 'aprutil-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\aprutil-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\aprutil-1_ib_1.pdb'; linking object as if no debug info 24>apr-1.lib(apr_atomic.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_1.pdb'; linking object as if no debug info 24>apr-1.lib(dir.obj) : warning LNK4099: PDB 'apr-1_ib_4.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_4.pdb'; linking object as if no debug info 24>apr-1.lib(filedup.obj) : warning LNK4099: PDB 'apr-1_ib_6.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_6.pdb'; linking object as if no debug info 24>apr-1.lib(filepath.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_7.pdb'; linking object as if no debug info 24>apr-1.lib(filepath_util.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_8.pdb'; linking object as if no debug info 24>apr-1.lib(filestat.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_9.pdb'; linking object as if no debug info 24>apr-1.lib(filesys.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_10.pdb'; linking object as if no debug info 24>apr-1.lib(flock.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_1.pdb'; linking object as if no debug info 24>apr-1.lib(fullrw.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_11.pdb'; linking object as if no debug info 24>apr-1.lib(open.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_7.pdb'; linking object as if no debug info 24>apr-1.lib(pipe.obj) : warning LNK4099: PDB 'apr-1_ib_4.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_4.pdb'; linking object as if no debug info 24>apr-1.lib(readwrite.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_1.pdb'; linking object as if no debug info 24>apr-1.lib(seek.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_2.pdb'; linking object as if no debug info 24>apr-1.lib(thread_cond.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_2.pdb'; linking object as if no debug info 24>apr-1.lib(thread_mutex.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_3.pdb'; linking object as if no debug info 24>apr-1.lib(apr_pools.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_10.pdb'; linking object as if no debug info 24>apr-1.lib(env.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_7.pdb'; linking object as if no debug info 24>apr-1.lib(internal.obj) : warning LNK4099: PDB 'apr-1_ib_6.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_6.pdb'; linking object as if no debug info 24>apr-1.lib(misc.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_2.pdb'; linking object as if no debug info 24>apr-1.lib(start.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_8.pdb'; linking object as if no debug info 24>apr-1.lib(utf8.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_1.pdb'; linking object as if no debug info 24>apr-1.lib(inet_ntop.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_10.pdb'; linking object as if no debug info 24>apr-1.lib(inet_pton.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_3.pdb'; linking object as if no debug info 24>apr-1.lib(sendrecv.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_9.pdb'; linking object as if no debug info 24>apr-1.lib(sockaddr.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_2.pdb'; linking object as if no debug info 24>apr-1.lib(sockets.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_7.pdb'; linking object as if no debug info 24>apr-1.lib(sockopt.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_1.pdb'; linking object as if no debug info 24>apr-1.lib(select.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_8.pdb'; linking object as if no debug info 24>apr-1.lib(apr_cpystrn.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_10.pdb'; linking object as if no debug info 24>apr-1.lib(apr_snprintf.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_2.pdb'; linking object as if no debug info 24>apr-1.lib(apr_strings.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_3.pdb'; linking object as if no debug info 24>apr-1.lib(apr_strtok.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_8.pdb'; linking object as if no debug info 24>apr-1.lib(apr_hash.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_9.pdb'; linking object as if no debug info 24>apr-1.lib(apr_tables.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_7.pdb'; linking object as if no debug info 24>apr-1.lib(proc.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_11.pdb'; linking object as if no debug info 24>apr-1.lib(signals.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_9.pdb'; linking object as if no debug info 24>apr-1.lib(thread.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_3.pdb'; linking object as if no debug info 24>apr-1.lib(time.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden\indra\build-VC80\win_crash_logger\Release\apr-1_ib_10.pdb'; linking object as if no debug info 24>Embedding manifest... 25>Compiling... 25>llwindebug.cpp 24>Build log was saved at "file://c:\linden\indra\build-VC80\win_crash_logger\windows-crash-logger.dir\Release\BuildLog.htm" 24>windows-crash-logger - 0 error(s), 39 warning(s) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090304/b6c216ea/attachment.htm From kf6kjg at gmail.com Wed Mar 4 17:44:01 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed Mar 4 17:44:06 2009 Subject: [sldev] libexpat Message-ID: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> Ok. So I tweaked and tweaked, and got trunk compiling again on my system. But. The client fails to start: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory So I ldd the binary: ldd do-not-directly-run-secondlife-bin | grep expat and get libexpat.so.0 => not found libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f840c1fd000) And am sitting here wondering why libexpat.so.0 is being linked. I understand that Expat changes ABI across versions, (annoying) but why is it being linked in with the new? I don't have libexpat.so.0 anywhere on my system, nor did it come with the Linden Libs... What am I supposed to do? Thanks, Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090304/a9ba7b24/attachment-0001.htm From carlo at alinoe.com Wed Mar 4 17:52:31 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed Mar 4 17:51:16 2009 Subject: [sldev] libexpat In-Reply-To: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> References: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> Message-ID: <20090305015231.GA6412@alinoe.com> On Wed, Mar 04, 2009 at 05:44:01PM -0800, Ricky wrote: > ldd do-not-directly-run-secondlife-bin | grep expat > and get > libexpat.so.0 => not found > libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f840c1fd000) > > And am sitting here wondering why libexpat.so.0 is being linked. I understand Maybe one of the other libraries is linked with it? Try running ldd on every library that you use while linking do-not-directly-run-secondlife-bin -- Carlo Wood From kf6kjg at gmail.com Wed Mar 4 18:08:11 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed Mar 4 18:08:16 2009 Subject: [sldev] libexpat In-Reply-To: <20090305015231.GA6412@alinoe.com> References: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> <20090305015231.GA6412@alinoe.com> Message-ID: <3bb9647e0903041808r555448eflc95902cffdda606f@mail.gmail.com> Ok. So: ldd do-not-directly-run-secondlife-bin | grep -v 'expat' | cut -c2- | sed -e 's/.*=> //' | cut -d' ' -f1 | xargs ldd | grep 'expat' gives: libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f806d166000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f4df893e000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fa792e8a000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007ff56f681000) ldd: warning: you do not have execution permission for `/lib/libgcc_s.so.1' libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fd8d83d7000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f027e221000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f4f62219000) And so I asked equery if there was anything in my system linked against libexpat.so.0, and the answer was no. hum... On Wed, Mar 4, 2009 at 5:52 PM, Carlo Wood wrote: > On Wed, Mar 04, 2009 at 05:44:01PM -0800, Ricky wrote: > > ldd do-not-directly-run-secondlife-bin | grep expat > > and get > > libexpat.so.0 => not found > > libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f840c1fd000) > > > > And am sitting here wondering why libexpat.so.0 is being linked. I > understand > > Maybe one of the other libraries is linked with it? > Try running ldd on every library that you use while linking > do-not-directly-run-secondlife-bin > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090304/766c56a5/attachment.htm From lists.secondlife.com at trap.wereanimal.net Wed Mar 4 22:35:35 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com@trap.wereanimal.net) Date: Wed Mar 4 22:35:46 2009 Subject: [sldev] [HELP] Skipping incompatible lllmozlib2 library In-Reply-To: <3bb9647e0903031916m228818e4n414e7b370355d6d7@mail.gmail.com> References: <200903031658.02673.rgwells@techno-logix.com> <200903032154.49201.khyota@redhyena.net> <3bb9647e0903031916m228818e4n414e7b370355d6d7@mail.gmail.com> Message-ID: <200903050135.35795.lists.secondlife.com@trap.wereanimal.net> On Tuesday 03 March 2009 10:16:28 pm Ricky wrote: > I wrote a series of step on my wiki userpage ( > http://wiki.secondlife.com/wiki/User:Cron_Stardust ) that might be of use > to you. I wrote it for compiling trunk on Gentoo x86_64, but it should > apply to most 64bit Linux... I've just got done making some secondlife ebuilds for gentoo users and put them in an overlay. I manage to get RC, trunk to build, but featurette fails to build. Its at gentoo.techwolf.net if anyone like to give them a try. -- Techwolf Lupindo From lists.secondlife.com at trap.wereanimal.net Wed Mar 4 22:38:29 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com@trap.wereanimal.net) Date: Wed Mar 4 22:38:39 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <9bb32d430903040328x78efa471i9d90af642cc22970@mail.gmail.com> References: <9bb32d430903040328x78efa471i9d90af642cc22970@mail.gmail.com> Message-ID: <200903050138.29828.lists.secondlife.com@trap.wereanimal.net> On Wednesday 04 March 2009 06:28:37 am Ambrosia wrote: > Hokay, first off, don't grab the shadow-draft-2 branch. > Grab normal trunk instead. The shadow code got merged into it, and > it's basically the base for the 1.23 viewer. Any further changes in > the shadow code will probably take place in that one. > I just done getting my trunk ebuild to work. I manged to find the debug setting on the net to turn on shadows. It works but with one problem. How can the range be extended? Like to 1000 meters? This would make for some great senic shots. -- Techwolf Lupindo From lists.secondlife.com at trap.wereanimal.net Wed Mar 4 23:28:29 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com@trap.wereanimal.net) Date: Wed Mar 4 23:28:37 2009 Subject: [sldev] libexpat In-Reply-To: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> References: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> Message-ID: <200903050228.29496.lists.secondlife.com@trap.wereanimal.net> On Wednesday 04 March 2009 08:44:01 pm Ricky wrote: > The client fails to start: error while loading shared libraries: > libexpat.so.0: cannot open shared object file: No such file or directory > > So I ldd the binary: > ldd do-not-directly-run-secondlife-bin | grep expat > and get > libexpat.so.0 => not found > libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f840c1fd000) > > And am sitting here wondering why libexpat.so.0 is being linked. Try "locate libexpat.so.0" and see if its anywhere on your system. If that doesn't work, "find / -name *libexpat.so.0*" If its not anywhere on the system, then the build is somehow linking to the downloadable libs, "http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/expat-1.95.8- linux64-20080909.tar.bz2" -- Techwolf Lupindo From chaosstar at gmail.com Wed Mar 4 23:32:38 2009 From: chaosstar at gmail.com (Ambrosia) Date: Wed Mar 4 23:32:39 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <200903050138.29828.lists.secondlife.com@trap.wereanimal.net> References: <9bb32d430903040328x78efa471i9d90af642cc22970@mail.gmail.com> <200903050138.29828.lists.secondlife.com@trap.wereanimal.net> Message-ID: <9bb32d430903042332v3e5edc4m9b74ede64820d4c7@mail.gmail.com> Open up the debug settings, and search for RenderShadowClipPlanes(?) Put in values like 50 150 300 and you will find the distance at which shadows show to be increased, be aware tho that they might be a little more rough up close. The other settings I tinkered with, but in the end left at the default...tho you can also increase the amount of blur passes (beware FPS hits), and the strength of the blur and gaussian. > I just done getting my trunk ebuild to work. I manged to find the debug > setting on the net to turn on shadows. It works but with one problem. How can > the range be extended? Like to 1000 meters? This would make for some great > senic shots. > > -- Techwolf Lupindo From philip at yhbt.com Wed Mar 4 23:40:16 2009 From: philip at yhbt.com (Philip Lowman) Date: Wed Mar 4 23:40:20 2009 Subject: [sldev] CMakePorts Message-ID: I've started a little open source project that some Second Life developers may be interested in which aims to make it easier to use 3rd party dependencies in Windows (either to prebuild dependencies for a project or to build and link to them inside a bigger project). http://code.google.com/p/cmakeports/wiki/CMakePortsPlan Obviously we're just getting started so there's not many ports there yet. The project got started when we noticed a lot of duplication of effort in the community (OSG, VTK, KDE-Windows) regarding people "CMakeifing" popular open-source projects. We'd welcome ports from the Second Life community if anyone wants to volunteer to create/maintain any. -- Philip Lowman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090305/f8690e29/attachment-0001.htm From kf6kjg at gmail.com Thu Mar 5 00:24:42 2009 From: kf6kjg at gmail.com (Ricky) Date: Thu Mar 5 00:24:46 2009 Subject: [sldev] libexpat In-Reply-To: <200903050228.29496.lists.secondlife.com@trap.wereanimal.net> References: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> <200903050228.29496.lists.secondlife.com@trap.wereanimal.net> Message-ID: <3bb9647e0903050024k5627133bi964fec90f7ce102e@mail.gmail.com> Ok, so I did the find, and the only instances of libexpat.so.0 are hidden deep within vmware folders... Nowhere near a standard include search path! FYI: I fairly closely follow the build directions I posted on my user page at http://wiki.secondlife.com/wiki/User:Cron_Stardust the only exception to this is that I've disabled a patch and had to tweak a source file due to a bad #if or three.... I can find no instance of libexpat.so.0 in my linden directory. (That's where I checked out trunk...) Not sure how it's decideing to link against a practically non-existent lib... Cron On Wed, Mar 4, 2009 at 11:28 PM, wrote: > On Wednesday 04 March 2009 08:44:01 pm Ricky wrote: > > The client fails to start: error while loading shared libraries: > > libexpat.so.0: cannot open shared object file: No such file or directory > > > > So I ldd the binary: > > ldd do-not-directly-run-secondlife-bin | grep expat > > and get > > libexpat.so.0 => not found > > libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f840c1fd000) > > > > And am sitting here wondering why libexpat.so.0 is being linked. > > Try "locate libexpat.so.0" and see if its anywhere on your system. If that > doesn't work, "find / -name *libexpat.so.0*" If its not anywhere on the > system, then the build is somehow linking to the downloadable libs, > " > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/expat-1.95.8- > linux64-20080909.tar.bz2 > " > > -- Techwolf Lupindo > > > > _______________________________________________ > 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/20090305/66b2b649/attachment.htm From robla at lindenlab.com Thu Mar 5 00:36:20 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Mar 5 00:36:26 2009 Subject: [sldev] CMakePorts In-Reply-To: References: Message-ID: <49AF8F04.4000903@lindenlab.com> On 03/04/2009 11:40 PM, Philip Lowman wrote: > I've started a little open source project that some Second Life > developers may be interested in which aims to make it easier to use > 3rd party dependencies in Windows (either to prebuild dependencies for > a project or to build and link to them inside a bigger project). > > http://code.google.com/p/cmakeports/wiki/CMakePortsPlan > > Obviously we're just getting started so there's not many ports there > yet. The project got started when we noticed a lot of duplication of > effort in the community (OSG, VTK, KDE-Windows) regarding people > "CMakeifing" popular open-source projects. We'd welcome ports from > the Second Life community if anyone wants to volunteer to > create/maintain any. What a great idea! Sounds like it's going to be a lot of work up front, but sounds like it could result in a lot of saved time in the long haul. This seems most helpful for people doing "standalone" builds of the Windows version of the Second Life viewer. Since Linden Lab developers typically use the non-standalone mode, it's not a project we would be an early adopter for, but I for one am excited to see this, and hope some folks on this list look into it more. Rob From chaosstar at gmail.com Thu Mar 5 00:55:02 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 00:55:04 2009 Subject: [sldev] libexpat In-Reply-To: <3bb9647e0903050024k5627133bi964fec90f7ce102e@mail.gmail.com> References: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> <200903050228.29496.lists.secondlife.com@trap.wereanimal.net> <3bb9647e0903050024k5627133bi964fec90f7ce102e@mail.gmail.com> Message-ID: <9bb32d430903050055s3a5a283bo63ace5e666dd8a4e@mail.gmail.com> On Thu, Mar 5, 2009 at 09:24, Ricky wrote: > FYI: I fairly closely follow the build directions I posted on my user page > at http://wiki.secondlife.com/wiki/User:Cron_Stardust?? the only exception > to this is that I've disabled a patch and had to tweak a source file due to > a bad #if or three.... A question, why do you emerge scons? The new build process doesn't use it, AFAIK, since 1.21. > I can find no instance of libexpat.so.0 in my linden directory. (That's > where I checked out trunk...)? Not sure how it's decideing to link against a > practically non-existent lib... libexpat gets used in the XML parsing classes. Since you are building a standalone build, judging by your user page, instead of using the libraries LL provides in the cmake process, you need to emerge it. I presume it doesn't get grabbed by cmake in standalone. Of course the question remains why it doesn't complain in the first place during the linking to the shared lib, instead of just...doing it. >> -- Techwolf Lupindo From vector at leafpile.com Thu Mar 5 01:23:51 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu Mar 5 01:24:03 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <9bb32d430903040328x78efa471i9d90af642cc22970@mail.gmail.com> Message-ID: Ah, thanks. The one marked "trunk" Doh, that's what you're talking about. OK, got that, but I still got trouble. the same: CMake Error: Failed to download or unpack prebuilt 'GL'. Process returned 1. -- Configuring done Cleaning 'build-VC80' Error: the command 'cmake' exited with status -1 and no build-vc80 directory. I'm using cmake ver 2.4.8, and python version 2.5 and MSVS 2005 Express... so I may need that registry entry, but I'm reading the wiki's and not finding any info on that registry change. I've been able to make the standard build without too much trouble. Thanks for your help. Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Ambrosia Sent: Wednesday, March 04, 2009 3:29 AM To: Vector Hastings Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build Hokay, first off, don't grab the shadow-draft-2 branch. Grab normal trunk instead. The shadow code got merged into it, and it's basically the base for the 1.23 viewer. Any further changes in the shadow code will probably take place in that one. After doing so, just run the python configure -G VC80, and it should work without a hinch. Altho: A question, do you use Visual Studio 2005, or Visual Studio 2005 Express? The latter needs a little registry entry so the generator finds it without problems. On Wed, Mar 4, 2009 at 11:25, Vector Hastings wrote: > I'm a real newb to the branch environment, so even basic advise could be > helpful. > > I downloaded from > http://svn.secondlife.com/trac/linden/browser/branches/2008/shadow-draft-2?a nd > set about trying to use the CMake instructions from > http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds > Any advice? > > Thanks to all, > > Vector _______________________________________________ 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 vector at leafpile.com Thu Mar 5 01:59:15 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu Mar 5 01:59:29 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: Message-ID: I'm attaching the full log below, but seems like I'm stuck on: "RuntimeError: Error matching md5 for http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 0613.tar.bz2" I don't know much about this, but looks like I'm getting the wrong hash-totals or some similar control. Have the files changed? Is there an environment gotcha? I'd be so grateful for any guidance. Thanks. Full log: C:\SL_SD2_trunk\trunk\indra>c:\python25\python develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=OFF -DUNATTENDED:BOOL =OFF -DROOT_PROJECT_NAME:STRING=SecondLife "" "C:\\SL_SD2_trunk\\trunk\\indra"' in 'build-VC80' -- Check for working C compiler: cl -- Check for working C compiler: cl -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: cl -- Check for working CXX compiler: cl -- works install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset install.py:67: DeprecationWarning: the md5 module is deprecated; use hashlib ins tead import md5 install.py:78: DeprecationWarning: the sets module is deprecated from sets import Set as set, ImmutableSet as frozenset Traceback (most recent call last): md File "install.py", line 1153, in 5 mismatch: c:\docume~1\...\locals~1\temp\install.cache....\GL-windows-20080 613.tar.bz2 Downloading http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-wind ows-20080613.tar.bz2 to local file c:\docume~1\...\locals~1\temp\install.cache ....\GL-windows-20080613.tar.bz2 sys.exit(main()) File "install.py", line 1145, in main options.scp) File "install.py", line 644, in do_install cache_dir) File "install.py", line 603, in install ifile.fetch_local() File "install.py", line 145, in fetch_local raise RuntimeError("Error matching md5 for %s" % self.url) RuntimeError: Error matching md5 for http://s3.amazonaws.com/viewer-source-downl oads/install_pkgs/GL-windows-20080613.tar.bz2 CMake Error: Failed to download or unpack prebuilt 'GL'. Process returned 1. -- Configuring done Cleaning 'build-VC80' Error: the command 'cmake' exited with status -1 -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Vector Hastings Sent: Thursday, March 05, 2009 1:24 AM To: Ambrosia; sldev@lists.secondlife.com Subject: RE: [sldev] Help with setting up Shadow Build Ah, thanks. The one marked "trunk" Doh, that's what you're talking about. OK, got that, but I still got trouble. the same: CMake Error: Failed to download or unpack prebuilt 'GL'. Process returned 1. -- Configuring done Cleaning 'build-VC80' Error: the command 'cmake' exited with status -1 and no build-vc80 directory. I'm using cmake ver 2.4.8, and python version 2.5 and MSVS 2005 Express... so I may need that registry entry, but I'm reading the wiki's and not finding any info on that registry change. I've been able to make the standard build without too much trouble. Thanks for your help. Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Ambrosia Sent: Wednesday, March 04, 2009 3:29 AM To: Vector Hastings Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build Hokay, first off, don't grab the shadow-draft-2 branch. Grab normal trunk instead. The shadow code got merged into it, and it's basically the base for the 1.23 viewer. Any further changes in the shadow code will probably take place in that one. After doing so, just run the python configure -G VC80, and it should work without a hinch. Altho: A question, do you use Visual Studio 2005, or Visual Studio 2005 Express? The latter needs a little registry entry so the generator finds it without problems. On Wed, Mar 4, 2009 at 11:25, Vector Hastings wrote: > I'm a real newb to the branch environment, so even basic advise could be > helpful. > > I downloaded from > http://svn.secondlife.com/trac/linden/browser/branches/2008/shadow-draft-2?a nd > set about trying to use the CMake instructions from > http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds > Any advice? > > Thanks to all, > > Vector _______________________________________________ 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 chaosstar at gmail.com Thu Mar 5 02:05:39 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 02:05:45 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: References: Message-ID: <9bb32d430903050205kee0d494rfefde8d5f79e9eed@mail.gmail.com> On Thu, Mar 5, 2009 at 10:59, Vector Hastings wrote: > I'm attaching the full log below, but seems like I'm stuck on: > > "RuntimeError: Error matching md5 for > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 > 0613.tar.bz2" > > I don't know much about this, but looks like I'm getting the wrong > hash-totals or some similar control. Have the files changed? Is there an > environment gotcha? > > I'd be so grateful for any guidance. Thanks. > Interesting. It indeed seems as if it has a wrong MD5 checksum in the cmake library list. I think the GL-Windows-2008 package is also quite a new addition..I used to grab the GL headers from an external source since they were not supplied. You have two ways to handle this: comment out that library in the install.xml in the top folder, grab it manually, and extract it (it contains a libraries tree structure already), orrrr grab it manually, make a MD5 checksum of it, and put the correct value in the install.xml :3 From chaosstar at gmail.com Thu Mar 5 02:11:15 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 02:11:17 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <9bb32d430903050205kee0d494rfefde8d5f79e9eed@mail.gmail.com> References: <9bb32d430903050205kee0d494rfefde8d5f79e9eed@mail.gmail.com> Message-ID: <9bb32d430903050211y6c835ftc5370f62061aa283@mail.gmail.com> By the way, the messages about the MD5 python module being deprecated are also strange. I don't remember getting those, myself. Mayhaps the MD5 checksum is correct, but the module fails at correctly comparing it. The OS wiki mentions (at least for the Linux compile instructions) that Python 2.5 might cause some messages when running develop.py, but say it -should- run fine. Try grabbing the GL package manually, comment it out, and see if you get MD5 errors on the other libraries as well. On Thu, Mar 5, 2009 at 11:05, Ambrosia wrote: > On Thu, Mar 5, 2009 at 10:59, Vector Hastings wrote: >> I'm attaching the full log below, but seems like I'm stuck on: >> >> "RuntimeError: Error matching md5 for >> http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >> 0613.tar.bz2" >> >> I don't know much about this, but looks like I'm getting the wrong >> hash-totals or some similar control. Have the files changed? Is there an >> environment gotcha? >> >> I'd be so grateful for any guidance. Thanks. >> > > Interesting. It indeed seems as if it has a wrong MD5 checksum in the > cmake library list. > I think the GL-Windows-2008 package is also quite a new addition..I > used to grab the GL headers from an external source since they were > not supplied. > > You have two ways to handle this: > > comment out that library in the install.xml in the top folder, grab it > manually, and extract it (it contains a libraries tree structure > already), orrrr grab it manually, make a MD5 checksum of it, and put > the correct value in the install.xml :3 > From vector at leafpile.com Thu Mar 5 02:29:47 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu Mar 5 02:30:01 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <9bb32d430903050205kee0d494rfefde8d5f79e9eed@mail.gmail.com> Message-ID: Awesome! Being better at commenting out than at making checksums at 2:30 am, I went that route... it's downloading tarbals and I'm going to bed. Thank you soooo much Ambrosia! -----Original Message----- From: Ambrosia [mailto:chaosstar@gmail.com] Sent: Thursday, March 05, 2009 2:06 AM To: Vector Hastings Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build On Thu, Mar 5, 2009 at 10:59, Vector Hastings wrote: > I'm attaching the full log below, but seems like I'm stuck on: > > "RuntimeError: Error matching md5 for > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 > 0613.tar.bz2" > > I don't know much about this, but looks like I'm getting the wrong > hash-totals or some similar control. Have the files changed? Is there an > environment gotcha? > > I'd be so grateful for any guidance. Thanks. > Interesting. It indeed seems as if it has a wrong MD5 checksum in the cmake library list. I think the GL-Windows-2008 package is also quite a new addition..I used to grab the GL headers from an external source since they were not supplied. You have two ways to handle this: comment out that library in the install.xml in the top folder, grab it manually, and extract it (it contains a libraries tree structure already), orrrr grab it manually, make a MD5 checksum of it, and put the correct value in the install.xml :3 From sldev at free.fr Thu Mar 5 04:43:05 2009 From: sldev at free.fr (Henri Beauchamp) Date: Thu Mar 5 04:43:18 2009 Subject: [sldev] Deprecated protocol feature: stray colon in 500 response In-Reply-To: <49AC5557.9010603@lindenlab.com> References: <49AC5557.9010603@lindenlab.com> Message-ID: <20090305134305.fad249c6.sldev@free.fr> On Mon, 02 Mar 2009 13:53:27 -0800, Rob Lanphier wrote: > Hi folks, > > The current version of our server infrastructure for capabilities has a > misfeature in it, where 500 responses have a stray colon in them. > Capabilities are meant to be HTTP-compliant, but this stray colon is > not. However, that incompatibility is required to maintain > compatibility with 1.20.17 and earlier viewers (and their derivatives). > > Maintaining this situation is a pain, because coercing standards-based > infrastructure (like Apache) to do the wrong thing is a major pain. We > eventually would like to eliminate this aberration from our > infrastructure, but that would mean that older viewers would stop > working. We'll give you plenty of warning before actually changing this > infrastructure, but we figured it's best to get the technical > information out now so that this will hopefully be a moot point by the > time we announce a timeline. > > We're asking that everyone who has a viewer based on 1.20.17 and older > to either upgrade to a newer base revision of the viewer (e.g. 1.21 or > later) or apply a fix as described here: > https://wiki.secondlife.com/wiki/Deprecated_Protocol_Features > > ...with patches attached here: > https://jira.secondlife.com/browse/VWR-12248 > > Thanks! > Rob The legacy renderer branch of the Cool SL Viewer (v1.19.0.5) has been updated to implement the fixes. I also published on the JIRA a patch adapted to the v1.19.0.5 viewer, which aggregates all three patches by Ramzi. The patch might work with older viewers as well... Henri. From chaosstar at gmail.com Thu Mar 5 08:35:49 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 08:35:51 2009 Subject: [sldev] Complete standalone trunk building script for Debian Lenny Message-ID: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> Greetings SLDEViants! I made a bash script that compiles a standalone 1.23 trunk build on Apt/dpkg based systems. It's tested on Debian Lenny, and takes care of everything, getting packages (Including the toolchain and subversion), downloading the trunk, adding fixes and 3rd party libraries, before finally compiling and making a nice directory for the viewer. In other words, if all runs well it's fire and forget. It can be grabbed at: ftp://ambftp.ath.cx/build-trunk-ambrosia.sh It should work on even the most minimal Lenny installations. Please see the comments at the top of the script for details. Also, the script should do its work on Ubuntu and Debian Sid, and similiar dpkg-based distributions, tho the line that grabs the system packages might need some tweaking. As I said, it's 1-shot unattended, so run 'sh build-trunk-ambrosia.sh', enter your root pass (onoz!). have some coffee, and hopefully return to a shiny new viewer. And yes, I expect you to check the script first before doing anything like typing in passwords. I added lots of comments, and indented it well, so it should be easy to read and a good base for more tweaking. It's made to compile on both 32 and 64 bit, and attempts to create a standalone build with FMod disabled, OpenAL enabled, and the debug setting on 'Release'. I tried to make it do several checks, as not to redo already done steps on re-run, unless wanted. Enjoy! From thomas.shikami at online.de Thu Mar 5 09:24:37 2009 From: thomas.shikami at online.de (Thomas Shikami) Date: Thu Mar 5 09:24:48 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: References: Message-ID: <49B00AD5.2090009@online.de> Vector Hastings wrote: > "RuntimeError: Error matching md5 for > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 > 0613.tar.bz2" > > I don't know much about this, but looks like I'm getting the wrong > hash-totals or some similar control. Have the files changed? Is there an > environment gotcha? > someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the correct file invalidating the checksum of older install.xml the recent GL-windows-20080613.tar.bz2 and the former GL-windows-20080613.tar.bz2 differ not only by size, but by contents as well. The original file that is expected by almost all install.xml is 372004 bytes and has a MD5 of e6ba152b7edd4ad2c9db4f9ff7bd38e1. The file that is found recently at the same position is only 55613 in size with MD5 of 768030927c83e1d9e78f31625dfd678c. Most people still have the expected file in their cache and therefore do not experience that bug. From gcanaday at gmail.com Thu Mar 5 09:39:50 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Thu Mar 5 09:40:05 2009 Subject: [sldev] Complete standalone trunk building script for Debian Lenny In-Reply-To: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> References: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> Message-ID: <200903051239.50313.gcanaday@gmail.com> Nice. Trying it out now. Ubuntu has root disabled by default. As a result, su -c does not work. sudo seems to be working ok. Running it as I type. --GC On Thursday 05 March 2009 11:35:49 am Ambrosia wrote: > Greetings SLDEViants! > > I made a bash script that compiles a standalone 1.23 trunk build on > Apt/dpkg based systems. > > It's tested on Debian Lenny, and takes care of everything, getting > packages (Including the toolchain and subversion), > downloading the trunk, adding fixes and 3rd party libraries, before > finally compiling and making a nice directory > for the viewer. In other words, if all runs well it's fire and forget. > > It can be grabbed at: > > ftp://ambftp.ath.cx/build-trunk-ambrosia.sh > > It should work on even the most minimal Lenny installations. Please > see the comments at the top of the script for details. > Also, the script should do its work on Ubuntu and Debian Sid, and > similiar dpkg-based distributions, > tho the line that grabs the system packages might need some tweaking. > > As I said, it's 1-shot unattended, so run 'sh > build-trunk-ambrosia.sh', enter your root pass (onoz!). have some > coffee, > and hopefully return to a shiny new viewer. > > And yes, I expect you to check the script first before doing anything > like typing in passwords. I added lots of comments, and > indented it well, so it should be easy to read and a good base for > more tweaking. > > It's made to compile on both 32 and 64 bit, and attempts to create a > standalone build with FMod disabled, OpenAL enabled, > and the debug setting on 'Release'. I tried to make it do several > checks, as not to redo already done steps on re-run, unless > wanted. > > Enjoy! > _______________________________________________ > 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 chaosstar at gmail.com Thu Mar 5 09:42:30 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 09:42:33 2009 Subject: [sldev] Complete standalone trunk building script for Debian Lenny In-Reply-To: <200903051239.50313.gcanaday@gmail.com> References: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> <200903051239.50313.gcanaday@gmail.com> Message-ID: <9bb32d430903050942g3018aa01r78611929f81a0d6f@mail.gmail.com> Yes, I'm aware, hence why I mentioned replacing it with sudo and removing the '&& exit' in the comments. Theoretically the script could just check /etc/issue for Ubuntuness or Debian. On Thu, Mar 5, 2009 at 18:39, Glen Canaday wrote: > > Nice. Trying it out now. > > Ubuntu has root disabled by default. As a result, su -c does not work. sudo > seems to be working ok. Running it as I type. > > --GC From gcanaday at gmail.com Thu Mar 5 09:46:38 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Thu Mar 5 09:46:42 2009 Subject: [sldev] Complete standalone trunk building script for Debian Lenny In-Reply-To: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> References: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> Message-ID: <200903051246.38355.gcanaday@gmail.com> removed quotes: su - -c "apt-get..." changed to sudo apt-get update ... etc Seems to be working now. Hopefully it doesn't break anything. --GC On Thursday 05 March 2009 11:35:49 am Ambrosia wrote: > Greetings SLDEViants! > > I made a bash script that compiles a standalone 1.23 trunk build on > Apt/dpkg based systems. > > It's tested on Debian Lenny, and takes care of everything, getting > packages (Including the toolchain and subversion), > downloading the trunk, adding fixes and 3rd party libraries, before > finally compiling and making a nice directory > for the viewer. In other words, if all runs well it's fire and forget. > > It can be grabbed at: > > ftp://ambftp.ath.cx/build-trunk-ambrosia.sh > > It should work on even the most minimal Lenny installations. Please > see the comments at the top of the script for details. > Also, the script should do its work on Ubuntu and Debian Sid, and > similiar dpkg-based distributions, > tho the line that grabs the system packages might need some tweaking. > > As I said, it's 1-shot unattended, so run 'sh > build-trunk-ambrosia.sh', enter your root pass (onoz!). have some > coffee, > and hopefully return to a shiny new viewer. > > And yes, I expect you to check the script first before doing anything > like typing in passwords. I added lots of comments, and > indented it well, so it should be easy to read and a good base for > more tweaking. > > It's made to compile on both 32 and 64 bit, and attempts to create a > standalone build with FMod disabled, OpenAL enabled, > and the debug setting on 'Release'. I tried to make it do several > checks, as not to redo already done steps on re-run, unless > wanted. > > Enjoy! > _______________________________________________ > 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 chaosstar at gmail.com Thu Mar 5 09:57:35 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 09:57:37 2009 Subject: [sldev] Complete standalone trunk building script for Debian Lenny In-Reply-To: <200903051246.38355.gcanaday@gmail.com> References: <9bb32d430903050835qa64b9darf0f9285ff175baf4@mail.gmail.com> <200903051246.38355.gcanaday@gmail.com> Message-ID: <9bb32d430903050957w25985a4cr61bb491515274b31@mail.gmail.com> There, I added a check for 'ubuntu' in /etc/issue. If present, it attempts to automatically use sudo instead of su - -c Script link is the same. :3 From vector at leafpile.com Thu Mar 5 11:32:01 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu Mar 5 11:32:16 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <49B00AD5.2090009@online.de> Message-ID: Do you know where I can get the former one? I noticed when I unpacked the one that's there that the headers were different sizes and dates. I went ahead and overlayed the one's I'd packaged from earlier builds since I figured these "new" ones were the ones compatible with the trunk. Thanks! Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Thomas Shikami Sent: Thursday, March 05, 2009 9:25 AM To: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build Vector Hastings wrote: > "RuntimeError: Error matching md5 for > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 > 0613.tar.bz2" > > I don't know much about this, but looks like I'm getting the wrong > hash-totals or some similar control. Have the files changed? Is there an > environment gotcha? > someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the correct file invalidating the checksum of older install.xml the recent GL-windows-20080613.tar.bz2 and the former GL-windows-20080613.tar.bz2 differ not only by size, but by contents as well. The original file that is expected by almost all install.xml is 372004 bytes and has a MD5 of e6ba152b7edd4ad2c9db4f9ff7bd38e1. The file that is found recently at the same position is only 55613 in size with MD5 of 768030927c83e1d9e78f31625dfd678c. Most people still have the expected file in their cache and therefore do not experience that bug. _______________________________________________ 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 Thu Mar 5 17:45:00 2009 From: soft at lindenlab.com (Soft) Date: Thu Mar 5 17:45:02 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <49B00AD5.2090009@online.de> References: <49B00AD5.2090009@online.de> Message-ID: On Thu, Mar 5, 2009 at 11:24 AM, Thomas Shikami wrote: > Vector Hastings wrote: >> >> "RuntimeError: Error matching md5 for >> >> http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >> 0613.tar.bz2" >> >> I don't know much about this, but looks like I'm getting the wrong >> hash-totals or some similar control. Have the files changed? Is there an >> environment gotcha? >> > > someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the > correct file invalidating the checksum of older install.xml That's apparently what happened here. I sent a note to the internal engineer list asking them to never reuse filenames here, and explaining what happened. Unfortunately, I don't know where to get a copy of the old library bundle unless the dev who first uploaded it steps forward. I'd be very surprised if the new one didn't work though, checksum aside. From soft at lindenlab.com Thu Mar 5 18:26:20 2009 From: soft at lindenlab.com (Soft) Date: Thu Mar 5 18:26:23 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: References: <49B00AD5.2090009@online.de> Message-ID: On Thu, Mar 5, 2009 at 7:45 PM, Soft wrote: > On Thu, Mar 5, 2009 at 11:24 AM, Thomas Shikami > wrote: >> Vector Hastings wrote: >>> >>> "RuntimeError: Error matching md5 for >>> >>> http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >>> 0613.tar.bz2" >>> >>> I don't know much about this, but looks like I'm getting the wrong >>> hash-totals or some similar control. Have the files changed? Is there an >>> environment gotcha? >>> >> >> someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the >> correct file invalidating the checksum of older install.xml > > That's apparently what happened here. I sent a note to the internal > engineer list asking them to never reuse filenames here, and > explaining what happened. > > Unfortunately, I don't know where to get a copy of the old library > bundle unless the dev who first uploaded it steps forward. I'd be very > surprised if the new one didn't work though, checksum aside. Okay, following up on this -- * The old bundle has been found and is being put back in place * The install.xml will be updated to point to a new location for the new bundle From poppy at lindenlab.com Thu Mar 5 19:35:58 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Thu Mar 5 19:36:00 2009 Subject: [sldev] CMakePorts In-Reply-To: References: Message-ID: <49B09A1E.8050902@lindenlab.com> I don't get it. Why would you change the build system of a 3rd party library for Second Life? (Other than because you really like CMake and want to write more CMakeLists.txt files.) + poppy Philip Lowman wrote: > I've started a little open source project that some Second Life > developers may be interested in which aims to make it easier to use 3rd > party dependencies in Windows (either to prebuild dependencies for a > project or to build and link to them inside a bigger project). > > http://code.google.com/p/cmakeports/wiki/CMakePortsPlan > > Obviously we're just getting started so there's not many ports there > yet. The project got started when we noticed a lot of duplication of > effort in the community (OSG, VTK, KDE-Windows) regarding people > "CMakeifing" popular open-source projects. We'd welcome ports from the > Second Life community if anyone wants to volunteer to create/maintain any. > > -- > Philip Lowman > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 philip at yhbt.com Thu Mar 5 22:06:36 2009 From: philip at yhbt.com (Philip Lowman) Date: Thu Mar 5 22:06:39 2009 Subject: [sldev] CMakePorts In-Reply-To: <49B09A1E.8050902@lindenlab.com> References: <49B09A1E.8050902@lindenlab.com> Message-ID: It's a good question. The reason why is quite simple. Many of these 3rd party library authors have no clue how useful their code really is. We want to make it easy for us (and others) to use this code in their own projects, especially when they're stuck with a compiler like MSVC which (at least at the moment) has 8 different build permutations (per version!). Rather than try to maintain hacked up build systems for these popular 3rd party libraries it's simply far easier to switch them over to CMake. That allows people to use Makefiles or whatever IDE they prefer (Visual Studio, Eclipse, CodeBlocks, XCode, KDevelop, etc.). On Thu, Mar 5, 2009 at 10:35 PM, Paul Oppenheim (Poppy Linden) < poppy@lindenlab.com> wrote: > I don't get it. Why would you change the build system of a 3rd party > library for Second Life? (Other than because you really like CMake and want > to write more CMakeLists.txt files.) > > + poppy > > Philip Lowman wrote: > >> I've started a little open source project that some Second Life developers >> may be interested in which aims to make it easier to use 3rd party >> dependencies in Windows (either to prebuild dependencies for a project or to >> build and link to them inside a bigger project). >> >> http://code.google.com/p/cmakeports/wiki/CMakePortsPlan >> >> Obviously we're just getting started so there's not many ports there yet. >> The project got started when we noticed a lot of duplication of effort in >> the community (OSG, VTK, KDE-Windows) regarding people "CMakeifing" popular >> open-source projects. We'd welcome ports from the Second Life community if >> anyone wants to volunteer to create/maintain any. >> >> -- >> Philip Lowman >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -- Philip Lowman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090306/560d7e08/attachment.htm From robla at lindenlab.com Thu Mar 5 22:28:57 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Mar 5 22:29:19 2009 Subject: [sldev] CMakePorts In-Reply-To: References: <49B09A1E.8050902@lindenlab.com> Message-ID: <49B0C2A9.2010306@lindenlab.com> Hi Philip, I've assumed what you're envisioning is a sort of Gentoo emerge/FreeBSD ports type system (hence the name "ports") for Windows , layered on top of CMake, such that there's a standard set of build commands and dependency resolution system. Do I have the ultimate vision roughly right? It sounds like a bit of a stretch from the core purpose of CMake, but not a wild stretch. Rob On 03/05/2009 10:06 PM, Philip Lowman wrote: > It's a good question. > > The reason why is quite simple. Many of these 3rd party library > authors have no clue how useful their code really is. We want to make > it easy for us (and others) to use this code in their own projects, > especially when they're stuck with a compiler like MSVC which (at > least at the moment) has 8 different build permutations (per version!). > > Rather than try to maintain hacked up build systems for these popular > 3rd party libraries it's simply far easier to switch them over to > CMake. That allows people to use Makefiles or whatever IDE they > prefer (Visual Studio, Eclipse, CodeBlocks, XCode, KDevelop, etc.). > > > On Thu, Mar 5, 2009 at 10:35 PM, Paul Oppenheim (Poppy Linden) > > wrote: > > I don't get it. Why would you change the build system of a 3rd > party library for Second Life? (Other than because you really like > CMake and want to write more CMakeLists.txt files.) > > + poppy > > Philip Lowman wrote: > > I've started a little open source project that some Second > Life developers may be interested in which aims to make it > easier to use 3rd party dependencies in Windows (either to > prebuild dependencies for a project or to build and link to > them inside a bigger project). > > http://code.google.com/p/cmakeports/wiki/CMakePortsPlan > > Obviously we're just getting started so there's not many ports > there yet. The project got started when we noticed a lot of > duplication of effort in the community (OSG, VTK, KDE-Windows) > regarding people "CMakeifing" popular open-source projects. > We'd welcome ports from the Second Life community if anyone > wants to volunteer to create/maintain any. > > -- > Philip Lowman > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > > > > -- > Philip Lowman > ------------------------------------------------------------------------ > > _______________________________________________ > 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 vector at leafpile.com Thu Mar 5 22:36:51 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu Mar 5 22:37:06 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: Message-ID: Thanks for everyone's help! The new tarball seems to fix that problem, now I'm onto umpteen of these: "CMake Error: Cannot find source file "C:/SL_SD2_Trunk/indra/build-VC80/newview/r es/arrow.cur" Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .i n .txx" A quick look on google suggests missing artwork (??) If that's the case, Any ideas on where I can snag the right stuff and update the install script to use it? Thanks again to all, Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Soft Sent: Thursday, March 05, 2009 6:26 PM To: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build On Thu, Mar 5, 2009 at 7:45 PM, Soft wrote: > On Thu, Mar 5, 2009 at 11:24 AM, Thomas Shikami > wrote: >> Vector Hastings wrote: >>> >>> "RuntimeError: Error matching md5 for >>> >>> http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >>> 0613.tar.bz2" >>> >>> I don't know much about this, but looks like I'm getting the wrong >>> hash-totals or some similar control. Have the files changed? Is there an >>> environment gotcha? >>> >> >> someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the >> correct file invalidating the checksum of older install.xml > > That's apparently what happened here. I sent a note to the internal > engineer list asking them to never reuse filenames here, and > explaining what happened. > > Unfortunately, I don't know where to get a copy of the old library > bundle unless the dev who first uploaded it steps forward. I'd be very > surprised if the new one didn't work though, checksum aside. Okay, following up on this -- * The old bundle has been found and is being put back in place * The install.xml will be updated to point to a new location for the new bundle _______________________________________________ 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 philip at yhbt.com Thu Mar 5 23:29:46 2009 From: philip at yhbt.com (Philip Lowman) Date: Thu Mar 5 23:29:54 2009 Subject: [sldev] CMakePorts In-Reply-To: <49B0C2A9.2010306@lindenlab.com> References: <49B09A1E.8050902@lindenlab.com> <49B0C2A9.2010306@lindenlab.com> Message-ID: On Fri, Mar 6, 2009 at 1:28 AM, Rob Lanphier wrote: > Hi Philip, > > I've assumed what you're envisioning is a sort of Gentoo emerge/FreeBSD > ports type system (hence the name "ports") for Windows , layered on top > of CMake, such that there's a standard set of build commands and > dependency resolution system. > > Do I have the ultimate vision roughly right? It sounds like a bit of a > stretch from the core purpose of CMake, but not a wild stretch. That may have been the inspiration for the idea by others, but I think it's highly doubtful CMakePorts will evolve into the "holy-grail" solution for installing open-source software on Windows. The reason why is our focus is on libraries, not applications. As C++ becomes used in more and more open-source libraries and the number of compilers grows more and more on Windows, I think it would become harder and harder to maintain a ports system in the Gentoo/FreeBSD fashion. At the moment KDE-Windows is probably a much better candidate for an "application" ports system. We'll be working with them to ensure that there is no wasted effort in terms of adding CMake scripts for open-source library projects, though. Ultimately I think the two use cases for CMakePorts will be allowing developers to say: "OK, I want a [32 | 64bit] MSVC [7.0 | 7.1 | 8.0 | 9.0] /M[TD] Debug & Release build of all of these libraries, make install here, thank you very much, I'll take things from here"... or.. "OK I want to build libcurl, libfreetype, and libpng within my project (and please make install the DLLs by-the-way)" I could be entirely wrong about this though, we'll just have to see how things progress. -- Philip Lowman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090306/7df4bd42/attachment-0001.htm From chaosstar at gmail.com Thu Mar 5 23:50:39 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu Mar 5 23:50:41 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: References: Message-ID: <9bb32d430903052350r6eca1028t7c3257ae178e6360@mail.gmail.com> Vector: see the file doc/asset_urls.txt in there are URLs to the artwork and libs you need to add. On Fri, Mar 6, 2009 at 07:36, Vector Hastings wrote: > Thanks for everyone's help! > > The new tarball seems to fix that problem, now I'm onto umpteen of these: > > "CMake Error: Cannot find source file > "C:/SL_SD2_Trunk/indra/build-VC80/newview/r > es/arrow.cur" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .i > n .txx" > > A quick look on google suggests missing artwork (??) > > If that's the case, Any ideas on where I can snag the right stuff and update > the install script to use it? > > Thanks again to all, > > Vector > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Soft > Sent: Thursday, March 05, 2009 6:26 PM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Help with setting up Shadow Build > > > On Thu, Mar 5, 2009 at 7:45 PM, Soft wrote: >> On Thu, Mar 5, 2009 at 11:24 AM, Thomas Shikami >> wrote: >>> Vector Hastings wrote: >>>> >>>> "RuntimeError: Error matching md5 for >>>> >>>> > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >>>> 0613.tar.bz2" >>>> >>>> I don't know much about this, but looks like I'm getting the wrong >>>> hash-totals or some similar control. Have the files changed? Is there an >>>> environment gotcha? >>>> >>> >>> someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the >>> correct file invalidating the checksum of older install.xml >> >> That's apparently what happened here. I sent a note to the internal >> engineer list asking them to never reuse filenames here, and >> explaining what happened. >> >> Unfortunately, I don't know where to get a copy of the old library >> bundle unless the dev who first uploaded it steps forward. I'd be very >> surprised if the new one didn't work though, checksum aside. > > Okay, following up on this -- > * The old bundle has been found and is being put back in place > * The install.xml will be updated to point to a new location for the new > bundle > > > > > _______________________________________________ > 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 vector at leafpile.com Fri Mar 6 01:16:04 2009 From: vector at leafpile.com (Vector Hastings) Date: Fri Mar 6 01:16:38 2009 Subject: [sldev] Help with setting up Shadow Build In-Reply-To: <9bb32d430903052350r6eca1028t7c3257ae178e6360@mail.gmail.com> Message-ID: You guys are great! Thanks for the compassion Ambrosia. That sets up the environment fabulously! (I'm obviously pretty green at this.) Now on to compiling ;-D Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Ambrosia Sent: Thursday, March 05, 2009 11:51 PM To: Vector Hastings Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build Vector: see the file doc/asset_urls.txt in there are URLs to the artwork and libs you need to add. On Fri, Mar 6, 2009 at 07:36, Vector Hastings wrote: > Thanks for everyone's help! > > The new tarball seems to fix that problem, now I'm onto umpteen of these: > > "CMake Error: Cannot find source file > "C:/SL_SD2_Trunk/indra/build-VC80/newview/r > es/arrow.cur" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .i > n .txx" > > A quick look on google suggests missing artwork (??) > > If that's the case, Any ideas on where I can snag the right stuff and update > the install script to use it? > > Thanks again to all, > > Vector > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Soft > Sent: Thursday, March 05, 2009 6:26 PM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Help with setting up Shadow Build > > > On Thu, Mar 5, 2009 at 7:45 PM, Soft wrote: >> On Thu, Mar 5, 2009 at 11:24 AM, Thomas Shikami >> wrote: >>> Vector Hastings wrote: >>>> >>>> "RuntimeError: Error matching md5 for >>>> >>>> > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >>>> 0613.tar.bz2" >>>> >>>> I don't know much about this, but looks like I'm getting the wrong >>>> hash-totals or some similar control. Have the files changed? Is there an >>>> environment gotcha? >>>> >>> >>> someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the >>> correct file invalidating the checksum of older install.xml >> >> That's apparently what happened here. I sent a note to the internal >> engineer list asking them to never reuse filenames here, and >> explaining what happened. >> >> Unfortunately, I don't know where to get a copy of the old library >> bundle unless the dev who first uploaded it steps forward. I'd be very >> surprised if the new one didn't work though, checksum aside. > > Okay, following up on this -- > * The old bundle has been found and is being put back in place > * The install.xml will be updated to point to a new location for the new > bundle > > > > > _______________________________________________ > 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 vector at leafpile.com Sat Mar 7 04:56:42 2009 From: vector at leafpile.com (Vector Hastings) Date: Sat Mar 7 04:57:03 2009 Subject: [sldev] Sound missing In-Reply-To: Message-ID: Does anyone have ideas on where to look in my build environment to solve an otherwise well-working trunk compile that has no sound? I'm MSVS 2005 Express, running on Win XP 32. Cheers, Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Vector Hastings Sent: Friday, March 06, 2009 1:16 AM To: Ambrosia Cc: sldev@lists.secondlife.com Subject: RE: [sldev] Help with setting up Shadow Build You guys are great! Thanks for the compassion Ambrosia. That sets up the environment fabulously! (I'm obviously pretty green at this.) Now on to compiling ;-D Vector -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Ambrosia Sent: Thursday, March 05, 2009 11:51 PM To: Vector Hastings Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Help with setting up Shadow Build Vector: see the file doc/asset_urls.txt in there are URLs to the artwork and libs you need to add. On Fri, Mar 6, 2009 at 07:36, Vector Hastings wrote: > Thanks for everyone's help! > > The new tarball seems to fix that problem, now I'm onto umpteen of these: > > "CMake Error: Cannot find source file > "C:/SL_SD2_Trunk/indra/build-VC80/newview/r > es/arrow.cur" > > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .i > n .txx" > > A quick look on google suggests missing artwork (??) > > If that's the case, Any ideas on where I can snag the right stuff and update > the install script to use it? > > Thanks again to all, > > Vector > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Soft > Sent: Thursday, March 05, 2009 6:26 PM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Help with setting up Shadow Build > > > On Thu, Mar 5, 2009 at 7:45 PM, Soft wrote: >> On Thu, Mar 5, 2009 at 11:24 AM, Thomas Shikami >> wrote: >>> Vector Hastings wrote: >>>> >>>> "RuntimeError: Error matching md5 for >>>> >>>> > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-windows-2008 >>>> 0613.tar.bz2" >>>> >>>> I don't know much about this, but looks like I'm getting the wrong >>>> hash-totals or some similar control. Have the files changed? Is there an >>>> environment gotcha? >>>> >>> >>> someone uploaded another GL-windows-20080613.tar.bz2 and overwrote the >>> correct file invalidating the checksum of older install.xml >> >> That's apparently what happened here. I sent a note to the internal >> engineer list asking them to never reuse filenames here, and >> explaining what happened. >> >> Unfortunately, I don't know where to get a copy of the old library >> bundle unless the dev who first uploaded it steps forward. I'd be very >> surprised if the new one didn't work though, checksum aside. > > Okay, following up on this -- > * The old bundle has been found and is being put back in place > * The install.xml will be updated to point to a new location for the new > bundle > > > > > _______________________________________________ > 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 _______________________________________________ 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 suzyq at pobox.com Sat Mar 7 07:17:07 2009 From: suzyq at pobox.com (Suzy Deffeyes) Date: Sat Mar 7 07:17:11 2009 Subject: [sldev] Inventory caps Message-ID: <2bd5b7f10903070717w581f00c3y4be3ca6b37308158@mail.gmail.com> I've been looking at the inventory related caps in the viewer. FetchInventory WebFetchInventoryDescendents FetchLib FetchLibDescendents Does this code work in the viewer if a grid has it enabled? I tried Agni and Aditi, but did not get them as caps. Is there a test grid I could try? WebFetchInventoryDescendents - Is this the same as FetchInventoryDescendents was? If not, how is it different? in LLInventoryModel::bulkFetch(), I find a uuid being sent as a string folder_sd["folder_id"] = LLUUID::null.asString(); Why in this one special case is it a string unstead of UUID? Also, it looks like the null UUID has special meaning of "Lost" items. Is this correct? In ll_permissions_from_sd(), masks are being done using strings (since LLSD has no uint), and the mask in LLSaleInfo::fromLLSD() is done as a binary. Shouldn't all masks use consistent handling (or update LLSD to handle uints). ll_pretty_print_sd - when I print something that contains the null UUID, why does pretty print do it as instead of printing the actual UUID. Where does this special case occur, and is it a change in the bits sent to the region, or is it limited to functionality in the pretty print? Also, since I don't know of a test grid where these Inventory caps are deployed, I can't learn by looking at the traffic back and forth. My mechanism for defining what they can send/receive is limited to wading through code. Is there an easier way to do this that I am not aware of? Sorry for the laundry list of questions. Thanks Suzy Deffeyes/Pixel Gausman IBM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090307/e0727b50/attachment.htm From me at signpostmarv.name Sat Mar 7 21:18:55 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat Mar 7 21:19:45 2009 Subject: [sldev] history question: physics on the server- first for SL ? Message-ID: <49B3553F.3050108@signpostmarv.name> A question thats been bugging me lately: Was SL the first major (or ever) virtual world environment/mmo to simulate physics almost entirely on the server ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090308/0cc6bb5d/smime.bin From kf6kjg at gmail.com Sat Mar 7 21:23:06 2009 From: kf6kjg at gmail.com (Ricky) Date: Sat Mar 7 21:23:09 2009 Subject: [sldev] libexpat In-Reply-To: <9bb32d430903050055s3a5a283bo63ace5e666dd8a4e@mail.gmail.com> References: <3bb9647e0903041744x8972774if27175c1090da89d@mail.gmail.com> <200903050228.29496.lists.secondlife.com@trap.wereanimal.net> <3bb9647e0903050024k5627133bi964fec90f7ce102e@mail.gmail.com> <9bb32d430903050055s3a5a283bo63ace5e666dd8a4e@mail.gmail.com> Message-ID: <3bb9647e0903072123s6a42f2fbx4b9688b29052b62a@mail.gmail.com> scons... I guess it's time to re-evaluate some of my process... :D If I'm out of date on some other steps, please, anyone, make a note in my comments page! It'll be most appreciated! On my system I have dev-libs/expat installed. The latest version, according to my system, is installed at version 2.0.1-r1. An equery files dev-libs/expat gives the following symlinks and file: /usr/lib64/libexpat.so -> libexpat.so.1.5.2 /usr/lib64/libexpat.so.1 -> libexpat.so.1.5.2 /usr/lib64/libexpat.so.1.5.2 Searching my system returns the fact that, excepting some instances packaged with VMWare's Player, there is no libexpat.so.0, only libexpat.so.1. Does the viewer require both? Or is the old one being linked in by some mistake in my process or setup? Cron On Thu, Mar 5, 2009 at 12:55 AM, Ambrosia wrote: > On Thu, Mar 5, 2009 at 09:24, Ricky wrote: > > FYI: I fairly closely follow the build directions I posted on my user > page > > at http://wiki.secondlife.com/wiki/User:Cron_Stardust the only > exception > > to this is that I've disabled a patch and had to tweak a source file due > to > > a bad #if or three.... > A question, why do you emerge scons? The new build process doesn't use > it, AFAIK, since 1.21. > > > I can find no instance of libexpat.so.0 in my linden directory. (That's > > where I checked out trunk...) Not sure how it's decideing to link > against a > > practically non-existent lib... > > libexpat gets used in the XML parsing classes. Since you are building > a standalone build, judging by your user page, instead of using the > libraries LL provides in the cmake process, you need to emerge it. I > presume it doesn't get grabbed by cmake in standalone. Of course the > question remains why it doesn't complain in the first place during the > linking to the shared lib, instead of just...doing it. > > >> -- Techwolf Lupindo > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090307/57c3cd2d/attachment.htm From kf6kjg at gmail.com Sat Mar 7 21:37:00 2009 From: kf6kjg at gmail.com (Ricky) Date: Sat Mar 7 21:37:01 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: <49B3553F.3050108@signpostmarv.name> References: <49B3553F.3050108@signpostmarv.name> Message-ID: <3bb9647e0903072137i24ce3633jc5642d26a90273d@mail.gmail.com> Running physics client-side is asking for packet-hackers to cheat. Running it only on the server invites physics lag. Because of this dichotomy, most /games/ run most of the processing client-side, with server-side checks to try and catch cheaters. (Or so I understand..) This leads to an arms race... Expensive. SL was designed as an community cooperation and construction environment. (Again, or so I understand.) this makes the possibility of slight physics lag acceptable, as twitch skillz aren't needed. To me as a beginning software engineer who has studied a little into networking, I prefer all the physics being computed server-side. Less worries about cheaters. Yet there can still be issues. Ever played Halo online? Notice how that, unless you're host, you have to lead everybody by a bit more than normal? And that the distance you have to lead by is related to your ping to the host? In Halo, one of the clients is chosen as host. That lucky person gets to see everything in real-time. Everyone else sends shoot requests to the host and it processes them when it gets them. Sometimes up to 100+ milliseconds later. Whoops, miss. Now, note: I've never played Halo myself, but I've talked with many who have, and I hear this issue commonly. Another issue than cheating shows up if a game allows the clients to do ALL the physics. On my machine, I shoot and just barely head shot you, but on your machine, you just saw me and ducked behind a pillar in that 100ms of ping delay... Which computer is right? How do you programmatically choose? To me, I killed you. I even saw the bullet hit! But to you, you were nowhere near that bullet. Ugh. Wars have started over less.... Hopefully this mess clarifies things :D Cron Stardust. On Sat, Mar 7, 2009 at 9:18 PM, SignpostMarv Martin wrote: > A question thats been bugging me lately: Was SL the first major (or ever) > virtual world environment/mmo to simulate physics almost entirely on the > server ? > > > ~ Marv. > > _______________________________________________ > 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/20090307/deea2c05/attachment.htm From tom at streamsense.net Sat Mar 7 22:11:04 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Sat Mar 7 22:11:31 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: <3bb9647e0903072137i24ce3633jc5642d26a90273d@mail.gmail.com> References: <49B3553F.3050108@signpostmarv.name> <3bb9647e0903072137i24ce3633jc5642d26a90273d@mail.gmail.com> Message-ID: <49B36178.2030608@streamsense.net> Ricky wrote: > To me as a beginning software engineer who has studied a little into > networking, I prefer all the physics being computed server-side. Less > worries about cheaters. This accounts for a vast majority of lag on second life. Using the server to compute collisions for every agent on the sim... .... causes more CPU load exponentially for every agent .... causes a LOT more network utilisation (a packet for every collision, and for simply collisions that the viewer should be able to detect, and the CPU overheads associated with it) The only real reason why *avatar* physics aren't run client side is due to licensing of the physics engine... ~T From kf6kjg at gmail.com Sun Mar 8 08:39:49 2009 From: kf6kjg at gmail.com (Ricky) Date: Sun Mar 8 08:40:07 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: <49B36178.2030608@streamsense.net> References: <49B3553F.3050108@signpostmarv.name> <3bb9647e0903072137i24ce3633jc5642d26a90273d@mail.gmail.com> <49B36178.2030608@streamsense.net> Message-ID: <3bb9647e0903080839q67c1752fiaa384f5f1c86d3af@mail.gmail.com> Note that most networked applications don't send packets all the time. I don't for for certain if this is true or not for SL. What I have read about is only sending conglomerated packets of updates at a rate of about 10FPS. Clients (or in our case, the viewer,) interpolates motion between these 100ms average interval packets. The viewer at least does that... I've seen packets get lost, and my avvie just keep walking until it snaps back into position... Ricky On Sat, Mar 7, 2009 at 10:11 PM, Thomas Grimshaw wrote: > Ricky wrote: > >> To me as a beginning software engineer who has studied a little into >> networking, I prefer all the physics being computed server-side. Less >> worries about cheaters. >> > This accounts for a vast majority of lag on second life. > > Using the server to compute collisions for every agent on the sim... > .... causes more CPU load exponentially for every agent > .... causes a LOT more network utilisation (a packet for every collision, > and for simply collisions that the viewer should be able to detect, and the > CPU overheads associated with it) > > The only real reason why *avatar* physics aren't run client side is due to > licensing of the physics engine... > > ~T > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090308/55ae0f75/attachment.htm From dmahalko at gmail.com Mon Mar 9 16:59:27 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Mar 9 16:59:36 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: <49B3553F.3050108@signpostmarv.name> References: <49B3553F.3050108@signpostmarv.name> Message-ID: Many qualifiers here so this is hard to answer. SL was probably the first non-game "3D virtual world" with physics, period. If you allow 3D and even "2.5D" multiplayer games to count as a very limited sort of virtual world, where the interaction mainly is to run around shooting things and typing insults back and forth then no, it is not the first 3D virtual world with server-side physics at all. Server-side game physics existed all the way back to id's DOOM running on IPX and dialup. The physics were very simple, in terms of "you cannot run through walls, you get hurt if you fall a long ways or are crushed" but it was indeed all server-side. The game client merely sends information like "player is pressing the forward key" and it is up to the server to act on that and actually move the player. For games with just one or two people, it is possible for one person to play as the server machine with almost no latency, but historically 8 or more players doesn't work from a home-based server since the server must send and receive a large volume of data to all clients equally. Since most residential Internet service has capped outgoing speed vs incoming, a home game server can only handle up to the outgoing rate, which may only be about 4 people. More players than that requires a business T-1 or greater with equal speeds in and out from the game server. A five-year-old Unreal Tournament 2004 server hosting 32 players may be easily burning 1500 kbit outgoing and incoming at the same time (48 kbit per player), making it impossible to run from most home broadband available even now. This, by the way, is going to be a real problem if / when OpenSim becomes popular. A home OpenSim is not going to be able to handle more than maybe 4 people in the sim if your home broadband is capped at 512 kbit outgoing, even if the incoming speed is 5 megabit. If you want more people in your OpenSim you will need either a business internet connection to your house or put the server in a colocation facility ... in which case, why not stick with SL's already colo-hosted servers? (I really don't think anyone has thought this part of OpenSim through. Is it really going to be worth it to get a "free" sim that costs $xxx for the monthly colo bandwidth fees, on a rackmount server that costs $xxxx?) In most 3D multiplayer games, the information about the location and state of all players is sent to all clients, whether or not the player on the client can actually SEE the other players. It is too much work for the server to deal with 3D occlusion so all updates are sent for all game objects all the time. If you could somehow connect to the game and hide the 3D map completely you would see all players and game objects like guns and powerups floating around in empty space. A way to cheat at 3D games is to modify the game maps to put windows in walls to see into otherwise unseen nearby rooms and hallways. Although these windows are unknown to the server and cannot be fired through, this lets you gain an advantage to see the players moving around in parts of the map you should not normally see into, so you can fire a rocket at someone just about to come around a corner 50 yards away, etc. Servers do checksums on client game files to protect against this sort of 3D mapfile hacking. In this regard, SL is probably the first 3D multiplayer evironment to NOT send this data to everyone all the time, since it is just too much data and would overwhelm slower clients. AFAIK, SL doesn't do 3D occlusion checks either, but instead just uses your viewing distance and camera's view frustum to determine what updates it needs to send to your client. I have no idea if the hiding of small distant objects is part of this limiting of updates sent to clients. - Scalar Tardis / Dale Mahalko On Sat, Mar 7, 2009 at 11:18 PM, SignpostMarv Martin wrote: > A question thats been bugging me lately: Was SL the first major (or ever) > virtual world environment/mmo to simulate physics almost entirely on the > server ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090309/cfbe3585/attachment.htm From gcanaday at gmail.com Mon Mar 9 18:06:09 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Mon Mar 9 18:06:35 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: References: <49B3553F.3050108@signpostmarv.name> Message-ID: <200903092106.09244.gcanaday@gmail.com> > If you want more people in your OpenSim you will need either a business > internet connection to your house or put the server in a colocation > facility ... in which case, why not stick with SL's already colo-hosted > servers? (I really don't think anyone has thought this part of OpenSim > through. Is it really going to be worth it to get a "free" sim that costs > $xxx for the monthly colo bandwidth fees, on a rackmount server that costs > $xxxx?) > This will still be less than LL's colo / island rates, mostly because you will have to deal with the sim maintenance yourself and there will be no one there to manage your sim for you. If the fee is just for the space and bandwidth, I can see a lot of possible instability but quite a few people making quite a bit of money when their exchange is put into place. just my $0.02. --GC From sldev at free.fr Tue Mar 10 00:22:14 2009 From: sldev at free.fr (Henri Beauchamp) Date: Tue Mar 10 00:22:27 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: References: <49B3553F.3050108@signpostmarv.name> Message-ID: <20090310082214.b3b81fa4.sldev@free.fr> On Mon, 9 Mar 2009 17:59:27 -0600, Dale Mahalko wrote: > This, by the way, is going to be a real problem if / when OpenSim becomes > popular. A home OpenSim is not going to be able to handle more than maybe 4 > people in the sim if your home broadband is capped at 512 kbit outgoing, > even if the incoming speed is 5 megabit. In most towns, the current ADSL2+ connection speeds here (France) are 24Mbps downlink/1Mbps uplink (ATM bandwidth: the actual IP bandwidth is therefore around 15% less than these figures) and fiber optic connections (either 100% FO or mixed, FO to your building and coaxial cable to your appartment) offer 100MBps downlink/5MBps uplink... Plenty enough for OpenSim. :-P That's an advantage of "old Europe" countries over USA or other large countries: the population density is much higher and so is the comms networks density, meaning people are closer to the comms nodes, which in turn allows higher bandwidth to the end user. Henri. From secret.argent at gmail.com Tue Mar 10 01:02:02 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Mar 10 01:02:09 2009 Subject: [sldev] history question: physics on the server- first for SL ? In-Reply-To: References: <49B3553F.3050108@signpostmarv.name> Message-ID: <6105CC7B-1AAB-443C-A082-43121072C169@gmail.com> On 2009-03-09, at 18:59, Dale Mahalko wrote: > If you want more people in your OpenSim you will need either a > business internet connection to your house or put the server in a > colocation facility ... in which case, why not stick with SL's > already colo-hosted servers? Control. Flexibility. Different feature set. Security (eg, a sim in a firewalled subnet with VPN access from the clients). From soft at lindenlab.com Wed Mar 11 09:15:06 2009 From: soft at lindenlab.com (Soft) Date: Wed, 11 Mar 2009 11:15:06 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From ramzi at lindenlab.com Wed Mar 11 12:27:17 2009 From: ramzi at lindenlab.com (Ramzi) Date: Wed, 11 Mar 2009 12:27:17 -0700 Subject: [sldev] Deprecated protocol feature: stray colon in 500 response - 9 MAY 2009 In-Reply-To: <49AC5557.9010603@lindenlab.com> References: <49AC5557.9010603@lindenlab.com> Message-ID: <49B81095.5080000@lindenlab.com> Just as an update to this: as Rob mentioned, Linden Lab would give plenty of warning before changing the server infrastructure with a stray colon. With the release of Viewer 1.22 today, we are rolling out a new process for supporting certain Linden Lab viewers to connect to Second Life: * Viewer 1.22 (current version) * Viewer 1.21 (previous version), * and the latest release candidate (1.22 RC11). T Linden posted on the Second Life blog about this new level of predictability, along with a 30-day grace period to get the word out about the announcement: https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions This means the announcement period ends in 30 days, on 8-April-2009. After this, Linden Lab will schedule to phase out its official viewer 1.20. Since the normal "phase out" period is also 30 days, this means that after 8-May-2009, residents using the official viewer 1.20 will be blocked from connecting to Second Life (and prompted instead to upgrade to a newer version.) At that time, Linden Lab can believe that no 1.20 viewers will be trying to communicate to the server. Of course, as before, Linden Lab does not plan to block the login by any versions of un-official, open source viewers. Therefore, the change to server infrastructure described below will take place NO sooner than 9-May-2009. However, it will be scheduled for completion *on or after that date*. After that date, without warning, the server response may cease to contain a stray colon, and open source viewers based on the obsoleted EventPoll code of viewer 1.20 would cease to fully function at that time, without warning. I hope this clarifies the timeline. Thanks! Ramzi Linden Release Team Rob Lanphier wrote: > Hi folks, > > The current version of our server infrastructure for capabilities has a > misfeature in it, where 500 responses have a stray colon in them. > Capabilities are meant to be HTTP-compliant, but this stray colon is > not. However, that incompatibility is required to maintain > compatibility with 1.20.17 and earlier viewers (and their derivatives). > > Maintaining this situation is a pain, because coercing standards-based > infrastructure (like Apache) to do the wrong thing is a major pain. We > eventually would like to eliminate this aberration from our > infrastructure, but that would mean that older viewers would stop > working. We'll give you plenty of warning before actually changing this > infrastructure, but we figured it's best to get the technical > information out now so that this will hopefully be a moot point by the > time we announce a timeline. > > We're asking that everyone who has a viewer based on 1.20.17 and older > to either upgrade to a newer base revision of the viewer (e.g. 1.21 or > later) or apply a fix as described here: > https://wiki.secondlife.com/wiki/Deprecated_Protocol_Features#Deprecated_protocol_feature:__stray_colon_in_HTTP_500_responses_.28viewers_1.20.17_and_earlier.29 > > ...with patches attached here: > https://jira.secondlife.com/browse/VWR-12248 > > Thanks! > Rob > > From open at autistici.org Wed Mar 11 13:00:18 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 11 Mar 2009 20:00:18 +0000 Subject: [sldev] [HELP] [Linux] Warning while building 113976-RC Message-ID: I'm going to compile the current RC from sources on Linux Ubuntu 8.10. I just extracted the archives and ran develop.py script. I got not errors but this warning: Writing state to .../113976-RC/linden/installed.xml -- Version of viewer is 1.22.11.0 -- Configuring done CMake Warning at newview/CMakeLists.txt:1294 (add_executable): Cannot generate a safe linker search path for target secondlife-bin because files in some directories may conflict with libraries in implicit directories: link library [libGLU.so] in /usr/lib may be hidden by files in: .../113976-RC/linden/indra/../libraries/i686-linux/lib_release_client Some of these libraries may not be found correctly. -- Generating done -- Build files have been written to: .../113976-RC/linden/indra/viewer-linux-i686-relwithdebinfo BTW, libglu1-mesa-dev (7.2-1ubuntu2) is on my system. Should I worry about this kind of messages? report it on PJIRA? Is something missing/broken on my system in a critical way, or can I ignore this? Thanks in advance - in the meantime I'm going to try building and see. Best wishes, Opensource Obscure -- friendfeed.com/oobscure - twitter.com/oobscure From gcanaday at gmail.com Wed Mar 11 14:55:56 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Wed, 11 Mar 2009 17:55:56 -0400 Subject: [sldev] Odd warning signs that a release is coming In-Reply-To: References: Message-ID: <200903111755.56619.gcanaday@gmail.com> I just thought I'd note, as an aside... It's odd. Even if i do not watch the dev schedule, I always know where there is an imminent client release. Why? My crash rate goes waaaay up! This happened before the het grid when I was on a mac, in between when I fought with Vista, and even now on the Linux client (plz make a 64-bit build, I simply can't get it to build no matter what I do). This time, my sound quit working (used to work) and it would occasionally go down about twice a week without warning, and without taking X with it. Weird, huh... --GC From gcanaday at gmail.com Wed Mar 11 14:56:15 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Wed, 11 Mar 2009 17:56:15 -0400 Subject: [sldev] [HELP] [Linux] Warning while building 113976-RC Message-ID: <200903111756.15305.gcanaday@gmail.com> You got that far? you're my hero. --GC On Wednesday 11 March 2009 4:00:18 pm Opensource Obscure wrote: > I'm going to compile the current RC from sources on Linux Ubuntu 8.10. > > I just extracted the archives and ran develop.py script. I got not > errors but this warning: > > > Writing state to .../113976-RC/linden/installed.xml > -- Version of viewer is 1.22.11.0 > -- Configuring done > CMake Warning at newview/CMakeLists.txt:1294 (add_executable): > Cannot generate a safe linker search path for target secondlife-bin > because > files in some directories may conflict with libraries in implicit > directories: > > link library [libGLU.so] in /usr/lib may be hidden by files in: > .../113976-RC/linden/indra/../libraries/i686-linux/lib_release_client > > Some of these libraries may not be found correctly. > > -- Generating done > -- Build files have been written to: > .../113976-RC/linden/indra/viewer-linux-i686-relwithdebinfo > > > BTW, libglu1-mesa-dev (7.2-1ubuntu2) is on my system. > > Should I worry about this kind of messages? report it on PJIRA? > Is something missing/broken on my system in a critical way, or can > I ignore this? > > Thanks in advance - in the meantime I'm going to try building and see. > > Best wishes, > Opensource Obscure > -- > friendfeed.com/oobscure - twitter.com/oobscure > _______________________________________________ > 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 gcanaday at gmail.com Wed Mar 11 15:39:40 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Wed, 11 Mar 2009 18:39:40 -0400 Subject: [sldev] gstreamer In-Reply-To: References: Message-ID: <200903111839.40570.gcanaday@gmail.com> I just erased a huge rant relating to trying to use a 32-bit gstreamer on a 64-bit Linux installation. I'll just say this: it doesn't work and it will never work. At this point any streaming through the client at all brings it down like a sack of bricks the moment it is activated. I can't build my own client though I would love to. TYVM for the OpenAL sound-- I can finally use system sound and viewer sound at the same time. For the first time ever, in fact, and it's awesome! However, streaming just isn't going to happen. I would like to remove the gstreamer dependency completely and be allowed to choose my own streaming backend... for example, OpenAL / Jack / ?? / ALSA for system sounds and voice, gstreamer / xine / ?? / Phonon for streaming media. Has anyone here ever successfully compiled a 64-bit Linux client on Ubuntu 8.10? How? I'll bet that for the meantime, being able to do that will go a looooong way toward being able to get gstreamer to work until I can see about adding a backend switch. --GC From sean at lindenlab.com Wed Mar 11 15:48:49 2009 From: sean at lindenlab.com (Sean Linden) Date: Wed, 11 Mar 2009 15:48:49 -0700 Subject: [sldev] gstreamer In-Reply-To: <200903111839.40570.gcanaday@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> Message-ID: <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> On Wed, Mar 11, 2009 at 3:39 PM, Glen Canaday wrote: > I just erased a huge rant relating to trying to use a 32-bit gstreamer on a > 64-bit Linux installation. I'll just say this: it doesn't work and it will > never work. At this point any streaming through the client at all brings it > down like a sack of bricks the moment it is activated. > > I can't build my own client though I would love to. TYVM for the OpenAL > sound-- I can finally use system sound and viewer sound at the same time. > For > the first time ever, in fact, and it's awesome! > > However, streaming just isn't going to happen. I would like to remove the > gstreamer dependency completely and be allowed to choose my own streaming > backend... for example, OpenAL / Jack / ?? / ALSA for system sounds and > voice, > gstreamer / xine / ?? / Phonon for streaming media. > > Has anyone here ever successfully compiled a 64-bit Linux client on Ubuntu > 8.10? How? I'll bet that for the meantime, being able to do that will go a > looooong way toward being able to get gstreamer to work until I can see > about > adding a backend switch. > > I wish I had the time to attempt to do a build - I have the same problem - the viewer crashes immediately if I try to enable streaming. Voice works, but not using pulseaudio. I have to kill pulseaudio before starting SL, and if I don't need to use voice and I leave pulseaudio running, the viewer will frequently hang or cause other audio apps to hang, resulting in my needing to restart pulseaudio after quitting the viewer. I'm not *quite* regretting putting 64 bit Intrepid on my Macbook, but I occasionally wish I'd stuck with 32 bit when I'm trying to get into an in-world meeting in a hurry. Anyway, if I find the time/nerve/brains to attempt to do a build, I'll let you know how it turns out (I'm in ops, not dev). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090311/5b7f9a93/attachment.htm From I_really_needed_a_new_mailbox at gmx.de Wed Mar 11 16:24:56 2009 From: I_really_needed_a_new_mailbox at gmx.de (zai) Date: Thu, 12 Mar 2009 00:24:56 +0100 Subject: [sldev] [Wiki] Machine translations - feedback requested Message-ID: <1236813896.6272.28.camel@konsubuntu> Heyas! I recently made a change to a heavily used template in the SL Wiki and received both, very positive and negative feedback. So it is also requested to undo the change again. I'd like to request feedback to get some kind of community (or Linden) decision on this. In order to not be redundant, I wrote the description on the discussion page of the template. Interested parties please browse and reply at: https://wiki.secondlife.com/wiki/Template_talk:Multi-lang#Google_translation_links Thank you! zai -- https://wiki.secondlife.com/wiki/User:Zai_Lynch http://www.flickr.com/people/ZaiLynch http://www.youtube.com/ZaiLynch http://twitter.com/ZaiLynch From rgwells at techno-logix.com Wed Mar 11 16:26:36 2009 From: rgwells at techno-logix.com (Russell G. Wells) Date: Wed, 11 Mar 2009 16:26:36 -0700 Subject: [sldev] gstreamer In-Reply-To: <200903111839.40570.gcanaday@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> Message-ID: <200903111626.36323.rgwells@techno-logix.com> I tried getting a 64bit compile going on Kubuntu 8.04, but after about 3 weeks of trying I gave up. ?I installed a VM of 32bit Kubuntu 8.04 and just do 32bit builds. ? I get lots of crashed relating to streaming media and will be trying to troubleshoot these crashes. ?I can't even get voice to work at all. ? I think that getting a full 64bit build would be a good thing, but it's going to take a bit of work to get it stable (I think). ? Russell G. Wells On Wednesday 11 March 2009 15:39:40 Glen Canaday wrote: > I just erased a huge rant relating to trying to use a 32-bit gstreamer on a > 64-bit Linux installation. I'll just say this: it doesn't work and it will > never work. At this point any streaming through the client at all brings it > down like a sack of bricks the moment it is activated. > > I can't build my own client though I would love to. TYVM for the OpenAL > sound-- I can finally use system sound and viewer sound at the same time. > For the first time ever, in fact, and it's awesome! > > However, streaming just isn't going to happen. I would like to remove the > gstreamer dependency completely and be allowed to choose my own streaming > backend... for example, OpenAL / Jack / ?? / ALSA for system sounds and > voice, gstreamer / xine / ?? / Phonon for streaming media. > > Has anyone here ever successfully compiled a 64-bit Linux client on Ubuntu > 8.10? How? I'll bet that for the meantime, being able to do that will go a > looooong way toward being able to get gstreamer to work until I can see > about adding a backend switch. > > --GC > > _______________________________________________ > 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 gcanaday at gmail.com Wed Mar 11 17:30:43 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Wed, 11 Mar 2009 20:30:43 -0400 Subject: [sldev] gstreamer In-Reply-To: <200903111626.36323.rgwells@techno-logix.com> References: <200903111839.40570.gcanaday@gmail.com> <200903111626.36323.rgwells@techno-logix.com> Message-ID: <200903112030.43718.gcanaday@gmail.com> Won't even build for me. constantly complains about libraries and such that are actually there. The good news is that on my 64-bit ubuntu, everything *except* streaming works. I'm crashing, so stability isn't there, but the fact that things are mostly working is a huge step in the right direction. Sean - if you get a chance to try that, let me know how it works out. I can't make heads or tails of all the different things that go wrong with it. Last time I tried it it didn't like llmozlib. The installed mozlib conflicted with the ll one and prevented the build from going past that stage. the ubuntu lib ain't compatible with the ll changes I don't think. Also, forcing the LL version onto the system killed thunderbird and firefox. 1.22 is working, with voice, from the main linux DL. If either of you succeed, post your bash history from start to finish and I will copy/paste I swear it ;P --GC On Wednesday 11 March 2009 7:26:36 pm Russell G. Wells wrote: > I tried getting a 64bit compile going on Kubuntu 8.04, but after about 3 > weeks of trying I gave up. I installed a VM of 32bit Kubuntu 8.04 and just > do 32bit builds. > > I get lots of crashed relating to streaming media and will be trying to > troubleshoot these crashes. I can't even get voice to work at all. > > I think that getting a full 64bit build would be a good thing, but it's > going to take a bit of work to get it stable (I think). > > Russell G. Wells > > On Wednesday 11 March 2009 15:39:40 Glen Canaday wrote: > > I just erased a huge rant relating to trying to use a 32-bit gstreamer on > > a 64-bit Linux installation. I'll just say this: it doesn't work and it > > will never work. At this point any streaming through the client at all > > brings it down like a sack of bricks the moment it is activated. > > > > I can't build my own client though I would love to. TYVM for the OpenAL > > sound-- I can finally use system sound and viewer sound at the same time. > > For the first time ever, in fact, and it's awesome! > > > > However, streaming just isn't going to happen. I would like to remove the > > gstreamer dependency completely and be allowed to choose my own streaming > > backend... for example, OpenAL / Jack / ?? / ALSA for system sounds and > > voice, gstreamer / xine / ?? / Phonon for streaming media. > > > > Has anyone here ever successfully compiled a 64-bit Linux client on > > Ubuntu 8.10? How? I'll bet that for the meantime, being able to do that > > will go a looooong way toward being able to get gstreamer to work until I > > can see about adding a backend switch. > > > > --GC > > > > _______________________________________________ > > 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 open at autistici.org Wed Mar 11 18:11:42 2009 From: open at autistici.org (Opensource Obscure) Date: Thu, 12 Mar 2009 01:11:42 +0000 Subject: [sldev] [HELP] [Linux] Warning while building 113976-RC In-Reply-To: <200903111756.15305.gcanaday@gmail.com> References: <200903111756.15305.gcanaday@gmail.com> Message-ID: <33c9cf53193576926fa06c7a9af6385d@localhost> On Wed, 11 Mar 2009 17:56:15 -0400, Glen Canaday wrote: > You got that far? you're my hero. > > --GC Actually, I didn't go much far, at first at least: http://pastebin.ca/raw/1358595 However, apparently I could work around that by adding a "%s", at line 93 (before " dialog_text") in linden/indra/linux_crash_logger/llcrashloggerlinux.cpp I don't remember anymore what this error is due to. Wrong g++ version on my system? a non-fixed bug? A flag in the building commands I'm not using? By the way, I'm so ignorant that I can't even understand either the problem or the workaround I just remember someone mentioned here many months ago. It still works though, the viewer built correctly after that. But it doesn't compile out of the box, and this was on a common setup (Ubuntu 8.10 is widespread now, and I think this is an almost-vanilla installation). Best wishes, Opensource Obscure From johnniecarling at gmail.com Wed Mar 11 19:03:28 2009 From: johnniecarling at gmail.com (Johnnie Carling) Date: Wed, 11 Mar 2009 22:03:28 -0400 Subject: [sldev] [HELP] [Linux] Warning while building 113976-RC In-Reply-To: <33c9cf53193576926fa06c7a9af6385d@localhost> References: <200903111756.15305.gcanaday@gmail.com> <33c9cf53193576926fa06c7a9af6385d@localhost> Message-ID: <200903112203.28702.johnniecarling@gmail.com> > On Wed, 11 Mar 2009 17:56:15 -0400, Glen Canaday > I don't remember anymore what this error is due to. Wrong > g++ version on my system? a non-fixed bug? A flag in the > building commands I'm not using? By the way, I'm so ignorant > that I can't even understand either the problem or the workaround In indra/cmake/00-Common.cmake > Line 183 Just comment out set(GCC_WARNINGS "${GCC_WARNINGS} -Werror") -Werror is a good thing to set if your developing, however I just want the darn thing to compile. ;) Oh... I get the same error you posted earlier, never caused a problem so I just ignore it. (Debian sid) From carlo at alinoe.com Wed Mar 11 21:27:08 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 12 Mar 2009 05:27:08 +0100 Subject: [sldev] [HELP] [Linux] Warning while building 113976-RC In-Reply-To: <33c9cf53193576926fa06c7a9af6385d@localhost> References: <200903111756.15305.gcanaday@gmail.com> <33c9cf53193576926fa06c7a9af6385d@localhost> Message-ID: <20090312042708.GA4536@alinoe.com> On Thu, Mar 12, 2009 at 01:11:42AM +0000, Opensource Obscure wrote: > However, apparently I could work around that by adding a > "%s", > at line 93 (before " dialog_text") in > linden/indra/linux_crash_logger/llcrashloggerlinux.cpp > > I don't remember anymore what this error is due to. Wrong > g++ version on my system? a non-fixed bug? A flag in the > building commands I'm not using? By the way, I'm so ignorant > that I can't even understand either the problem or the workaround If you do printf("%s", str), then you avoid a crash in the case the 'str' contains a '%s' (or %d etc). In theory printf(fmt) is correct if fmt is a char* and does NEVER contain such formats. However, this has been the cause of many crashes and exploits, so gcc/g++ has the option to give you a warning when a non-literal format is being used. And correctly so, I believe it is much better (and safer) to use "%s" as format in such cases and pass the string 'fmt' as string parameter. -- Carlo Wood From carlo at alinoe.com Wed Mar 11 21:41:24 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 12 Mar 2009 05:41:24 +0100 Subject: [sldev] gstreamer In-Reply-To: <200903111626.36323.rgwells@techno-logix.com> References: <200903111839.40570.gcanaday@gmail.com> <200903111626.36323.rgwells@techno-logix.com> Message-ID: <20090312044124.GB4536@alinoe.com> On Wed, Mar 11, 2009 at 04:26:36PM -0700, Russell G. Wells wrote: > I tried getting a 64bit compile going on Kubuntu 8.04, but after about 3 weeks > of trying I gave up. ?I installed a VM of 32bit Kubuntu 8.04 and just do > 32bit builds. ? > > I get lots of crashed relating to streaming media and will be trying to > troubleshoot these crashes. ?I can't even get voice to work at all. ? > > I think that getting a full 64bit build would be a good thing, but it's going > to take a bit of work to get it stable (I think). ? My pure 64bit build is rock stable... well, crashes at most once every two days... It's not just the source that you use however, and how you compile it - it's also the shared libraries that you link with. In the beginning (a few months ago) I had special (custom) versions of several libraries -- but at the moment I'm using the (latest) official libraries... I think... lemme check... hikaru:build:omvviewer/indra/build/newview>ldd ./omvviewer linux-vdso.so.1 => (0x00007fff1a1fe000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007f9711aad000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007f9711882000) libogg.so.0 => /usr/lib/libogg.so.0 (0x00007f971167d000) libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x00007f9711476000) libm.so.6 => /lib/libm.so.6 (0x00007f97111f3000) libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007f9710cac000) libalut.so.0 => /usr/lib/libalut.so.0 (0x00007f9710aa5000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f9710821000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f971060a000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f9710408000) libboost_program_options-gcc42-mt-1_34_1.so.1.34.1 => /usr/lib/libboost_program_options-gcc42-mt-1_34_1.so.1.34.1 (0x00007f97101ce000) libboost_regex-gcc42-mt-1_34_1.so.1.34.1 => /usr/lib/libboost_regex-gcc42-mt-1_34_1.so.1.34.1 (0x00007f970ff20000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00007f970fcfe000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007f970fac0000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f970f87b000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f970f5b7000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007f970f332000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f9711ea3000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f970f12a000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f970ef0f000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f970ec03000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f970e9f2000) libllmozlib2.so.0 => /usr/lib/libllmozlib2.so.0 (0x00007f970e8c5000) libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007f970e60a000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f970e3ee000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007f970e1cd000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f970dfc9000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f970dd47000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007f970daac000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f970d891000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f970d685000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007f970d43a000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f970ce66000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f970cc62000) librt.so.1 => /lib/librt.so.1 (0x00007f970ca59000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f970c833000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007f970c606000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f970c3d5000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x00007f970c1c7000) libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x00007f970bfbf000) libXft.so.2 => /usr/lib/libXft.so.2 (0x00007f970bdab000) libxmlrpc-epi.so.0 => /usr/lib/libxmlrpc-epi.so.0 (0x00007f970bb99000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f970b977000) libopenjpeg.so.2 => /usr/lib/libopenjpeg.so.2 (0x00007f970b757000) libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 (0x00007f970b487000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x00007f970b12b000) libcurl-cares.so.4 => /usr/lib/libcurl-cares.so.4 (0x00007f970aee5000) libcares.so.2 => /usr/lib/libcares.so.2 (0x00007f970acd7000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f970aa86000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f970a6eb000) libboost_signals-gcc42-mt-1_34_1.so.1.34.1 => /usr/lib/libboost_signals-gcc42-mt-1_34_1.so.1.34.1 (0x00007f970a4d8000) libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007f970a2b5000) libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f970a082000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f9709e58000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f9709b4c000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f9709935000) libc.so.6 => /lib/libc.so.6 (0x00007f97095e1000) libdl.so.2 => /lib/libdl.so.2 (0x00007f97093dd000) libicui18n.so.38 => /usr/lib/libicui18n.so.38 (0x00007f970907f000) libicuuc.so.38 => /usr/lib/libicuuc.so.38 (0x00007f9708d3e000) libpcre.so.3 => /usr/lib/libpcre.so.3 (0x00007f9708b0f000) libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00007f9707a9d000) libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x00007f970799c000) libuuid.so.1 => /lib/libuuid.so.1 (0x00007f9707798000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00007f9707596000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f970737a000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f9707178000) libxpcom.so.0d => /usr/lib/libxpcom.so.0d (0x00007f9706f74000) libmozjs.so.0d => /usr/lib/libmozjs.so.0d (0x00007f9706ca8000) libnspr4.so.0d => /usr/lib/libnspr4.so.0d (0x00007f9706a6b000) libplc4.so.0d => /usr/lib/libplc4.so.0d (0x00007f9706866000) libplds4.so.0d => /usr/lib/libplds4.so.0d (0x00007f9706663000) libxul.so.0d => /usr/lib/libxul.so.0d (0x00007f97053e3000) libasound.so.2 => /usr/lib/libasound.so.2 (0x00007f9705106000) libdirectfb-1.0.so.0 => /usr/lib/libdirectfb-1.0.so.0 (0x00007f9704e8f000) libfusion-1.0.so.0 => /usr/lib/libfusion-1.0.so.0 (0x00007f9704c87000) libdirect-1.0.so.0 => /usr/lib/libdirect-1.0.so.0 (0x00007f9704a70000) libvga.so.1 => /usr/lib/libvga.so.1 (0x00007f9704811000) /lib64/ld-linux-x86-64.so.2 (0x00007f9711e85000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f97045cc000) libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007f97043c8000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f97041c0000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f9703fb7000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f9703dad000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f9703ba6000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f970399c000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f9703799000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f9703597000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f9703492000) libidn.so.11 => /usr/lib/libidn.so.11 (0x00007f970325f000) libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007f970303b000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0x00007f9702df2000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f9702bc6000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00007f97029b6000) libdb-4.6.so => /usr/lib/libdb-4.6.so (0x00007f970266c000) libpq.so.5 => /usr/lib/libpq.so.5 (0x00007f9702448000) libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15 (0x00007f9702039000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007f9701dc3000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f9701b8b000) libicudata.so.38 => /usr/lib/libicudata.so.38 (0x00007f9700eb4000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f9700caf000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00007f9700a4d000) libx86.so.1 => /lib/libx86.so.1 (0x00007f970082b000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00007f97005c3000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007f97004c0000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f97002a8000) libresolv.so.2 => /lib/libresolv.so.2 (0x00007f9700093000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00007f96ffe79000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00007f96ffbc7000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f96ff925000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f96ff6ff000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x00007f96ff4fc000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f96ff2f3000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00007f96ff0f1000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00007f96feee0000) Yup, see.. only "system" libraries. "system" between quotes, because several are still custom packages maintained by Robin Cornelius that I get with 'apt-get' from his site. The version I use is the version released by Linden Lab, but patched with 45 or so other patches: the OMV viewer. See http://omvviewer.byteme.org.uk/index.shtml for more info. -- Carlo Wood From jan.ciger at gmail.com Thu Mar 12 14:03:36 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 12 Mar 2009 22:03:36 +0100 Subject: [sldev] gstreamer In-Reply-To: <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> Message-ID: <49B978A8.70403@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean Linden wrote: > I wish I had the time to attempt to do a build - I have the same problem > - the viewer crashes immediately if I try to enable streaming. Voice > works, but not using pulseaudio. I have to kill pulseaudio before > starting SL, and if I don't need to use voice and I leave pulseaudio > running, the viewer will frequently hang or cause other audio apps to > hang, resulting in my needing to restart pulseaudio after quitting the > viewer. This issue with voice and pulseaudio is present in the 32bit build as well. For me, if I enable voice, the pulse server crashes after a short time resulting in an incredible racket (looping sample). Restarting pulse cures it, but then the client will lose sound until I restart it too. So voice is completely unusable on machines that are using pulseaudio right now. BTW, most modern distros are changing over to pulseaudio, so it would help to actually support it. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJuXion11XseNj94gRAtFbAJ9xNffWgDoiWzF1LXM1bjdtatQ9nwCgnPOe CfywLeGGl4OVJSJa0pxCDpA= =AMPz -----END PGP SIGNATURE----- From gcanaday at gmail.com Thu Mar 12 15:35:59 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Thu, 12 Mar 2009 18:35:59 -0400 Subject: [sldev] gstreamer In-Reply-To: <49B978A8.70403@gmail.com> References: <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> Message-ID: <200903121835.59603.gcanaday@gmail.com> What to do for video, then? --GC (sry for the dupe Jan, I meant to send to the list only) On Thursday 12 March 2009 5:03:36 pm Jan Ciger wrote: > Sean Linden wrote: > > I wish I had the time to attempt to do a build - I have the same problem > > - the viewer crashes immediately if I try to enable streaming. Voice > > works, but not using pulseaudio. I have to kill pulseaudio before > > starting SL, and if I don't need to use voice and I leave pulseaudio > > running, the viewer will frequently hang or cause other audio apps to > > hang, resulting in my needing to restart pulseaudio after quitting the > > viewer. > > This issue with voice and pulseaudio is present in the 32bit build as > well. For me, if I enable voice, the pulse server crashes after a short > time resulting in an incredible racket (looping sample). Restarting > pulse cures it, but then the client will lose sound until I restart it > too. So voice is completely unusable on machines that are using > pulseaudio right now. BTW, most modern distros are changing over to > pulseaudio, so it would help to actually support it. > > Regards, > > Jan From vector at leafpile.com Thu Mar 12 17:46:24 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu, 12 Mar 2009 17:46:24 -0700 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <49B978A8.70403@gmail.com> Message-ID: Does anyone have or know where to find KirstenLee's source for his SD5 release? I'm messing with it because he fixed a lot of problems with the shadowdraft code that's in the trunk (one is at https://jira.secondlife.com/browse/VWR-12314 ), but the SD2 version I have doesn't have the latest scripting commands. Seems like I need a boat, oars, and an ocean, but I can only seem to assemble two together at any one time. :-\ I spoke with KirstenLee today, but he just said he's retired, doesn't want to deal with any more sourcedrops. Thanks to anyone who can help. Vector From khyota at redhyena.net Thu Mar 12 18:53:52 2009 From: khyota at redhyena.net (Khyota) Date: Thu, 12 Mar 2009 21:53:52 -0400 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: References: Message-ID: <200903122153.52931.khyota@redhyena.net> On Thursday 12 March 2009 8:46:24 Vector Hastings wrote: > Does anyone have or know where to find KirstenLee's source for his SD5 > release? > > I'm messing with it because he fixed a lot of problems with the shadowdraft > code that's in the trunk (one is at > https://jira.secondlife.com/browse/VWR-12314 ), but the SD2 version I have > doesn't have the latest scripting commands. Seems like I need a boat, oars, > and an ocean, but I can only seem to assemble two together at any one time. > > :-\ > > I spoke with KirstenLee today, but he just said he's retired, doesn't want > to deal with any more sourcedrops. > > Thanks to anyone who can help. > > Vector > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges He posted it as an ever convienient RAR archive here. http://www.armyof4.com/Kirstenlee/ Khyota From khyota at redhyena.net Thu Mar 12 19:02:29 2009 From: khyota at redhyena.net (Khyota) Date: Thu, 12 Mar 2009 22:02:29 -0400 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: References: Message-ID: <200903122202.29410.khyota@redhyena.net> On Thursday 12 March 2009 8:46:24 Vector Hastings wrote: > I spoke with KirstenLee today, but he just said he's retired, doesn't want > to deal with any more sourcedrops. > > Thanks to anyone who can help. > > Vector > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges Yes apparently Kirsten thought it was easier to stop development then comply with the GPL and release the source code. Make me wonder what he wanted to hide. Khyota From tigrospottystripes at gmail.com Thu Mar 12 19:05:12 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 12 Mar 2009 23:05:12 -0300 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <200903122202.29410.khyota@redhyena.net> References: <200903122202.29410.khyota@redhyena.net> Message-ID: <49B9BF58.1060503@Gmail.com> I thought the issue was only about the source code for older versions.... Khyota escreveu: > On Thursday 12 March 2009 8:46:24 Vector Hastings wrote: > > >> I spoke with KirstenLee today, but he just said he's retired, doesn't want >> to deal with any more sourcedrops. >> >> Thanks to anyone who can help. >> >> Vector >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > Yes apparently Kirsten thought it was easier to stop development then comply > with the GPL and release the source code. Make me wonder what he wanted to > hide. > > Khyota > _______________________________________________ > 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 jan.ciger at gmail.com Fri Mar 13 00:16:11 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 13 Mar 2009 08:16:11 +0100 Subject: [sldev] gstreamer In-Reply-To: <200903121835.14113.gcanaday@gmail.com> References: <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <200903121835.14113.gcanaday@gmail.com> Message-ID: <49BA083B.4070200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Glen Canaday wrote: > What to do for video, then? What has video to do with voice? The two are unrelated (voice doesn't use gstreamer for anything, it is completely a Vivox issue). I was only completing the info from Sean Linden on the voice problem. BTW, in your case, I would strongly suggest to use your own 64bit version of gstreamer. That may fix many of the crashes you are having. Mixing 32bit and 64bit libraries is rarely good idea. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJugg7n11XseNj94gRAvfFAJ0aEWpqoKooXuxwkFZxt18KmFh8TQCgt9US KH3K5OpiuBsH4owqFGZWcLg= =2bOL -----END PGP SIGNATURE----- From sldev at free.fr Fri Mar 13 02:21:45 2009 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 13 Mar 2009 10:21:45 +0100 Subject: [sldev] gstreamer In-Reply-To: <49B978A8.70403@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> Message-ID: <20090313102145.47eac843.sldev@free.fr> On Thu, 12 Mar 2009 22:03:36 +0100, Jan Ciger wrote: > Sean Linden wrote: > > > I wish I had the time to attempt to do a build - I have the same problem > > - the viewer crashes immediately if I try to enable streaming. Voice > > works, but not using pulseaudio. I have to kill pulseaudio before > > starting SL, and if I don't need to use voice and I leave pulseaudio > > running, the viewer will frequently hang or cause other audio apps to > > hang, resulting in my needing to restart pulseaudio after quitting the > > viewer. > > This issue with voice and pulseaudio is present in the 32bit build as > well. For me, if I enable voice, the pulse server crashes after a short > time resulting in an incredible racket (looping sample). Restarting > pulse cures it, but then the client will lose sound until I restart it > too. So voice is completely unusable on machines that are using > pulseaudio right now. BTW, most modern distros are changing over to > pulseaudio, so it would help to actually support it. I personally got all audio device usage conflicts solved by getting rid of ALSA and *all* sound wrappers/daemons (pulseaudio, esd, jackit, arts, you name it) and installing OSS v4.1 (http://www.opensound.com/oss.html). OSS got a transparent software mixer: any number of programs may use /dev/dsp for example, and OSS takes care about mixing up everything transparently for them. You will never get "in use audio device" problems. Beside, the OSS sound drivers are much better than ALSA's, and OSS is now Open Source as well, so why bothering with buggy ALSA and sound wrappers/daemons any more ?... Henri. From jan.ciger at gmail.com Fri Mar 13 04:38:15 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 13 Mar 2009 12:38:15 +0100 Subject: [sldev] gstreamer In-Reply-To: <20090313102145.47eac843.sldev@free.fr> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <20090313102145.47eac843.sldev@free.fr> Message-ID: <49BA45A7.1040100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henri Beauchamp wrote: > I personally got all audio device usage conflicts solved by getting rid > of ALSA and *all* sound wrappers/daemons (pulseaudio, esd, jackit, arts, > you name it) and installing OSS v4.1 (http://www.opensound.com/oss.html). > Henri, that is unfortunately not an option for the majority of Linux users. They do not have neither the skills nor the means to install this version of OSS. Distros will not ship it, because it is not free (libre) software. The current trend is the standardization on PulseAudio that provides more features than just software mixing - e.g. transparent moving of audio streams between devices (SL using speakers, but when I want to use voice, I could move the sound to my headset instead), hot plugging of devices and many other things. I am not advocating Pulse here, it has its own share of problems (mainly stability), but it seems to be the emerging standard sound system on Linux. Fedora, Ubuntu, Mandriva all ship it by default, Suse probably too. SL works with PulseAudio quite fine because Pulse behaves as both Alsa device if a plugin is installed (e.g. Ubuntu and Mandriva does that by default) and can provide also the esound (esd) API. The only part that is not working right is the voice part - the chosen device is ignored (e.g. I ask voice to play on headphones, but it still comes out of the speakers) and enabled voice crashes the PulseAudio server after a while. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJukWjn11XseNj94gRAq/8AJ9Vobj6irGUFyS6nbrwXMT9bquJTQCfVdTI 8nlEuq2uti5aiTEyEMEu2Cg= =xkgK -----END PGP SIGNATURE----- From soft at lindenlab.com Fri Mar 13 06:14:28 2009 From: soft at lindenlab.com (Soft) Date: Fri, 13 Mar 2009 08:14:28 -0500 Subject: [sldev] Webkit versus Second Life Message-ID: Watching an Apple Safari/Webkit developer intro talk, they did something pretty cool: They demonstrated that you can fetch and build Webkit using nothing but your mouse. They assume you have the developer tools and subversion installed. The rest is su-and-say enough that you can just copy and paste three lines from the browser. One to do the svn fetch, one to build, and one to launch the built app. We're pretty far away from that. We rely on a handful of libraries that we can't provide on our own. We need some extra development tools installed. We have library and artwork bundles apart from the source bundle. We have separate steps for configuring and for building. An awful lot of new devs get lost somewhere in the process. Of all the above, if we were going to focus on knocking out just one step next, which do you think would be most valuable? Which is the highest hurdle? Another cool thing they do is making sure the nightly builds are completely stand-alone. Testing a build is as simple as unpacking a zip file and running a file in the contents - no installers permitted, no writing to files outside that directory. The idea is that it's possible to keep an array of nightlies and binary chop through versions to find regressions. Mac and Linux are pretty much at this stage. Would this be preferable for Windows BSI nightlies? From nik at terminaldischarge.net Fri Mar 13 08:28:25 2009 From: nik at terminaldischarge.net (Nik Radford) Date: Fri, 13 Mar 2009 08:28:25 -0700 (PDT) Subject: [sldev] Webkit versus Second Life Message-ID: <0d34cb0e958e62e9e41e6b1c4003a8d9.squirrel@webmail.terminaldischarge.net> > Watching an Apple Safari/Webkit developer intro talk, they did > something pretty cool: They demonstrated that you can fetch and build > Webkit using nothing but your mouse. They assume you have the > developer tools and subversion installed. The rest is su-and-say > enough that you can just copy and paste three lines from the browser. > One to do the svn fetch, one to build, and one to launch the built > app. > > We're pretty far away from that. We rely on a handful of libraries > that we can't provide on our own. We need some extra development tools > installed. We have library and artwork bundles apart from the source > bundle. We have separate steps for configuring and for building. An > awful lot of new devs get lost somewhere in the process. > > Of all the above, if we were going to focus on knocking out just one > step next, which do you think would be most valuable? Which is the > highest hurdle? > > > Another cool thing they do is making sure the nightly builds are > completely stand-alone. Testing a build is as simple as unpacking a > zip file and running a file in the contents - no installers permitted, > no writing to files outside that directory. The idea is that it's > possible to keep an array of nightlies and binary chop through > versions to find regressions. Mac and Linux are pretty much at this > stage. Would this be preferable for Windows BSI nightlies? I'd find it preferable, if I was taking the nightlies. > _______________________________________________ > 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 carlo at alinoe.com Fri Mar 13 08:52:14 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 13 Mar 2009 16:52:14 +0100 Subject: [sldev] Webkit versus Second Life In-Reply-To: References: Message-ID: <20090313155214.GA26128@alinoe.com> On Fri, Mar 13, 2009 at 08:14:28AM -0500, Soft wrote: > Watching an Apple Safari/Webkit developer intro talk, they did > something pretty cool: They demonstrated that you can fetch and build > Webkit using nothing but your mouse. They assume you have the > developer tools and subversion installed. The rest is su-and-say > enough that you can just copy and paste three lines from the browser. > One to do the svn fetch, one to build, and one to launch the built > app. That is bullshit; each pasted command can start a plethora of other commands. I could write a script that downloads, build, installs AND starts SecondLife - including all shared libraries if you wish and call it "we_are_so_cool". Then you "beat" Apple Safari/Webkit: just ONE line to paste! > We're pretty far away from that. We rely on a handful of libraries > that we can't provide on our own. We need some extra development tools > installed. We have library and artwork bundles apart from the source > bundle. We have separate steps for configuring and for building. I consider most of that a plus! Having a "black box" means less flexibility and ONLY works in a FULLY (version) controlled environment. Microsoft and Apple already (attempt to) do that (and still fail often -- except during a presentation). Linux has chosen a different path. I strongly believe that a non-black box, and flexibility is worth more than a "one click" process that either works or not (that being said, I AM author of a few auto-magic scripts like http://www.xs4all.nl/~carlo17/howto/build-nvidia-kernel and http://www.xs4all.nl/~carlo17/vvinstall2 Look at those scripts to have an idea how "cool/good" one-click installations are... Do you really want this? Nevertheless, I wrote those for end-users that otherwise would simply have nothing at all. Developers should be able to understand each step. The more steps the better. What we NEED is a HOWTO that explains every step in detail (and thus, many copy&paste lines). Most of my HOWTO's are that way, look for example at http://www.xs4all.nl/~carlo17/howto/encode.html or http://www.xs4all.nl/~carlo17/svn/index.html with many little copy&paste blocks instead of one-script-fits-all. > An awful lot of new devs get lost somewhere in the process. > > Of all the above, if we were going to focus on knocking out just one > step next, which do you think would be most valuable? Which is the > highest hurdle? A new developer has NO value unless he has an overview of the process, the components involved and how everything hangs together. New developers need to learn a lot of things. The best way to learn is by doing. Changing a whole install/compile step to a one-click won't make them any wiser and they will be of no value imho. Nevertheless-- I can answer your question ;). The answer is *precisely* what the Open Metaverse Viewer project's goal is: * Only use opensource components and to remove any non-free dependencies. Your next step should be get rid of any closed source third-party libraries/software. Then we need a webpage that outlines each step for new developers to follow, rather than one powerful script. We (OMV developers) ran into this too, so you can have a look at our first attempts to outline things that need to be done on http://omvviewer.byteme.org.uk/source.shtml (courtesy Robin Cornelius) and in more detail http://omvviewer.byteme.org.uk/git.shtml > Another cool thing they do is making sure the nightly builds are > completely stand-alone. Testing a build is as simple as unpacking a > zip file and running a file in the contents - no installers permitted, > no writing to files outside that directory. The idea is that it's > possible to keep an array of nightlies and binary chop through > versions to find regressions. Mac and Linux are pretty much at this > stage. Would this be preferable for Windows BSI nightlies? -- Carlo Wood From open at autistici.org Fri Mar 13 09:37:25 2009 From: open at autistici.org (Opensource Obscure) Date: Fri, 13 Mar 2009 16:37:25 +0000 Subject: [sldev] Webkit versus Second Life In-Reply-To: References: Message-ID: <44f9449f0fe10d8e3735fd0596fd0257@localhost> On Fri, 13 Mar 2009 08:14:28 -0500, Soft wrote: > We're pretty far away from that. We rely on a handful of libraries > that we can't provide on our own. We need some extra development tools > installed. We have library and artwork bundles apart from the source > bundle. We have separate steps for configuring and for building. An > awful lot of new devs get lost somewhere in the process. > > Of all the above, if we were going to focus on knocking out just one > step next, which do you think would be most valuable? Which is the > highest hurdle? Personally, preparing your system to build the viewer. That is, not only installing all libraries and dev tools, but also checking their versions, and sometimes having to install a specific version - one that could then easily conflict with the one present by default on my system. I'm fine with getting all the bundles and using the develop.py script. I can also live with the fact that the resulting .bz2 file is created in a deep-level directory - it's not a big deal (its location is printed in the last lines of the building process output). I don't see any other big hurdle. Understanding that to avoid a certain build error I need to use a specific version of a software (different than the one provided by my system by defult) was someway harder and more problematic. This problem is even harder when docs are not complete and out-of-date. I'm fine with following long and detailed step-by-step instructions - but again, I get that it's hard to write this kind of instructions when we have to deal with many different distros (talking about Linux here, as it's the only environment I use). Once again, please note that I'm probably less competent than most people on this list: I'm not a developer and I never wrote a patch - I just download the sources and try to build them, 1) because I'm curious about future viewer features, 2) to help spotting and reporting bugs, 3) to apply existing patches that haven't already been fixed in the official branches. HTH, Opensource Obscure p.s. I could build from trunk and there are shadows all over SL now! w00t! From sldev at free.fr Fri Mar 13 09:47:57 2009 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 13 Mar 2009 17:47:57 +0100 Subject: [sldev] gstreamer In-Reply-To: <49BA45A7.1040100@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <20090313102145.47eac843.sldev@free.fr> <49BA45A7.1040100@gmail.com> Message-ID: <20090313174757.d2b35111.sldev@free.fr> On Fri, 13 Mar 2009 12:38:15 +0100, Jan Ciger wrote: > Henri Beauchamp wrote: > > > I personally got all audio device usage conflicts solved by getting rid > > of ALSA and *all* sound wrappers/daemons (pulseaudio, esd, jackit, arts, > > you name it) and installing OSS v4.1 (http://www.opensound.com/oss.html). > > > > Henri, that is unfortunately not an option for the majority of Linux > users. They do not have neither the skills nor the means to install this > version of OSS. Did you try it at all ??? I doubt so... It's as simple as downloading a package from OSS website and installing it, just like you do with your distro packaging mechanism (RPM and DEB and TAR are provided)... And if your packaging mechanism is not supported, you got an auto-extractible package (just run it and it will do the rest). > Distros will not ship it, because it is not free (libre) > software. Sorry, but OSS v4 *is* Open Source... http://developer.opensound.com/sources/ My bet is that given how more performant and easy is OSS (not to mention the OSS API has been around since day one of audio support in Linux and all software support it), it will replace the buggy, extremely flacky and unfriendly ALSA in the future. With OSS, you can get rid of *all* the stupid sound daemons and not have to worry if this or that software will support them. Henri. From brad at lindenlab.com Fri Mar 13 11:05:51 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Fri, 13 Mar 2009 11:05:51 -0700 Subject: [sldev] s/maint-render/render-pipeline/g Message-ID: <49BAA07F.5070605@lindenlab.com> There's been a bit of discussion internally lately, and we came to the conclusion that maint-render has had a lot going on in it that doesn't count as simply maintenance (for example when shadow-draft merged into it). To reflect that the ongoing work on the renderer is generally in the form of larger scale projects, we've renamed the maint-render branch series to be render-pipeline. So, render-pipeline-1 (I believe exporting as I write this) is what would have been maint-render-12. In summary, if you've been tracking the maint-render branches, they're now called render-pipeline, so have at it... cheers, -Brad From sllists at boroon.dasgupta.ch Fri Mar 13 12:08:14 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 13 Mar 2009 20:08:14 +0100 Subject: [sldev] Standalone BSI nightlies on Windows (was: Webkit versus Second Life) In-Reply-To: References: Message-ID: <49BAAF1E.80908@boroon.dasgupta.ch> Soft schrieb: > [...] > > Another cool thing they do is making sure the nightly builds are > completely stand-alone. Testing a build is as simple as unpacking a > zip file and running a file in the contents - no installers permitted, > no writing to files outside that directory. The idea is that it's > possible to keep an array of nightlies and binary chop through > versions to find regressions. Mac and Linux are pretty much at this > stage. Would this be preferable for Windows BSI nightlies? This question is probably better asked at the BSI list, as not all nightly build users/testers are on SLDev, so I'm cross posting this. cheers Boroondas From vector at leafpile.com Fri Mar 13 15:54:04 2009 From: vector at leafpile.com (Vector Hastings) Date: Fri, 13 Mar 2009 15:54:04 -0700 Subject: [sldev] Webkit versus Second Life In-Reply-To: <20090313155214.GA26128@alinoe.com> Message-ID: I would quibble with what seems to me to be the overly harsh and single-minded assessment of "A new developer has NO value unless he has an overview of the process, the components involved and how everything hangs together." So you must understand how photons are released during the excitation of atoms before using an optical mouse? To get personal for a moment... I'm an example of someone who has a non-development need to delve into the opensource end of SL. I'm making a machinima that demands some features that really aren't available as-is and probably won't ever become stuff you'll find on the advanced menu. The fact that SL is OpenSource is part of why I felt comfortable choosing SL as this platform, because I knew if we ran into these kinds of needs, solutions would be possible. And I share the feeling Obscuro mentions of being a little fish at this table, since I never learned C++ and becoming expert at is isn't on my priority list. But at the same time I'd defend what we're doing as valuable even if we only find bugs in the software that's coming down the pipe. Part of the 'open' in OpenSource is to invite a larger tent and make us all feel welcome. Which includes encouraging people to get up and running as quickly as possible. So I salute what Soft is trying to achieve. That said, I concur with the general point that the automation machine can become part of the problem in getting started when it goes off the rails. The develop.py script we have today is an example that has often left me stuck with no real idea of why. I know when I first set up my environment, I think the biggest hill to climb was sorting through the competing documentations, because that was when 1.20 was giving way to 1.21 and Cmake, so I was mixing up my instructions between the two. After that, it was develop.py script errors, and after that hunting down the third party libraries (because again, that meant tackling different documentation at each provider). Hope that's helpful. Vector -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Carlo Wood Sent: Friday, March 13, 2009 8:52 AM To: Soft Cc: sldev Subject: Re: [sldev] Webkit versus Second Life On Fri, Mar 13, 2009 at 08:14:28AM -0500, Soft wrote: > Watching an Apple Safari/Webkit developer intro talk, they did > something pretty cool: They demonstrated that you can fetch and build > Webkit using nothing but your mouse. They assume you have the > developer tools and subversion installed. The rest is su-and-say > enough that you can just copy and paste three lines from the browser. > One to do the svn fetch, one to build, and one to launch the built > app. That is bullshit; each pasted command can start a plethora of other commands. I could write a script that downloads, build, installs AND starts SecondLife - including all shared libraries if you wish and call it "we_are_so_cool". Then you "beat" Apple Safari/Webkit: just ONE line to paste! > We're pretty far away from that. We rely on a handful of libraries > that we can't provide on our own. We need some extra development tools > installed. We have library and artwork bundles apart from the source > bundle. We have separate steps for configuring and for building. I consider most of that a plus! Having a "black box" means less flexibility and ONLY works in a FULLY (version) controlled environment. Microsoft and Apple already (attempt to) do that (and still fail often -- except during a presentation). Linux has chosen a different path. I strongly believe that a non-black box, and flexibility is worth more than a "one click" process that either works or not (that being said, I AM author of a few auto-magic scripts like http://www.xs4all.nl/~carlo17/howto/build-nvidia-kernel and http://www.xs4all.nl/~carlo17/vvinstall2 Look at those scripts to have an idea how "cool/good" one-click installations are... Do you really want this? Nevertheless, I wrote those for end-users that otherwise would simply have nothing at all. Developers should be able to understand each step. The more steps the better. What we NEED is a HOWTO that explains every step in detail (and thus, many copy&paste lines). Most of my HOWTO's are that way, look for example at http://www.xs4all.nl/~carlo17/howto/encode.html or http://www.xs4all.nl/~carlo17/svn/index.html with many little copy&paste blocks instead of one-script-fits-all. > An awful lot of new devs get lost somewhere in the process. > > Of all the above, if we were going to focus on knocking out just one > step next, which do you think would be most valuable? Which is the > highest hurdle? A new developer has NO value unless he has an overview of the process, the components involved and how everything hangs together. New developers need to learn a lot of things. The best way to learn is by doing. Changing a whole install/compile step to a one-click won't make them any wiser and they will be of no value imho. Nevertheless-- I can answer your question ;). The answer is *precisely* what the Open Metaverse Viewer project's goal is: * Only use opensource components and to remove any non-free dependencies. Your next step should be get rid of any closed source third-party libraries/software. Then we need a webpage that outlines each step for new developers to follow, rather than one powerful script. We (OMV developers) ran into this too, so you can have a look at our first attempts to outline things that need to be done on http://omvviewer.byteme.org.uk/source.shtml (courtesy Robin Cornelius) and in more detail http://omvviewer.byteme.org.uk/git.shtml > Another cool thing they do is making sure the nightly builds are > completely stand-alone. Testing a build is as simple as unpacking a > zip file and running a file in the contents - no installers permitted, > no writing to files outside that directory. The idea is that it's > possible to keep an array of nightlies and binary chop through > versions to find regressions. Mac and Linux are pretty much at this > stage. Would this be preferable for Windows BSI nightlies? -- Carlo Wood _______________________________________________ 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 thomas.shikami at online.de Fri Mar 13 16:38:39 2009 From: thomas.shikami at online.de (Thomas Shikami) Date: Sat, 14 Mar 2009 00:38:39 +0100 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <49B9BF58.1060503@Gmail.com> References: <200903122202.29410.khyota@redhyena.net> <49B9BF58.1060503@Gmail.com> Message-ID: <49BAEE7F.9030408@online.de> Tigro Spottystripes wrote: > I thought the issue was only about the source code for older versions.... > The issue is about KirstenLee distributing binaries of OpenLife without providing sources for it. KirstenLee took the binaries down, but still does not comply with releasing sources. From gcanaday at gmail.com Fri Mar 13 16:43:14 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Fri, 13 Mar 2009 19:43:14 -0400 Subject: [sldev] gstreamer In-Reply-To: <20090313174757.d2b35111.sldev@free.fr> References: <49BA45A7.1040100@gmail.com> <20090313174757.d2b35111.sldev@free.fr> Message-ID: <200903131943.14828.gcanaday@gmail.com> ALSA was originally written to replace the OSS system in the kernel for the 2.2 kernel series because the OSS stuff had a lot of legacy cruft in it and it was becoming increasingly hard to maintain. OSS wasn't buggy, but its drivers were difficult to write from what I remember. It's been a long time... what was that, 1999? 2000? Unless I remember wrong, ALSA was partly created also to permit a single unified interface to the kernel-level sound system no matter the hardware... I think in order to avoid having to write more ioctls. It's been a while; I don't remember everything and it's also likely that I remember a thing or two wrongly. OSS *is* older than ALSA by a long shot though. I used to use only OSS drivers because my SoundBlaster live 5.1 (emu10k1) was simply awesome though it circa 2001. >> What to do for video, then? >What has video to do with voice? The two are unrelated (voice doesn't >use gstreamer for anything, it is completely a Vivox issue). lol I know that... what I was meaning is if we could choose the backend for everything else including audio streaming, we're left with only video streaming to contend with and all of the I/O nightmares would essentially be stomped out. The switch to OpenAL in 1.22 fixed everything except streaming for me due to the 32- vs 64-bit gstreamer dependency. >BTW, in your case, I would strongly suggest to use your own 64bit >version of gstreamer. That may fix many of the crashes you are having. >Mixing 32bit and 64bit libraries is rarely good idea. Easier said than done. No client build = no link to 64-bit libs, and was the source of my rant in the first place! But I agree 100%. >A new developer has NO value unless he has an overview of the process, >the components involved and how everything hangs together. >New developers need to learn a lot of things. The best way to >learn is by doing. Changing a whole install/compile step to >a one-click won't make them any wiser and they will be of no >value imho. It's of value to get people started. Starting with a success is encouraging; starting with failure is not. Start a new dev at a known working position with a successful build is far more productive than handing them a pile of crap and saying "fix it and make it work." People do learn by doing it's true, but after trying and failing so many times I'm surprised many more haven't given up entirely. It's impossible to learn how things work together when they don't work at all because you can't see them interact. After things work, they can dive in and find out why it works and break it themselves to learn even more. Baby steps. Ambrosia earned mega mega points with me because of her (or his?) attempt to address this at that level even though it didn't work on my system! That got at least two people successfully building on Debian and that's awesome because now they can learn how things really work. If only one of them contributes only one patch to fix only one bug then it was worth the effort, imo. I haven't given up. I'm waiting for someone on a similar system (ubuntu 8.10 amd 64) to meet with success so I can ask them what they did that I didn't. I'm no n00b with Linux by a pretty big stretch; I learned why you don't move libc in a dynamic linked situation the hard way in 1997, for example, but the SL client build has me stumped but good. I bring it up on the list from time to time partly to remind people that there are still many who can't build, partly to remain in the loop though I'm one of those whom has contributed only one patch (which does not seem to have made it into 1.22 >:( ), and partly to test the waters to see if someone can give me a lightbulb moment. --GC On Friday 13 March 2009 12:47:57 pm Henri Beauchamp wrote: > On Fri, 13 Mar 2009 12:38:15 +0100, Jan Ciger wrote: > > Henri Beauchamp wrote: > > > I personally got all audio device usage conflicts solved by getting rid > > > of ALSA and *all* sound wrappers/daemons (pulseaudio, esd, jackit, > > > arts, you name it) and installing OSS v4.1 > > > (http://www.opensound.com/oss.html). > > > > Henri, that is unfortunately not an option for the majority of Linux > > users. They do not have neither the skills nor the means to install this > > version of OSS. > > Did you try it at all ??? I doubt so... > > It's as simple as downloading a package from OSS website and > installing it, just like you do with your distro packaging > mechanism (RPM and DEB and TAR are provided)... > And if your packaging mechanism is not supported, you got an > auto-extractible package (just run it and it will do the rest). > > > Distros will not ship it, because it is not free (libre) > > software. > > Sorry, but OSS v4 *is* Open Source... > http://developer.opensound.com/sources/ > > My bet is that given how more performant and easy is OSS (not to > mention the OSS API has been around since day one of audio support > in Linux and all software support it), it will replace the buggy, > extremely flacky and unfriendly ALSA in the future. > With OSS, you can get rid of *all* the stupid sound daemons and > not have to worry if this or that software will support them. > > Henri. > _______________________________________________ > 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 gcanaday at gmail.com Fri Mar 13 16:45:16 2009 From: gcanaday at gmail.com (Glen Canaday) Date: Fri, 13 Mar 2009 19:45:16 -0400 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <49BAEE7F.9030408@online.de> References: <49B9BF58.1060503@Gmail.com> <49BAEE7F.9030408@online.de> Message-ID: <200903131945.16831.gcanaday@gmail.com> Sounds like the fixes will have to be reproduced :( sux0rz. didn't someone say that they're available as a .rar archive? --GC On Friday 13 March 2009 7:38:39 pm Thomas Shikami wrote: > Tigro Spottystripes wrote: > > I thought the issue was only about the source code for older versions.... > > The issue is about KirstenLee distributing binaries of OpenLife without > providing sources for it. KirstenLee took the binaries down, but still > does not comply with releasing sources. > _______________________________________________ > 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 Fri Mar 13 16:48:59 2009 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Sat, 14 Mar 2009 10:48:59 +1100 Subject: [sldev] Webkit versus Second Life In-Reply-To: References: Message-ID: <30520128-B382-4285-9F1F-B5FC07E0501D@gmail.com> Hi, On 14/03/2009, at 12:14 AM, Soft wrote: > We're pretty far away from that. We rely on a handful of libraries > that we can't provide on our own. We need some extra development tools > installed. We have library and artwork bundles apart from the source > bundle. We have separate steps for configuring and for building. An > awful lot of new devs get lost somewhere in the process. > > Of all the above, if we were going to focus on knocking out just one > step next, which do you think would be most valuable? Which is the > highest hurdle? On the Mac, I'd say getting the universal binary built for fmod is the biggest hurdle, that seems to be the one that I see the most posts about here, and requires a handful of steps. Having said that, I'll attatch a script that I use for builds on the mac. It's a little clunky with the handleing of downloading the apropriate files, especially if the md5sums file is borked, but it's been working for me for a while. -------------- next part -------------- A non-text attachment was scrubbed... Name: updateSL Type: application/octet-stream Size: 3514 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090314/9a057fb6/attachment.obj -------------- next part -------------- From tigrospottystripes at gmail.com Fri Mar 13 16:52:10 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 13 Mar 2009 20:52:10 -0300 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <200903122153.52931.khyota@redhyena.net> References: <200903122153.52931.khyota@redhyena.net> Message-ID: <49BAF1AA.8070003@Gmail.com> is this it? Khyota escreveu: > He posted it as an ever convienient RAR archive here. > > http://www.armyof4.com/Kirstenlee/ > > Khyota > _______________________________________________ > 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 vector at leafpile.com Fri Mar 13 16:57:15 2009 From: vector at leafpile.com (Vector Hastings) Date: Fri, 13 Mar 2009 16:57:15 -0700 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <200903131945.16831.gcanaday@gmail.com> Message-ID: There's a .rar archive out there for his S16 viewer, but alas, no SD5. On a happy note, I finally managed to whack changeset 870 into his SD2_R7, which has enough fixes in it to be quite useable. (for example, no more missing shadows as reported in https://jira.secondlife.com/browse/VWR-12314 , but I have no idea what part of his changes fix it) -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Glen Canaday Sent: Friday, March 13, 2009 4:45 PM To: sldev at lists.secondlife.com Subject: Re: [sldev] Looking for source for KirstenLee's SD5 Sounds like the fixes will have to be reproduced :( sux0rz. didn't someone say that they're available as a .rar archive? --GC On Friday 13 March 2009 7:38:39 pm Thomas Shikami wrote: > Tigro Spottystripes wrote: > > I thought the issue was only about the source code for older versions.... > > The issue is about KirstenLee distributing binaries of OpenLife without > providing sources for it. KirstenLee took the binaries down, but still > does not comply with releasing sources. > _______________________________________________ > 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 tom at streamsense.net Fri Mar 13 16:57:23 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 13 Mar 2009 23:57:23 +0000 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <49BAF1AA.8070003@Gmail.com> References: <200903122153.52931.khyota@redhyena.net> <49BAF1AA.8070003@Gmail.com> Message-ID: <49BAF2E3.8070302@streamsense.net> No, the release is past build 160 at this stage Tigro Spottystripes wrote: > is this it? > > Khyota escreveu: > >> He posted it as an ever convienient RAR archive here. >> >> http://www.armyof4.com/Kirstenlee/ >> >> Khyota >> _______________________________________________ >> 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 khyota at redhyena.net Sat Mar 14 01:57:36 2009 From: khyota at redhyena.net (Khyota) Date: Sat, 14 Mar 2009 04:57:36 -0400 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: References: Message-ID: <200903140457.37254.khyota@redhyena.net> On Friday 13 March 2009 7:57:15 Vector Hastings wrote: > There's a .rar archive out there for his S16 viewer, but alas, no SD5. > > On a happy note, I finally managed to whack changeset 870 into his SD2_R7, > which has enough fixes in it to be quite useable. > (for example, no more missing shadows as reported in > https://jira.secondlife.com/browse/VWR-12314 , but I have no idea what part > of his changes fix it) > > How about just asking nicely for that specific fix? From jan.ciger at gmail.com Sat Mar 14 12:04:05 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat, 14 Mar 2009 20:04:05 +0100 Subject: [sldev] gstreamer In-Reply-To: <20090313174757.d2b35111.sldev@free.fr> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <20090313102145.47eac843.sldev@free.fr> <49BA45A7.1040100@gmail.com> <20090313174757.d2b35111.sldev@free.fr> Message-ID: <49BBFFA5.9040903@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, Henri Beauchamp wrote: > Did you try it at all ??? I doubt so... > > It's as simple as downloading a package from OSS website and > installing it, just like you do with your distro packaging > mechanism (RPM and DEB and TAR are provided)... > And if your packaging mechanism is not supported, you got an > auto-extractible package (just run it and it will do the rest). Right. Except that you are barking up the wrong tree here. I think I do posses the skills to install this, but if I have to go through this rigamarole every time I update my system to a newer release, well, thanks. Lot of things simply expect Alsa/Pulse to be in place these days. Perhaps you have more time than I do, but I prefer to have things working with my distro, not me having to bend over backwards to get a program like SL working properly by replacing a whole sound subsystem. > >> Distros will not ship it, because it is not free (libre) >> software. > > Sorry, but OSS v4 *is* Open Source... > http://developer.opensound.com/sources/ And what is this (on the download page): > Open Sound System is now free for personal and non-commercial use and > comes with a license key that will allow you to run OSS. The license > key is valid for up to 6 months at a time after which you will need > to download and install OSS again. There are no time limitations or > restricted functionality during the licensing period. A permanant > license key that will entitle you to free support and upgrades can be > ordered here That the sources are available doesn't mean that this is a free (libre) software. > My bet is that given how more performant and easy is OSS (not to > mention the OSS API has been around since day one of audio support > in Linux and all software support it), it will replace the buggy, > extremely flacky and unfriendly ALSA in the future. > With OSS, you can get rid of *all* the stupid sound daemons and > not have to worry if this or that software will support them. Right, with the license like the one above, I am looking forward to see that happen. The licensing is at the very least unclear, because the pre-packaged binaries carry a distinctly non-free license, but the source is supposedly multi-licensed (including GPL?). However, according to their FAQ, there are some closed source components. Ain't gonna happen, Henri. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJu/+ln11XseNj94gRAv+nAJ9pxVw35PnCT5HA7i3XPGI1wQEgcwCeKvbE sKHtKMgPww2qMHYpJ4DuOyQ= =n3UV -----END PGP SIGNATURE----- From seg at haxxed.com Sat Mar 14 16:16:03 2009 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 14 Mar 2009 18:16:03 -0500 Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder Message-ID: <1237072563.19095.98.camel@localhost.localdomain> Is this for real? http://forums.topcoder.com/?module=Thread&threadID=634679&start=0&mc=1#1071016 http://www.topcoder.com/tc?module=MatchDetails&rd=13772 http://forums.topcoder.com/?module=ThreadList&forumID=526417&mc=121 My googling and searching of mailing lists and LL blogs reveals no mention of TopCoder at all, that I can find. Is LL really behind this? Only other thing I can find is this: http://studio.topcoder.com/?module=ViewContestDetails&ct=1000525 I only found out about it because I have someone emailing me for tips. This treads directly on my territory and I'm going to be very annoyed if people are winning thousands of dollars for something I've been pouring hundreds of man hours into over the past two years without any such direct compensation. Also the rules are very concerning: http://www.topcoder.com/tc?module=MatchRules&rd=13772 "If TopCoder compensates you for your submission, then you agree to irrevocably and unconditionally transfer and assign to TopCoder all right, title and interest you have, may have or acquire in, such submission" "You further agree that any and all works of authorship created, authored or developed by you hereunder which TopCoder compensates you for shall be deemed to be "works made for hire" within the meaning of the United States Copyright Law and, as such, all rights therein including copyright shall belong solely and exclusively to TopCoder from the time of their creation." Or in short "You sign over your soul to TopCoder" which makes me hesitant to participate, and makes me question the motives of those behind the contest. This is very much the opposite of open collaboration. So, seriously WTF? Does this all sound fair to you? Because I'm sure feeling cheated. Incidentally I recently posted some patches that give a 30-35% speedup of the decoder: http://groups.google.com/group/openjpeg/browse_thread/thread/4d27b0eaeba39c8a -------------- 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/20090314/7208b440/attachment.pgp From maggie at matrisync.com Sat Mar 14 17:52:35 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Sat, 14 Mar 2009 20:52:35 -0400 Subject: [sldev] Shadowdraft Message-ID: I just hope somebody knows how to fix http://jira.secondlife.com/browse/VWR-9979 , or there won't be any Shadowdraft that works on nVidia. From vector at leafpile.com Sat Mar 14 23:13:51 2009 From: vector at leafpile.com (Vector Hastings) Date: Sat, 14 Mar 2009 23:13:51 -0700 Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder In-Reply-To: <1237072563.19095.98.camel@localhost.localdomain> Message-ID: I'm guessing the motive is to make money. You only lose rights to your algorithm if you win money... so that would be your compensation. How they'll make money is their business. If they sell it to LL, then it may become part of an OpenSource project, in which case I'm just guessing that they want absolute rights in order to distribute it for free. Gold might not be so bad, what would bother me if I was in your shoes would be losing rights for the second prize purse. :-\ You have my sympathy for the intellectual property angst involved. good luck, Vector -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Callum Lerwick Sent: Saturday, March 14, 2009 4:16 PM To: sldev Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder Is this for real? http://forums.topcoder.com/?module=Thread&threadID=634679&start=0&mc=1#10710 16 http://www.topcoder.com/tc?module=MatchDetails&rd=13772 http://forums.topcoder.com/?module=ThreadList&forumID=526417&mc=121 My googling and searching of mailing lists and LL blogs reveals no mention of TopCoder at all, that I can find. Is LL really behind this? Only other thing I can find is this: http://studio.topcoder.com/?module=ViewContestDetails&ct=1000525 I only found out about it because I have someone emailing me for tips. This treads directly on my territory and I'm going to be very annoyed if people are winning thousands of dollars for something I've been pouring hundreds of man hours into over the past two years without any such direct compensation. Also the rules are very concerning: http://www.topcoder.com/tc?module=MatchRules&rd=13772 "If TopCoder compensates you for your submission, then you agree to irrevocably and unconditionally transfer and assign to TopCoder all right, title and interest you have, may have or acquire in, such submission" "You further agree that any and all works of authorship created, authored or developed by you hereunder which TopCoder compensates you for shall be deemed to be "works made for hire" within the meaning of the United States Copyright Law and, as such, all rights therein including copyright shall belong solely and exclusively to TopCoder from the time of their creation." Or in short "You sign over your soul to TopCoder" which makes me hesitant to participate, and makes me question the motives of those behind the contest. This is very much the opposite of open collaboration. So, seriously WTF? Does this all sound fair to you? Because I'm sure feeling cheated. Incidentally I recently posted some patches that give a 30-35% speedup of the decoder: http://groups.google.com/group/openjpeg/browse_thread/thread/4d27b0eaeba39c8 a From kakurady at gmail.com Sun Mar 15 04:51:44 2009 From: kakurady at gmail.com (Geneko Nemeth) Date: Sun, 15 Mar 2009 07:51:44 -0400 Subject: [sldev] gstreamer In-Reply-To: <49B978A8.70403@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> Message-ID: <49BCEBD0.5070607@gmail.com> I have been playing with Pulseaudio 0.9.14 on Ubuntu Jaunty Alpha (because SLVoice tend to freeze the version 0.9.10 shipped with Intrepid). UI Sound and wind effects are working, but often SLVoice can use more CPU than Second Life client itself. (With the client window focused, even. That just spells lag.) And sometimes, SLVoice would also appear to freeze, leaving me to figure out why my voice won't transmit. As an aside, while Pulseaudio is one of the ways to go, it is still immature. GCat/Kaku ? 2009?03?12? 17:03, Jan Ciger ??: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sean Linden wrote: > > >> I wish I had the time to attempt to do a build - I have the same problem >> - the viewer crashes immediately if I try to enable streaming. Voice >> works, but not using pulseaudio. I have to kill pulseaudio before >> starting SL, and if I don't need to use voice and I leave pulseaudio >> running, the viewer will frequently hang or cause other audio apps to >> hang, resulting in my needing to restart pulseaudio after quitting the >> viewer. >> > > This issue with voice and pulseaudio is present in the 32bit build as > well. For me, if I enable voice, the pulse server crashes after a short > time resulting in an incredible racket (looping sample). Restarting > pulse cures it, but then the client will lose sound until I restart it > too. So voice is completely unusable on machines that are using > pulseaudio right now. BTW, most modern distros are changing over to > pulseaudio, so it would help to actually support it. > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFJuXion11XseNj94gRAtFbAJ9xNffWgDoiWzF1LXM1bjdtatQ9nwCgnPOe > CfywLeGGl4OVJSJa0pxCDpA= > =AMPz > -----END PGP SIGNATURE----- > _______________________________________________ > 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/20090315/3d28f113/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-?????.png Type: image/png Size: 64324 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090315/3d28f113/attachment-0001.png From sldev at free.fr Sun Mar 15 08:22:24 2009 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 15 Mar 2009 16:22:24 +0100 Subject: [sldev] gstreamer In-Reply-To: <49BBFFA5.9040903@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <20090313102145.47eac843.sldev@free.fr> <49BA45A7.1040100@gmail.com> <20090313174757.d2b35111.sldev@free.fr> <49BBFFA5.9040903@gmail.com> Message-ID: <20090315162224.2c36ff8e.sldev@free.fr> OK... This is my last message on this topic, for it's becoming less and less sldev related... Still, I can't let wrong things be said about a *great* software that could help many of you around (and not only when running SL). On Sat, 14 Mar 2009 20:04:05 +0100, Jan Ciger wrote: > Hi Henri, > > Henri Beauchamp wrote: > > Did you try it at all ??? I doubt so... > > > > It's as simple as downloading a package from OSS website and > > installing it, just like you do with your distro packaging > > mechanism (RPM and DEB and TAR are provided)... > > And if your packaging mechanism is not supported, you got an > > auto-extractible package (just run it and it will do the rest). > > Right. Except that you are barking up the wrong tree here. I think I do > posses the skills to install this, but if I have to go through this > rigamarole every time I update my system to a newer release, well, > thanks. If you had actually tried it, you would have noticed that the OSS init.d scripts are clever enough to recompile automatically the OSS modules whenever an update to your kernel occurs... > Lot of things simply expect Alsa/Pulse to be in place these > days. Perhaps you have more time than I do, but I prefer to have things > working with my distro, not me having to bend over backwards to get a > program like SL working properly by replacing a whole sound subsystem. It's a plug and play solution: no need to fiddle with anything as long as your distro provides modularized sound support (and I don't know any which don't). > >> Distros will not ship it, because it is not free (libre) > >> software. > > > > Sorry, but OSS v4 *is* Open Source... > > http://developer.opensound.com/sources/ > > And what is this (on the download page): > > > Open Sound System is now free for personal and non-commercial use and > > comes with a license key that will allow you to run OSS. The license > > key is valid for up to 6 months at a time after which you will need > > to download and install OSS again. There are no time limitations or > > restricted functionality during the licensing period. A permanant > > license key that will entitle you to free support and upgrades can be > > ordered here > > That the sources are available doesn't mean that this is a free (libre) > software. Once again, OSS *is* Free (like in free beer *and* free speech) software. As long as you compile it from sources (which would be what any distro maker would do anyway), it is GPL under Linux. The license for the binary pre-compiled package is something else (just like Second Life binary packages..), but it is still a free license for the end user (and the stuff about the 6 months key is completely deprecated: there is no such key any more now). > > My bet is that given how more performant and easy is OSS (not to > > mention the OSS API has been around since day one of audio support > > in Linux and all software support it), it will replace the buggy, > > extremely flacky and unfriendly ALSA in the future. > > With OSS, you can get rid of *all* the stupid sound daemons and > > not have to worry if this or that software will support them. > > Right, with the license like the one above, I am looking forward to see > that happen. The licensing is at the very least unclear, because the > pre-packaged binaries carry a distinctly non-free license, Yes, just like the Second Life viewer... So what ?... You can still build either from GPLed sources... > but the source is supposedly multi-licensed (including GPL?). Again, just like Second Life... and if you did read it right, you noticed that the license for OSS matches the one of the OS on which it is running, i.e. GPL for Linux, BDS, for *BSD, etc... Clever, I think. > However, according to their FAQ, there are some closed source > components. Yes, some *non-free* drivers (not in the provided free package) are closed source. But as they are written for professional audio devices and applications, it's not really a problem for the desktop computer user. > Ain't gonna happen, Henri. I bet it will. :-P Henri. From jan.ciger at gmail.com Sun Mar 15 12:36:45 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 15 Mar 2009 20:36:45 +0100 Subject: [sldev] gstreamer In-Reply-To: <49BCEBD0.5070607@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <49BCEBD0.5070607@gmail.com> Message-ID: <49BD58CD.9030904@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Geneko Nemeth wrote: > I have been playing with Pulseaudio 0.9.14 on Ubuntu Jaunty Alpha > (because SLVoice tend to freeze the version 0.9.10 shipped with > Intrepid). UI Sound and wind effects are working, but often SLVoice can > use more CPU than Second Life client itself. (With the client window > focused, even. That just spells lag.) I suspect that Pulse is running at a different sampling frequency than Vivox stuff uses and is doing resampling on the fly in you case. That can literally eat the CPU time. The most common setup for Pulse that I have seen is 48kHz sampling rate, because many modern soundcards default to it or do not even support slower rates (especially in laptops). Does anyone know what are the parameters Vivox libs are using for audio? > And sometimes, SLVoice would also > appear to freeze, leaving me to figure out why my voice won't transmit. For me voice freezes Pulseaudio (I have also 0.9.10 on Mandriva 2009), leaving it stuck with a repeating sample in a buffer. I had that happen with other applications before, but that is exceedingly rare today. Even Skype works quite OK with Pulseaudio, but SL voice does not :( > As an aside, while Pulseaudio is one of the ways to go, it is still > immature. That's unfortunately true, but it is getting better. Having more applications support it would both reduce the complexity of the applications (you can drop a lot of the soundcard-related wizardry) and expose more bugs in Pulse, letting them be fixed faster. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJvVjJn11XseNj94gRAt7/AKDo6MUI9aQuU5A41y/EfUpr0Wm/TACgz4YB TNVW37qOCn7DguNO4dCk/sI= =m8rV -----END PGP SIGNATURE----- From teravus at gmail.com Sun Mar 15 14:43:09 2009 From: teravus at gmail.com (Teravus Ovares) Date: Sun, 15 Mar 2009 17:43:09 -0400 Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder In-Reply-To: References: <1237072563.19095.98.camel@localhost.localdomain> Message-ID: <34cc66250903151443p6edbf037r7688dd62434292d5@mail.gmail.com> Maybe they are taking input heart in that the developers on this list have stated that they want as little proprietary code dependencies as possible? One major dependency in the release code is kdu to which the capital expense is somewhat high. Pricing: Ver 6.x New licensees: Non commercial: $ 250 Commercial 25: upto 25 employees/cctors.$ 12,000 Commercial 100 : upto 100 employees/cctors $ 16,000 Commercial 250 : upto 250 employees/cctors $ 32,000 Commercial Enterprise: unlimited employees/cctors $ 48,000 Library licenses: $ 250 --------------------------------------------------------- Ver 6.x Upgrades:(from previous versions) Non commercial including Library. Sent automatically $ 0 Commercial v5.x (any) to Commercial 25: $ 1,000 Multi-user non-commercial v5.x to Commercial 25: $ 10,900 Commercial v5.x (any) to Commercial 100: $ 5,000 Multi-user non-commercial v5.x to Commercial 100: $ 14,900 Commercial v5.x (for >100 employees) to Commercial 250:$ 10,000 Commercial v5.x (other) to Commercial 250: $ 21,000 Multi-user non-commercial v5.x to Commercial 250: $ 19,900 Commercial v5.x (for >100 employees) to commercial Enterprise: $ 26,000 Commercial v5.x (other) to Commercial Enterprise: $37,000 This, of course, is assuming that they're not using the speed pack versions.. I think that to improve the state of openjpeg instead of purchasing an upgrade would both reduce proprietary dependencies and reduce capital expenditures in the long run at the same time. As for venue, I guess the people who issued the contest there either didn't know there was a group of developers on this list working on it or didn't feel that the pool was large enough. my 2c Teravus On 3/15/09, Vector Hastings wrote: > I'm guessing the motive is to make money. You only lose rights to your > algorithm if you win money... so that would be your compensation. How > they'll make money is their business. If they sell it to LL, then it may > become part of an OpenSource project, in which case I'm just guessing that > they want absolute rights in order to distribute it for free. > > > Gold might not be so bad, what would bother me if I was in your shoes would > be losing rights for the second prize purse. :-\ > > You have my sympathy for the intellectual property angst involved. > > good luck, > > Vector > > -----Original Message----- > From: sldev-bounces at lists.secondlife.com > [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Callum Lerwick > Sent: Saturday, March 14, 2009 4:16 PM > To: sldev > Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder > > > Is this for real? > > http://forums.topcoder.com/?module=Thread&threadID=634679&start=0&mc=1#10710 > 16 > http://www.topcoder.com/tc?module=MatchDetails&rd=13772 > http://forums.topcoder.com/?module=ThreadList&forumID=526417&mc=121 > > My googling and searching of mailing lists and LL blogs reveals no > mention of TopCoder at all, that I can find. Is LL really behind this? > Only other thing I can find is this: > > http://studio.topcoder.com/?module=ViewContestDetails&ct=1000525 > > I only found out about it because I have someone emailing me for tips. > This treads directly on my territory and I'm going to be very annoyed if > people are winning thousands of dollars for something I've been pouring > hundreds of man hours into over the past two years without any such > direct compensation. > > Also the rules are very concerning: > > http://www.topcoder.com/tc?module=MatchRules&rd=13772 > > "If TopCoder compensates you for your submission, then you agree to > irrevocably and unconditionally transfer and assign to TopCoder all > right, title and interest you have, may have or acquire in, such > submission" > > "You further agree that any and all works of authorship created, > authored or developed by you hereunder which TopCoder compensates you > for shall be deemed to be "works made for hire" within the meaning of > the United States Copyright Law and, as such, all rights therein > including copyright shall belong solely and exclusively to TopCoder from > the time of their creation." > > Or in short "You sign over your soul to TopCoder" which makes me > hesitant to participate, and makes me question the motives of those > behind the contest. This is very much the opposite of open > collaboration. > > So, seriously WTF? Does this all sound fair to you? Because I'm sure > feeling cheated. > > > Incidentally I recently posted some patches that give a 30-35% speedup > of the decoder: > > http://groups.google.com/group/openjpeg/browse_thread/thread/4d27b0eaeba39c8 > a > > _______________________________________________ > 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 sly_squash at hotmail.com Sun Mar 15 15:39:27 2009 From: sly_squash at hotmail.com (Joshy Squashy) Date: Sun, 15 Mar 2009 17:39:27 -0500 Subject: [sldev] [HELP] Building on Windows 7? In-Reply-To: References: Message-ID: Now that the 1.22 release code is out, I tried a fresh compile for VS2008 and found the boost libraries still hadn't made it into the release and it didn't compile. However, I will be rebuilding my machine soon and would like to try the Windows 7 beta. Does anyone know if the 1.22 release code compiles in VS2005 under Windows 7? Does Second Life itself run under Windows 7? _________________________________________________________________ Windows Live? Groups: Create an online spot for your favorite groups to meet. http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090315/5ac388d4/attachment.htm From geenz at me.com Sun Mar 15 16:25:37 2009 From: geenz at me.com (Jonathan Goodman) Date: Sun, 15 Mar 2009 16:25:37 -0700 Subject: [sldev] [HELP] Building on Windows 7? In-Reply-To: References: Message-ID: <114552567379519979994065902747708312544-Webmail@me.com> >Now that the 1.22 release code is out, I tried a fresh compile for VS2008 and found the boost libraries still hadn't made it into the release and it didn't compile. However, I will be rebuilding my machine soon and would like to try the Windows 7 beta. Does anyone know if the 1.22 release code compiles in VS2005 under Windows 7? Does Second Life itself run under Windows 7? It will compile and run under Windows 7 with VS2005. I've had issues with getting the viewer to start after compiling with VS2008, even after replacing the boost libraries with VS2008 compiled versions. From kakurady at gmail.com Sun Mar 15 16:57:40 2009 From: kakurady at gmail.com (Geneko Nemeth) Date: Sun, 15 Mar 2009 19:57:40 -0400 Subject: [sldev] SLVoice and PulseAudio (was: gstreamer) In-Reply-To: <49BD58CD.9030904@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <49BCEBD0.5070607@gmail.com> <49BD58CD.9030904@gmail.com> Message-ID: <49BD95F4.4050504@gmail.com> Indeeds the Vivox voice outputs in 32khz. (This particular Pulse server defaults to s16le 2ch 44100Hz.) But that doesn't make sense, does it? After all, if it's the server's job to convert sample rates, why wolud the sound client be running at full CPU? And Windows' audio stack does on-the-fly rate conversions all the time, but there's not much a noticable performance impact. Interestingly, if you turn on Voice (with Alsa-Pulse-Alsa) and look in the debug log there's this line: AL lib: alsa.c:616: set access failed: Invalid argument Someone turn off Pulse and see what happens? GCat/Kaku *** Sink Input #98 *** Driver: pulsecore/protocol-native.c Owner Module: 1 Client: 62 Sink: 1 Sample Specification: s16le 2ch 44100Hz Channel Map: front-left,front-right Volume: 0: 100% 1: 100% Buffer Latency: 72448 usec Sink Latency: 23370 usec Resample method: src-linear Properties: media.name = "ALSA Playback" application.name = "ALSA plug-in [SLVoice]" native-protocol.peer = "TCP/IP client from 127.0.1.1:47686" native-protocol.version = "14" application.process.id = "20184" application.process.user = "nekoyasha" application.process.host = "nekokoneko" application.process.binary = "SLVoice" application.language = "C" *** Source Output #26 *** Driver: pulsecore/protocol-native.c Owner Module: 1 Client: 63 Source: 2 Sample Specification: s16le 1ch 32000Hz Channel Map: mono Buffer Latency: 14000 usec Source Latency: 3318 usec Resample method: src-linear Properties: media.name = "ALSA Capture" application.name = "ALSA plug-in [SLVoice]" native-protocol.peer = "TCP/IP client from 127.0.1.1:47687" native-protocol.version = "14" application.process.id = "20184" application.process.user = "nekoyasha" application.process.host = "nekokoneko" application.process.binary = "SLVoice" lines 281-321 ? 2009?03?15? 15:36, Jan Ciger ??: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Geneko Nemeth wrote: > >> I have been playing with Pulseaudio 0.9.14 on Ubuntu Jaunty Alpha >> (because SLVoice tend to freeze the version 0.9.10 shipped with >> Intrepid). UI Sound and wind effects are working, but often SLVoice can >> use more CPU than Second Life client itself. (With the client window >> focused, even. That just spells lag.) >> > > I suspect that Pulse is running at a different sampling frequency than > Vivox stuff uses and is doing resampling on the fly in you case. That > can literally eat the CPU time. The most common setup for Pulse that I > have seen is 48kHz sampling rate, because many modern soundcards default > to it or do not even support slower rates (especially in laptops). Does > anyone know what are the parameters Vivox libs are using for audio? > > >> And sometimes, SLVoice would also >> appear to freeze, leaving me to figure out why my voice won't transmit. >> > > For me voice freezes Pulseaudio (I have also 0.9.10 on Mandriva 2009), > leaving it stuck with a repeating sample in a buffer. I had that happen > with other applications before, but that is exceedingly rare today. Even > Skype works quite OK with Pulseaudio, but SL voice does not :( > > >> As an aside, while Pulseaudio is one of the ways to go, it is still >> immature. >> > > That's unfortunately true, but it is getting better. Having more > applications support it would both reduce the complexity of the > applications (you can drop a lot of the soundcard-related wizardry) and > expose more bugs in Pulse, letting them be fixed faster. > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFJvVjJn11XseNj94gRAt7/AKDo6MUI9aQuU5A41y/EfUpr0Wm/TACgz4YB > TNVW37qOCn7DguNO4dCk/sI= > =m8rV > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090315/c1adf838/attachment.htm From rgwells at techno-logix.com Sun Mar 15 18:24:14 2009 From: rgwells at techno-logix.com (Russell G. Wells) Date: Sun, 15 Mar 2009 18:24:14 -0700 Subject: [sldev] Can't make llmozlib2. Message-ID: <200903151824.14432.rgwells@techno-logix.com> I trying again to build the second life viewer on my Kubuntu 8.04 x86_64 platform. Specifically, I'm building the llmozlib2 sources. Note that I tried building the current viewer source with the -DMOZLIB:BOOL-FALSE option, but the 1.22.11 sources still fail to compile (that's another post). Anyway I checked out the llmozlib2 source from svn (https://svn.secondlife.com/svn/llmozlib/trunk/llmozlib2) and have tried to build using these steps: 1. update the ./build_mozilla/linux-libxul-bits/mozconfig to use gcc-4.2 2. run the linux-checkout_patch_build.sh script. This script checks out the mozilla code and applies the linden patches to it. Finaly, it does a build. I get the following error when the build process is generating the libxremote_client_s library: ... rm -f libxremote_client_s.a ar cr libxremote_client_s.a XRemoteClient.o ranlib libxremote_client_s.a XRemoteClient_standalone.o:(.data.rel.ro._ZTI13XRemoteClient[typeinfo for XRemoteClient]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' XRemoteClient_standalone.o:(.data.rel.ro._ZTI14nsRemoteClient[typeinfo for nsRemoteClient]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/bin/ld: mozilla-xremote-client: hidden symbol `vtable for __cxxabiv1::__class_type_info' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[3]: *** [mozilla-xremote-client] Error 1 make[3]: Leaving directory `/home/rgwells/projects/llmozlib2/build_mozilla/objdir-mozilla-linux/widget/src/xremoteclient' make[2]: *** [tier_50] Error 2 make[2]: Leaving directory `/home/rgwells/projects/llmozlib2/build_mozilla/objdir-mozilla-linux' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/rgwells/projects/llmozlib2/build_mozilla/objdir-mozilla-linux' make: *** [build] Error 2 There are no other errors in the 16000 line of compiler output i captured. I'm thinking that there is a library dependency that I'm missing, but that's a guess. Does anyone have a clue as to what this issue might be? System info: ------------------- Distribution: Kubuntu 8.04 Kernel version: 2.6.24-23-generic #1 SMP Mon Jan 26 01:04:16 UTC 2009 x86_64 GNU/Linux CPU: AMD Phenom 9850 Quad-Core @ 2.5 Ghz GPU: GeForce 9500 GT NVidia driver: 173.14.12 From vector at leafpile.com Mon Mar 16 01:20:01 2009 From: vector at leafpile.com (Vector Hastings) Date: Mon, 16 Mar 2009 01:20:01 -0700 Subject: [sldev] Camera Zoom Pointers In-Reply-To: <49BD95F4.4050504@gmail.com> Message-ID: Anybody know how joystick affects the zoom? And BTW, am I right in thinking this flycam zoom is more like adjusting a real-world camera's focal-length, whereas the "mouse zoom" in llagent is more like moving the camera's position? I've been doing my usual plodding method of adding llinfos into the lljoystickbutton.cpp code and it seems like when you turn on joystick mode, it stops calling any of the functions inside joystickbutton. This is completely not what I expected, and leaves me scratching my head where to turn next. Can someone tell me where I've fallen off the bus? (I'm lost and I can't get up.) (keep in mind, I'm a C++ newbie, so I'm probably missing the most obvious thing) (some background on what I'm trying to achieve: I want to make it possible to use zoom within llfollowcam, which has a LSL parameter for it but as far as I can tell doesn't do anything with it.) Thanks to anyone, Vector -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090316/c9dde5e3/attachment.htm From jan.ciger at gmail.com Mon Mar 16 02:20:34 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Mon, 16 Mar 2009 10:20:34 +0100 Subject: [sldev] SLVoice and PulseAudio In-Reply-To: <49BD95F4.4050504@gmail.com> References: <200903111839.40570.gcanaday@gmail.com> <3736d47a0903111548t3f642f53r933016db190e6b1e@mail.gmail.com> <49B978A8.70403@gmail.com> <49BCEBD0.5070607@gmail.com> <49BD58CD.9030904@gmail.com> <49BD95F4.4050504@gmail.com> Message-ID: <49BE19E2.2070605@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Geneko Nemeth wrote: > Indeeds the Vivox voice outputs in 32khz. (This particular Pulse server > defaults to s16le 2ch 44100Hz.) > > But that doesn't make sense, does it? After all, if it's the server's > job to convert sample rates, why wolud the sound client be running at > full CPU? And Windows' audio stack does on-the-fly rate conversions all > the time, but there's not much a noticable performance impact. Is it SLVoice causing the heavy load? In my case it was always Pulseaudio when the resampling was required. If it is SLVoice, then there is something else wrong with it, but without the source for the Vivox libraries we cannot do much to debug it :( > > Interestingly, if you turn on Voice (with Alsa-Pulse-Alsa) and look in > the debug log there's this line: > AL lib: alsa.c:616: set access failed: Invalid argument Hard to say, it could be unrelated to the problem. Perhaps SLVoice is trying to set some parameters not supported by the Pulse plugin, so Alsa complains or there is a conflict between SLVoice and regular sound. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJvhnin11XseNj94gRAizOAKC9hac+LvOW4D38h4d0FtqRWdy58QCg2hhd Cwq1j/OC2MThnN/31h8T4zw= =kbcS -----END PGP SIGNATURE----- From open at autistici.org Mon Mar 16 03:15:59 2009 From: open at autistici.org (Opensource Obscure) Date: Mon, 16 Mar 2009 10:15:59 +0000 Subject: [sldev] Camera Zoom Pointers In-Reply-To: References: Message-ID: <2764ef74b30442663ad2b7037154b6fd@localhost> I don't know if this is really the same topic than yours, but I was thinking along these lines in these days, and since you mentioned Camera and Joystick .. I love using the SpaceNavigator device in Flycam Mode. It lets you visit virtual environments in such a smooth way - keyboard-mouse combos don't allow that. I think that many Second Life users would benefit from using it, and that it's even easier to use than Alt-Zoom - but admittely, I'm a geek and not an average user, so I may be too enthusiasthic. A problem I found is that if I want to see a whole region with the Flycam, I have to move around my avatar too, because Draw Distance starts from the avatar's position - not the camera's one (I may be wrong about this. However this is my feeling and also I think this has been mentioned somewhere recently - maybe during an Office Hour, or on a mailing list) I mean that, even if you raise Draw Distance to 512m and you wait some minutes so that stuff loads, when the camera is far from your avatar many objects won't be drawn (until you move your avatar nearly enough to the camera). (Maybe object occlusion too has a role here? I didn't thought about this until right now) Having objects loading according to the position of the camera instead of the position of the avatar would noticeably improve the Flycam experience. I'm sure that machinima creators that use Flycam would be happy about this. So I'm asking to Linden Lab - would be this a reasonable feature / a feasible project? Is it worthwhile to open a ticket on PJIRA about this? or you can already tell me that this is not going to happen? Ciao, Opensource Obscure From dimitrio at dimitriolewis.com Mon Mar 16 06:21:21 2009 From: dimitrio at dimitriolewis.com (Dimitrio Lewis) Date: Mon, 16 Mar 2009 13:21:21 -0000 Subject: [sldev] Camera Zoom Pointers References: <2764ef74b30442663ad2b7037154b6fd@localhost> Message-ID: <001901c9a63a$1cb9ea70$0200a8c0@INFOTECH> > > A problem I found is that if I want to see a whole region > with the Flycam, I have to move around my avatar too, because > Draw Distance starts from the avatar's position - not the > camera's one (I may be wrong about this. However this is > my feeling and also I think this has been mentioned somewhere > recently - maybe during an Office Hour, or on a mailing list) > > I mean that, even if you raise Draw Distance to 512m and you > wait some minutes so that stuff loads, when the camera is far > from your avatar many objects won't be drawn (until you move > your avatar nearly enough to the camera). > Try setting RenderUseFarClip to FALSE in your debug settings. You could additionally stretch your draw distance further by setting RenderFarClip to a higher number, such as 2048. This will have the effect of rendering objects further from the camera at the cost of cpu and memory. There are a number of level-of-detail settings that can be altered to render the entire scene in higher detail, beginning with the word Render. These are fun to mess with but all take a toll on your cpu when set to higher values. From bos at lindenlab.com Mon Mar 16 12:20:42 2009 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon, 16 Mar 2009 12:20:42 -0700 Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder In-Reply-To: <1237072563.19095.98.camel@localhost.localdomain> References: <1237072563.19095.98.camel@localhost.localdomain> Message-ID: On Sat, Mar 14, 2009 at 4:16 PM, Callum Lerwick wrote: > Is this for real? > Yes, it is. It's a one-off experiment we've been running within Linden Lab to see how Topcoder's services work out. OpenJPEG decoding performance seemed like a good target to aim at because its success is easy to measure. The reason you haven't heard anything about it on sldev before now is simple, but unflattering: we forgot. The people who are running the experiment are not in regular development roles, and although I knew about the experiment, I didn't put two and two together and ask "hey, have we announced this on sldev?" Or in short "You sign over your soul to TopCoder" which makes me > hesitant to participate, and makes me question the motives of those > behind the contest. If the winning patches perform well and are sufficiently clean, we intend to offer them to the OpenJPEG project for inclusion under the existing OpenJPEG license (i.e. BSD). So whatever other concerns you may have, you should not worry about that side of things. I sincerely apologise for our oversight in not bringing this up earlier. Regards, Bryan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090316/30ea7b2b/attachment.htm From kf6kjg at gmail.com Mon Mar 16 17:10:04 2009 From: kf6kjg at gmail.com (Ricky) Date: Mon, 16 Mar 2009 17:10:04 -0700 Subject: [sldev] Camera Zoom Pointers In-Reply-To: <001901c9a63a$1cb9ea70$0200a8c0@INFOTECH> References: <2764ef74b30442663ad2b7037154b6fd@localhost> <001901c9a63a$1cb9ea70$0200a8c0@INFOTECH> Message-ID: <3bb9647e0903161710i1c4e92fbkaccfdb7f65c4aad2@mail.gmail.com> There is also the limit, determined server-side, of what objects are even streamed to the viewer. I don't remember what this is based on off the top of my head though... My 2 cents, Ricky On Mon, Mar 16, 2009 at 6:21 AM, Dimitrio Lewis wrote: > > > > A problem I found is that if I want to see a whole region > > with the Flycam, I have to move around my avatar too, because > > Draw Distance starts from the avatar's position - not the > > camera's one (I may be wrong about this. However this is > > my feeling and also I think this has been mentioned somewhere > > recently - maybe during an Office Hour, or on a mailing list) > > > > I mean that, even if you raise Draw Distance to 512m and you > > wait some minutes so that stuff loads, when the camera is far > > from your avatar many objects won't be drawn (until you move > > your avatar nearly enough to the camera). > > > > Try setting RenderUseFarClip to FALSE in your debug settings. You could > additionally stretch your draw distance further by setting RenderFarClip to > a higher number, such as 2048. This will have the effect of rendering > objects further from the camera at the cost of cpu and memory. There are a > number of level-of-detail settings that can be altered to render the entire > scene in higher detail, beginning with the word Render. These are fun to > mess with but all take a toll on your cpu when set to higher values. > > _______________________________________________ > 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/20090316/ac788926/attachment.htm From alissa_sabre at yahoo.co.jp Tue Mar 17 05:45:55 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue, 17 Mar 2009 21:45:55 +0900 Subject: [sldev] [HELP] Building on Windows 7? In-Reply-To: References: Message-ID: <1kw9tY7fP46owwkQaG5ccYa.alissa_sabre@yahoo.co.jp> > Does anyone > know if the 1.22 release code compiles in VS2005 under Windows 7? I tried it, but I even couldn't install Visual C++ 2005 Express on Windows 7. I spent just few hours on it, so it can be my trivial mistake. > Does Second Life itself run under Windows 7? Yes, it does. Mostly. I have NVIDIA GeForce 9600GT on the PC I tried Windows 7, and I needed to update the graphics driver through Windows Update to run SL viewer. (The update was categorized as optional, and it didn't insall automatically.) I found a problem regarding Japanese input method on Windows 7. When I ran SL viewer on Japanese version of Windows 7, it had no proble. However, When I ran it on US English version of Windows with Japanese Keyboard enabled, I had troble typing Japanese text throgh Microsoft Japanese IME. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From alissa_sabre at yahoo.co.jp Tue Mar 17 06:07:43 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue, 17 Mar 2009 22:07:43 +0900 Subject: [sldev] Webkit versus Second Life In-Reply-To: References: Message-ID: <1s88dw4nifev4s89ev7dt4kw.alissa_sabre@yahoo.co.jp> > They demonstrated that you can fetch and build > Webkit using nothing but your mouse. They assume you have the > developer tools and subversion installed. The rest is su-and-say > enough that you can just copy and paste three lines from the browser. > One to do the svn fetch, one to build, and one to launch the built > app. > We're pretty far away from that. I have no experience fetching Webkit source, and I don't know how complex building of Webkit is or what build system they are using. So, I can't judge how great their demonstration is. I know, however, something about the SL viewer building process. Yes, our building process is far from "just several mouse clicking." However, even today, some automated process (such as develop.py) makes some big changes to the viewer source or building process very difficult. Simple and automated build process is good, but I don't think it is more important than an easy-to-understand building system. More custom automated build tools you supply, higher the barrier to make some change to the building process be. I hope LL *doesn't* develop 10k lines of cryptic python build script to do a "just several mouse clicking" build process... Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From tigrospottystripes at gmail.com Tue Mar 17 07:37:53 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 17 Mar 2009 11:37:53 -0300 Subject: [sldev] Camera Zoom Pointers In-Reply-To: <2764ef74b30442663ad2b7037154b6fd@localhost> References: <2764ef74b30442663ad2b7037154b6fd@localhost> Message-ID: <49BFB5C1.2050108@Gmail.com> here it is http://jira.secondlife.com/browse/VWR-11781 :) Opensource Obscure escreveu: > I don't know if this is really the same topic than yours, > but I was thinking along these lines in these days, and > since you mentioned Camera and Joystick .. > > I love using the SpaceNavigator device in Flycam Mode. > It lets you visit virtual environments in such a smooth > way - keyboard-mouse combos don't allow that. I think > that many Second Life users would benefit from using it, > and that it's even easier to use than Alt-Zoom - but > admittely, I'm a geek and not an average user, so I may > be too enthusiasthic. > > A problem I found is that if I want to see a whole region > with the Flycam, I have to move around my avatar too, because > Draw Distance starts from the avatar's position - not the > camera's one (I may be wrong about this. However this is > my feeling and also I think this has been mentioned somewhere > recently - maybe during an Office Hour, or on a mailing list) > > I mean that, even if you raise Draw Distance to 512m and you > wait some minutes so that stuff loads, when the camera is far > from your avatar many objects won't be drawn (until you move > your avatar nearly enough to the camera). > > (Maybe object occlusion too has a role here? I didn't thought > about this until right now) > > Having objects loading according to the position of the camera > instead of the position of the avatar would noticeably improve > the Flycam experience. I'm sure that machinima creators that > use Flycam would be happy about this. > > So I'm asking to Linden Lab - would be this a reasonable > feature / a feasible project? Is it worthwhile to open > a ticket on PJIRA about this? or you can already tell me > that this is not going to happen? > > Ciao, > Opensource Obscure > _______________________________________________ > 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 open at autistici.org Tue Mar 17 12:56:09 2009 From: open at autistici.org (Opensource Obscure) Date: Tue, 17 Mar 2009 19:56:09 +0000 Subject: [sldev] [HELP] [Linux] Warning while building 113976-RC In-Reply-To: <20090312042708.GA4536@alinoe.com> References: <200903111756.15305.gcanaday@gmail.com> <33c9cf53193576926fa06c7a9af6385d@localhost> <20090312042708.GA4536@alinoe.com> Message-ID: Thanks everybody for the explanations about printf("%s", str) in linden/indra/linux_crash_logger/llcrashloggerlinux.cpp By the way this is solved in the render-pipeline branch; I could build r1927 on Linux without too much hassle, and the viewer has shadows (nicer than some previous releases), 2 more checkboxes in Preferences/Graphics/Hardware to set RenderUseFBO and RenderDeferred (that is, to enable shadows), and Antialiasing now works even with shadows enabled. Opensource Obscure From soft at lindenlab.com Wed Mar 18 09:57:27 2009 From: soft at lindenlab.com (Soft) Date: Wed, 18 Mar 2009 11:57:27 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: You know the dealy: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it: http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From dmahalko at gmail.com Thu Mar 19 16:53:14 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu, 19 Mar 2009 18:53:14 -0500 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts Message-ID: It occurred to me recently that LL's reasoning for not supporting raw 3D meshes as a prim type is basically invalid, what with how SL functions right now. The whole premise behind sculpted primitives was the idea that wavelet/JPEG lossy compression could be used to store "organic" shapes that don't have a very definite shape or form. The lossy wavelet compression of the RGB map allows the data size to stay very small on the asset server, and that this could not work if applied to storing and rendering mesh data. However, that whole argument was thrown out the window after people kept demanding precision in sculpted shapes, and some time ago someone at LL said "Okay, FINE, we will allow the option of lossless compression for RGB sculpt-map uploads" and support for this lossless uploading has been added into the viewer. So, uh, if lossless compression of sculpted primitives is permitted, doesn't that mean that there could equally be support for lossless compressed 3D mesh uploads, like traditional 3D editors use? There apparently isn't really any reason to prevent mesh uploads anymore, at least as long as the meshes are very small and simple, and the largest uploaded mesh byte size is equal to or smaller than the most randomized, incompressible compressed sculpt-map. Allowing use of small meshes would be more efficient for the 3D renderer anyway. Since sculpts have a fixed number of triangles, if your model does not need the triangles for detail then they need to be "bunched up" into a pile to get them out of the way, possibly tucked inside the model so they don't show. But these unnecessary bunched up triangles are still being processed by the 3D renderer whether or not they are needed. LL's own sample sculpt maps demonstrate this problem, like with the S-shaped sculpt that has a ton of prims scrunched up on it, and which could drop 50% or more of the triangle faces on it and still look good. So sculpted prims actually add to 3D scene rendering lag and contribute to a lower framerate and poor performance because they do not and cannot "turn off" unneeded triangle faces, vs a mesh which just simply would not include any more detail triangles than the mesh actually requires. But there seems to be major LL heel-dragging against implementing actual 3D mesh support and making models a heck of a lot easier to build in external editors, vs the arcanary of sculpts that very few people understand or can use effectively to reduce prim usage. So, I am not expecting this post will change anything. But oh well, I thought I would bring up this small detail for discussion. The sldev list has been pretty quiet lately anyway.. ;-) - Scalar Tardis / Dale Mahalko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090319/000da8a1/attachment.htm From dahliatrimble at gmail.com Thu Mar 19 17:38:59 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 19 Mar 2009 17:38:59 -0700 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: References: Message-ID: One advantage sculpts have is they require little or no modifications to the SL asset storage/distribution model. I'm not sure how other mesh storage methods would fit into this model, but I suspect some modifications would be required. One problem I have with sculpties is the lack of precision for the vertex elements as a result of quantifying them to 8 bit integers to convert them to a color. Another is the need for square or rectangular arrays of vertices which makes some techniques of free form mesh modeling difficult or impossible as arbitrary polygons cannot be added or deleted. Still, I am impressed with the cleverness of sculpted prims and although I do share your desire for more flexible means of designing meshes for SL, I am grateful that sculpties exist and are being improved upon. On Thu, Mar 19, 2009 at 4:53 PM, Dale Mahalko wrote: > It occurred to me recently that LL's reasoning for not supporting raw 3D > meshes as a prim type is basically invalid, what with how SL functions right > now. > > The whole premise behind sculpted primitives was the idea that wavelet/JPEG > lossy compression could be used to store "organic" shapes that don't have a > very definite shape or form. The lossy wavelet compression of the RGB map > allows the data size to stay very small on the asset server, and that this > could not work if applied to storing and rendering mesh data. > > However, that whole argument was thrown out the window after people kept > demanding precision in sculpted shapes, and some time ago someone at LL said > "Okay, FINE, we will allow the option of lossless compression for RGB > sculpt-map uploads" and support for this lossless uploading has been added > into the viewer. > > > > So, uh, if lossless compression of sculpted primitives is permitted, > doesn't that mean that there could equally be support for lossless > compressed 3D mesh uploads, like traditional 3D editors use? > > There apparently isn't really any reason to prevent mesh uploads anymore, > at least as long as the meshes are very small and simple, and the largest > uploaded mesh byte size is equal to or smaller than the most randomized, > incompressible compressed sculpt-map. > > > > Allowing use of small meshes would be more efficient for the 3D renderer > anyway. Since sculpts have a fixed number of triangles, if your model does > not need the triangles for detail then they need to be "bunched up" into a > pile to get them out of the way, possibly tucked inside the model so they > don't show. But these unnecessary bunched up triangles are still being > processed by the 3D renderer whether or not they are needed. > > LL's own sample sculpt maps demonstrate this problem, like with the > S-shaped sculpt that has a ton of prims scrunched up on it, and which could > drop 50% or more of the triangle faces on it and still look good. > > So sculpted prims actually add to 3D scene rendering lag and contribute > to a lower framerate and poor performance because they do not and cannot > "turn off" unneeded triangle faces, vs a mesh which just simply would not > include any more detail triangles than the mesh actually requires. > > > > But there seems to be major LL heel-dragging against implementing actual 3D > mesh support and making models a heck of a lot easier to build in external > editors, vs the arcanary of sculpts that very few people understand or can > use effectively to reduce prim usage. > > So, I am not expecting this post will change anything. But oh well, I > thought I would bring up this small detail for discussion. The sldev list > has been pretty quiet lately anyway.. ;-) > > - Scalar Tardis / Dale Mahalko > > > > _______________________________________________ > 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/20090319/377039d8/attachment.htm From me at signpostmarv.name Thu Mar 19 17:54:04 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri, 20 Mar 2009 00:54:04 +0000 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: References: Message-ID: <49C2E92C.1050505@signpostmarv.name> Didn't I read something about the possibility for sculpties to be animated/manipulated with shader language code ? How would arbitrary meshes be animated/manipulated ? ~ Marv. Dahlia Trimble wrote: > One advantage sculpts have is they require little or no modifications > to the SL asset storage/distribution model. I'm not sure how other > mesh storage methods would fit into this model, but I suspect some > modifications would be required. > > One problem I have with sculpties is the lack of precision for the > vertex elements as a result of quantifying them to 8 bit integers to > convert them to a color. Another is the need for square or rectangular > arrays of vertices which makes some techniques of free form mesh > modeling difficult or impossible as arbitrary polygons cannot be added > or deleted. > > Still, I am impressed with the cleverness of sculpted prims and > although I do share your desire for more flexible means of designing > meshes for SL, I am grateful that sculpties exist and are being > improved upon. > > On Thu, Mar 19, 2009 at 4:53 PM, Dale Mahalko > wrote: > > It occurred to me recently that LL's reasoning for not supporting > raw 3D meshes as a prim type is basically invalid, what with how > SL functions right now. > > The whole premise behind sculpted primitives was the idea that > wavelet/JPEG lossy compression could be used to store "organic" > shapes that don't have a very definite shape or form. The lossy > wavelet compression of the RGB map allows the data size to stay > very small on the asset server, and that this could not work if > applied to storing and rendering mesh data. > > However, that whole argument was thrown out the window after > people kept demanding precision in sculpted shapes, and some time > ago someone at LL said "Okay, FINE, we will allow the option of > lossless compression for RGB sculpt-map uploads" and support for > this lossless uploading has been added into the viewer. > > > > So, uh, if lossless compression of sculpted primitives is > permitted, doesn't that mean that there could equally be support > for lossless compressed 3D mesh uploads, like traditional 3D > editors use? > > There apparently isn't really any reason to prevent mesh uploads > anymore, at least as long as the meshes are very small and simple, > and the largest uploaded mesh byte size is equal to or smaller > than the most randomized, incompressible compressed sculpt-map. > > > > Allowing use of small meshes would be more efficient for the 3D > renderer anyway. Since sculpts have a fixed number of triangles, > if your model does not need the triangles for detail then they > need to be "bunched up" into a pile to get them out of the way, > possibly tucked inside the model so they don't show. But these > unnecessary bunched up triangles are still being processed by the > 3D renderer whether or not they are needed. > > LL's own sample sculpt maps demonstrate this problem, like with > the S-shaped sculpt that has a ton of prims scrunched up on > it, and which could drop 50% or more of the triangle faces on it > and still look good. > > So sculpted prims actually add to 3D scene rendering lag and > contribute to a lower framerate and poor performance because they > do not and cannot "turn off" unneeded triangle faces, vs a mesh > which just simply would not include any more detail triangles than > the mesh actually requires. > > > > But there seems to be major LL heel-dragging against implementing > actual 3D mesh support and making models a heck of a lot easier to > build in external editors, vs the arcanary of sculpts that very > few people understand or can use effectively to reduce prim usage. > > So, I am not expecting this post will change anything. But oh > well, I thought I would bring up this small detail for discussion. > The sldev list has been pretty quiet lately anyway.. ;-) > > - Scalar Tardis / Dale Mahalko > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090320/897a595a/attachment.bin From dahliatrimble at gmail.com Thu Mar 19 18:11:16 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 19 Mar 2009 18:11:16 -0700 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: <49C2E92C.1050505@signpostmarv.name> References: <49C2E92C.1050505@signpostmarv.name> Message-ID: There must be some support for skeleton or morph animation of meshes in the viewer as the avatars use those techniques. I have no idea if they could be applied to other meshes. On Thu, Mar 19, 2009 at 5:54 PM, SignpostMarv Martin wrote: > Didn't I read something about the possibility for sculpties to be > animated/manipulated with shader language code ? > > How would arbitrary meshes be animated/manipulated ? > > > ~ Marv. > > Dahlia Trimble wrote: > >> One advantage sculpts have is they require little or no modifications to >> the SL asset storage/distribution model. I'm not sure how other mesh storage >> methods would fit into this model, but I suspect some modifications would be >> required. >> >> One problem I have with sculpties is the lack of precision for the vertex >> elements as a result of quantifying them to 8 bit integers to convert them >> to a color. Another is the need for square or rectangular arrays of vertices >> which makes some techniques of free form mesh modeling difficult or >> impossible as arbitrary polygons cannot be added or deleted. >> >> Still, I am impressed with the cleverness of sculpted prims and although I >> do share your desire for more flexible means of designing meshes for SL, I >> am grateful that sculpties exist and are being improved upon. >> >> On Thu, Mar 19, 2009 at 4:53 PM, Dale Mahalko > dmahalko at gmail.com>> wrote: >> >> It occurred to me recently that LL's reasoning for not supporting >> raw 3D meshes as a prim type is basically invalid, what with how >> SL functions right now. >> The whole premise behind sculpted primitives was the idea that >> wavelet/JPEG lossy compression could be used to store "organic" >> shapes that don't have a very definite shape or form. The lossy >> wavelet compression of the RGB map allows the data size to stay >> very small on the asset server, and that this could not work if >> applied to storing and rendering mesh data. >> However, that whole argument was thrown out the window after >> people kept demanding precision in sculpted shapes, and some time >> ago someone at LL said "Okay, FINE, we will allow the option of >> lossless compression for RGB sculpt-map uploads" and support for >> this lossless uploading has been added into the viewer. >> So, uh, if lossless compression of sculpted primitives is >> permitted, doesn't that mean that there could equally be support >> for lossless compressed 3D mesh uploads, like traditional 3D >> editors use? >> There apparently isn't really any reason to prevent mesh uploads >> anymore, at least as long as the meshes are very small and simple, >> and the largest uploaded mesh byte size is equal to or smaller >> than the most randomized, incompressible compressed sculpt-map. >> Allowing use of small meshes would be more efficient for >> the 3D >> renderer anyway. Since sculpts have a fixed number of triangles, >> if your model does not need the triangles for detail then they >> need to be "bunched up" into a pile to get them out of the way, >> possibly tucked inside the model so they don't show. But these >> unnecessary bunched up triangles are still being processed by the >> 3D renderer whether or not they are needed. >> LL's own sample sculpt maps demonstrate this problem, like with >> the S-shaped sculpt that has a ton of prims scrunched up on >> it, and which could drop 50% or more of the triangle faces on it >> and still look good. >> So sculpted prims actually add to 3D scene rendering lag and >> contribute to a lower framerate and poor performance because they >> do not and cannot "turn off" unneeded triangle faces, vs a mesh >> which just simply would not include any more detail triangles than >> the mesh actually requires. >> But there seems to be major LL heel-dragging against >> implementing >> actual 3D mesh support and making models a heck of a lot easier to >> build in external editors, vs the arcanary of sculpts that very >> few people understand or can use effectively to reduce prim usage. >> So, I am not expecting this post will change anything. But oh >> well, I thought I would bring up this small detail for discussion. >> The sldev list has been pretty quiet lately anyway.. ;-) >> - Scalar Tardis / Dale Mahalko >> >> _______________________________________________ >> 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/20090319/7faa2003/attachment-0001.htm From alissa_sabre at yahoo.co.jp Thu Mar 19 19:22:03 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri, 20 Mar 2009 11:22:03 +0900 (JST) Subject: [sldev] Linux standalone built WITH llmozlib Message-ID: <20090320022203.53277.qmail@web3708.mail.tnz.yahoo.co.jp> Hi, I have a question. How can I make a standalone build WITH llmozlib support on Linux? I'm currently working on 1.22.11 source, BTW. Thanks in advance, Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From luis.ibanez at kitware.com Thu Mar 19 20:09:16 2009 From: luis.ibanez at kitware.com (Luis Ibanez) Date: Thu, 19 Mar 2009 23:09:16 -0400 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: References: Message-ID: <49C308DC.8020901@kitware.com> Hi Dale, I agree with you on this point. It is currently the case that due to the lack of support for raw meshes, users have to go about composing complex shapes by combining many prims, most of which end up being obscured inside others just to get the final form as the envelop of the group. The final result is that the client has to render a large amount of triangles, many of which are simply not visible. I can see as well, that there is a point in limiting the size of meshes that users can upload, and as you suggest, a mesh that has storage cost and a rendering cost similar to current images should be allowed since it doesn't diminish the performance of the client or the server. This may be a situation where it is not possible to find a "one size fit all" solution. For example, Avatars probably shouldn't be allowed to carry meshes that are too large or complicated. While owners of regions should be allowed, (and allowed to authorize others) to place complex meshes in their local sites. For example, I can imagine a University Campus that has an anatomical display, wanting to use raw meshes for rendering livers, hearts, lungs, arteries... etc. If the extra complexity of the meshes actually result in a higher server and storage cost, this should be then offered as an option to the region owners (for a price). Many may not need this features, but for others they are vital. As an example, I was visiting recently an educational display where a Heart model is shown cut open. The heart was made out of prims (a lot of work, and very well done), but it could have made with less effort and better looking by using a raw mesh. Luis ------------------ Dale Mahalko wrote: > It occurred to me recently that LL's reasoning for not supporting raw 3D > meshes as a prim type is basically invalid, what with how SL functions > right now. > > The whole premise behind sculpted primitives was the idea that > wavelet/JPEG lossy compression could be used to store "organic" shapes > that don't have a very definite shape or form. The lossy wavelet > compression of the RGB map allows the data size to stay very small on > the asset server, and that this could not work if applied to storing and > rendering mesh data. > > However, that whole argument was thrown out the window after people kept > demanding precision in sculpted shapes, and some time ago someone at LL > said "Okay, FINE, we will allow the option of lossless compression for > RGB sculpt-map uploads" and support for this lossless uploading has been > added into the viewer. > > > > So, uh, if lossless compression of sculpted primitives is permitted, > doesn't that mean that there could equally be support for lossless > compressed 3D mesh uploads, like traditional 3D editors use? > > There apparently isn't really any reason to prevent mesh uploads > anymore, at least as long as the meshes are very small and simple, and > the largest uploaded mesh byte size is equal to or smaller than the most > randomized, incompressible compressed sculpt-map. > > > > Allowing use of small meshes would be more efficient for the 3D renderer > anyway. Since sculpts have a fixed number of triangles, if your model > does not need the triangles for detail then they need to be "bunched up" > into a pile to get them out of the way, possibly tucked inside the model > so they don't show. But these unnecessary bunched up triangles are still > being processed by the 3D renderer whether or not they are needed. > > LL's own sample sculpt maps demonstrate this problem, like with the > S-shaped sculpt that has a ton of prims scrunched up on it, and which > could drop 50% or more of the triangle faces on it and still look good. > > So sculpted prims actually add to 3D scene rendering lag and contribute > to a lower framerate and poor performance because they do not and cannot > "turn off" unneeded triangle faces, vs a mesh which just simply would > not include any more detail triangles than the mesh actually requires. > > > > But there seems to be major LL heel-dragging against implementing actual > 3D mesh support and making models a heck of a lot easier to build in > external editors, vs the arcanary of sculpts that very few people > understand or can use effectively to reduce prim usage. > > So, I am not expecting this post will change anything. But oh well, I > thought I would bring up this small detail for discussion. The sldev > list has been pretty quiet lately anyway.. ;-) > > - Scalar Tardis / Dale Mahalko > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 teravus at gmail.com Thu Mar 19 20:28:57 2009 From: teravus at gmail.com (Teravus Ovares) Date: Thu, 19 Mar 2009 23:28:57 -0400 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: <49C308DC.8020901@kitware.com> References: <49C308DC.8020901@kitware.com> Message-ID: <34cc66250903192028j3e5e973boc6d96195c433451d@mail.gmail.com> Another thought here is.. at least with sculpted prim there are a few things.. as far as the renderer. There is a known number of vertices and you can index them by texture UUID so you only have to keep 1 copy around per texture in memory. Making sculpted prim is somewhat hard. This reduces the number of them out there thereby keeping a good relation between the scene complexity and 'user work required to make the scene complex'.. which is important for worlds with user created content. There are quite a few number of formats for 3d mesh. Some, very convoluted to implement. Some not so. A couple of other concepts that one must think about when dealing with this is, Bones? Skinning? morphs? Normals? binormals? Object heirarchy---> Linkset conversion?. These are all pretty simple for Sculpted prim. Now that I got that out of the way... gimme gimme support for 3d meshes! Regards Teravus On 3/19/09, Luis Ibanez wrote: > > Hi Dale, > > I agree with you on this point. > > It is currently the case that due to the lack of support for raw meshes, > users have to go about composing complex shapes by combining many prims, > most of which end up being obscured inside others just to get the final > form as the envelop of the group. The final result is that the client > has to render a large amount of triangles, many of which are simply not > visible. > > I can see as well, that there is a point in limiting the size of meshes > that users can upload, and as you suggest, a mesh that has storage cost > and a rendering cost similar to current images should be allowed since > it doesn't diminish the performance of the client or the server. > > This may be a situation where it is not possible to find a "one size fit > all" solution. For example, Avatars probably shouldn't be allowed to > carry meshes that are too large or complicated. While owners of regions > should be allowed, (and allowed to authorize others) to place complex > meshes in their local sites. For example, I can imagine a University > Campus that has an anatomical display, wanting to use raw meshes for > rendering livers, hearts, lungs, arteries... etc. > > If the extra complexity of the meshes actually result in a higher server > and storage cost, this should be then offered as an option to the region > owners (for a price). Many may not need this features, but for others > they are vital. > > As an example, I was visiting recently an educational display where a > Heart model is shown cut open. The heart was made out of prims (a lot of > work, and very well done), but it could have made with less effort and > better looking by using a raw mesh. > > > Luis > > > ------------------ > Dale Mahalko wrote: > > It occurred to me recently that LL's reasoning for not supporting raw 3D > > meshes as a prim type is basically invalid, what with how SL functions > > right now. > > > > The whole premise behind sculpted primitives was the idea that > > wavelet/JPEG lossy compression could be used to store "organic" shapes > > that don't have a very definite shape or form. The lossy wavelet > > compression of the RGB map allows the data size to stay very small on > > the asset server, and that this could not work if applied to storing and > > rendering mesh data. > > > > However, that whole argument was thrown out the window after people kept > > demanding precision in sculpted shapes, and some time ago someone at LL > > said "Okay, FINE, we will allow the option of lossless compression for > > RGB sculpt-map uploads" and support for this lossless uploading has been > > added into the viewer. > > > > > > > > So, uh, if lossless compression of sculpted primitives is permitted, > > doesn't that mean that there could equally be support for lossless > > compressed 3D mesh uploads, like traditional 3D editors use? > > > > There apparently isn't really any reason to prevent mesh uploads > > anymore, at least as long as the meshes are very small and simple, and > > the largest uploaded mesh byte size is equal to or smaller than the most > > randomized, incompressible compressed sculpt-map. > > > > > > > > Allowing use of small meshes would be more efficient for the 3D renderer > > anyway. Since sculpts have a fixed number of triangles, if your model > > does not need the triangles for detail then they need to be "bunched up" > > into a pile to get them out of the way, possibly tucked inside the model > > so they don't show. But these unnecessary bunched up triangles are still > > being processed by the 3D renderer whether or not they are needed. > > > > LL's own sample sculpt maps demonstrate this problem, like with the > > S-shaped sculpt that has a ton of prims scrunched up on it, and which > > could drop 50% or more of the triangle faces on it and still look good. > > > > So sculpted prims actually add to 3D scene rendering lag and contribute > > to a lower framerate and poor performance because they do not and cannot > > "turn off" unneeded triangle faces, vs a mesh which just simply would > > not include any more detail triangles than the mesh actually requires. > > > > > > > > But there seems to be major LL heel-dragging against implementing actual > > 3D mesh support and making models a heck of a lot easier to build in > > external editors, vs the arcanary of sculpts that very few people > > understand or can use effectively to reduce prim usage. > > > > So, I am not expecting this post will change anything. But oh well, I > > thought I would bring up this small detail for discussion. The sldev > > list has been pretty quiet lately anyway.. ;-) > > > > - Scalar Tardis / Dale Mahalko > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 stickman at gmail.com Thu Mar 19 20:39:15 2009 From: stickman at gmail.com (Stickman) Date: Thu, 19 Mar 2009 20:39:15 -0700 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: <34cc66250903192028j3e5e973boc6d96195c433451d@mail.gmail.com> References: <49C308DC.8020901@kitware.com> <34cc66250903192028j3e5e973boc6d96195c433451d@mail.gmail.com> Message-ID: > gimme gimme support for 3d meshes! Qarl put up an old survey on Jira back in August '08. The options are: -Work on Mesh import -improve existing tools The Jira to vote for improving existing tools is here: http://jira.secondlife.com/browse/MISC-1495 The Jira to work on mesh import is here: http://jira.secondlife.com/browse/MISC-1494 Also, here's an actual new feature request for mesh import/export, which has less votes than Qarl's survey about it: http://jira.secondlife.com/browse/SVC-2634 I dunno about the whole "export" part, but importing meshes would be nice. People would find a way to decompile them anyway, but no reason to make it easier on them. Stickman From boy.lane at yahoo.com Thu Mar 19 21:44:38 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Fri, 20 Mar 2009 12:44:38 +0800 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? Message-ID: <001001c9a916$94ef1180$6500a8c0@hp> I would like to bring up an issue here that is ongoing for a while, it is not directly related to a technical problem but it directly affects code contributions and intellectual property. Or to say it in short it's a slap in the face of every single contributor to the SL viewer code. Openlifegrid.com and it's owner Sakai Openlife (RL:Steve Sima) were repeatedly and by several people requested to provide the GPLed sources for the OLG viewer which is a fork of the official Linden viewer. Requests in their forum, via the Openlife contact form and via direct email are simply deleted or ignored. The only conclusion is that OLG intentional refuses to follow GPL licensing they accepted by using the Linden Lab licensed sources. This is now ongoing for months. One month back and under fire from outside Sakai finally opened a new website 3dxviewer.com which was meant to be used for all OL viewer related issues. A source code package, dated 22 Feb 2009 and containing sources in an older internal build 84 (about Jan 2009) were posted. This was outdated code at the time of posting. In the meantime OLG distributes binaries in build 160. As OLG changed the protocol, became incompatible to SL/Opensim and locked all other viewers out this is part of an attempt to use GPLed code and turn it into closed source. Knowledge, code contribution and expertise from both SL/3rd party viewers as well as the Opensim project are taken in by OLG and promoted as their own developments. Nothing at all is given back either to the viewer or the Opensim community and as a result OLG was removed from the Opensim project some time ago. Linden Lab encouraged everyone to report viewer licensing violations as in here: http://www.massively.com/2009/02/21/linden-lab-invites-reports-of-viewer-license-violations. They were reported several times from several people. However I don't know if there will be any internal follow up or response from Linden Lab. I would like to ask everybody here, including Linden's, what your opinion about this is, and what eventual follow up actions would make sense. That's not about being a GPL fascist as Henri likes to say, but I think OLG / Sakai went here a bit too far. It concerns everyone who works with the viewer. For more details you may want to have a look at http://www.sluniverse.com/php/vb/other-grids-virtual-worlds/26798-openlifegrid-continues-violate-gpl.html Sorry for posting this here, but I think it is important for LL as well as all 3rd party viewer developers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090320/92102f4e/attachment.htm From me at signpostmarv.name Thu Mar 19 22:37:15 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri, 20 Mar 2009 05:37:15 +0000 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: References: <49C2E92C.1050505@signpostmarv.name> Message-ID: <49C32B8B.1040009@signpostmarv.name> If user-created meshes had skeletons, doesn't that mean that llRequestPermissions(lllGetKey(),PERMISSION_ANIMATION); would allow people to use BVH to animate a mesh ? ~ Marv. Dahlia Trimble wrote: > There must be some support for skeleton or morph animation of meshes > in the viewer as the avatars use those techniques. I have no idea if > they could be applied to other meshes. > > On Thu, Mar 19, 2009 at 5:54 PM, SignpostMarv Martin > > wrote: > > Didn't I read something about the possibility for sculpties to be > animated/manipulated with shader language code ? > > How would arbitrary meshes be animated/manipulated ? > > > ~ Marv. > > Dahlia Trimble wrote: > > One advantage sculpts have is they require little or no > modifications to the SL asset storage/distribution model. I'm > not sure how other mesh storage methods would fit into this > model, but I suspect some modifications would be required. > > One problem I have with sculpties is the lack of precision for > the vertex elements as a result of quantifying them to 8 bit > integers to convert them to a color. Another is the need for > square or rectangular arrays of vertices which makes some > techniques of free form mesh modeling difficult or impossible > as arbitrary polygons cannot be added or deleted. > > Still, I am impressed with the cleverness of sculpted prims > and although I do share your desire for more flexible means of > designing meshes for SL, I am grateful that sculpties exist > and are being improved upon. > > On Thu, Mar 19, 2009 at 4:53 PM, Dale Mahalko > > >> wrote: > > It occurred to me recently that LL's reasoning for not > supporting > raw 3D meshes as a prim type is basically invalid, what > with how > SL functions right now. > The whole premise behind sculpted primitives was the > idea that > wavelet/JPEG lossy compression could be used to store "organic" > shapes that don't have a very definite shape or form. The lossy > wavelet compression of the RGB map allows the data size to stay > very small on the asset server, and that this could not work if > applied to storing and rendering mesh data. > However, that whole argument was thrown out the window > after > people kept demanding precision in sculpted shapes, and > some time > ago someone at LL said "Okay, FINE, we will allow the option of > lossless compression for RGB sculpt-map uploads" and > support for > this lossless uploading has been added into the viewer. > So, uh, if lossless compression of sculpted > primitives is > permitted, doesn't that mean that there could equally be > support > for lossless compressed 3D mesh uploads, like traditional 3D > editors use? > There apparently isn't really any reason to prevent > mesh uploads > anymore, at least as long as the meshes are very small and > simple, > and the largest uploaded mesh byte size is equal to or smaller > than the most randomized, incompressible compressed sculpt-map. > Allowing use of small meshes would be more > efficient for the 3D > renderer anyway. Since sculpts have a fixed number of > triangles, > if your model does not need the triangles for detail then they > need to be "bunched up" into a pile to get them out of the way, > possibly tucked inside the model so they don't show. But these > unnecessary bunched up triangles are still being processed > by the > 3D renderer whether or not they are needed. > LL's own sample sculpt maps demonstrate this problem, > like with > the S-shaped sculpt that has a ton of prims scrunched up on > it, and which could drop 50% or more of the triangle faces > on it > and still look good. > So sculpted prims actually add to 3D scene rendering > lag and > contribute to a lower framerate and poor performance > because they > do not and cannot "turn off" unneeded triangle faces, vs a mesh > which just simply would not include any more detail > triangles than > the mesh actually requires. > But there seems to be major LL heel-dragging > against implementing > actual 3D mesh support and making models a heck of a lot > easier to > build in external editors, vs the arcanary of sculpts that very > few people understand or can use effectively to reduce prim > usage. > So, I am not expecting this post will change anything. > But oh > well, I thought I would bring up this small detail for > discussion. > The sldev list has been pretty quiet lately anyway.. ;-) > - Scalar Tardis / Dale Mahalko > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090320/45f6ade7/attachment-0001.bin From GordonWendt at gmail.com Fri Mar 20 00:23:20 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri, 20 Mar 2009 03:23:20 -0400 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <001001c9a916$94ef1180$6500a8c0@hp> References: <001001c9a916$94ef1180$6500a8c0@hp> Message-ID: <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> If You haven't already then pop an email off to licensing at lindenlab.com as mentioned in the massively article and hope for the best. On the broader issue, I'm no lawyer but I'm sure the people in LL's legal team realize that selective or nonenforcement of their rights makes it tougher for them to enforce their rights when they choose to and/or have to do so which is a good incentive for them to act on this. I'd say that people should all email them about the issue but unless they're blatantly ignoring you that would probably do more harm than good unless a Linden pops in and tells us they want us spamming the legal department. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090320/3539012d/attachment.htm From gareth at litesim.com Fri Mar 20 01:53:09 2009 From: gareth at litesim.com (Gareth Nelson) Date: Fri, 20 Mar 2009 08:53:09 +0000 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> References: <001001c9a916$94ef1180$6500a8c0@hp> <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> Message-ID: <61dbdd7d0903200153i5586fe15qe2907b3feec3a4f8@mail.gmail.com> Rob Linden has informed me previously that they're aware of this and the legal department will be acting on it. How they'll be acting on it i'm not sure as he wouldn't say, but this list isn't the right place to discuss it anyway (as anyone will tell you from my own posts previously). On Fri, Mar 20, 2009 at 7:23 AM, Gordon Wendt wrote: > If You haven't already then pop an email off to licensing at lindenlab.com as > mentioned in the massively article and hope for the best.? On the broader > issue, I'm no lawyer but I'm sure the people in LL's legal team realize that > selective or nonenforcement of their rights makes it tougher for them to > enforce their rights when they choose to and/or have to do so which is a > good incentive for them to act on this.? I'd say that people should all > email them about the issue but unless they're blatantly ignoring you that > would probably do more harm than good unless a Linden pops in and tells us > they want us spamming the legal department. > > -G.W. > > _______________________________________________ > 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 carlo at alinoe.com Fri Mar 20 11:15:28 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 20 Mar 2009 19:15:28 +0100 Subject: [sldev] 3D mesh support, vs lossless compressed sculpts In-Reply-To: References: Message-ID: <20090320181528.GA28877@alinoe.com> I have spend most of my time studying sculpties lately. They are indeed very limited. I definitely second support for a raw mesh (which hopefull will then also be possible to be used for avatar shapes!). The current situation is this: If a cam moves further away, the viewer switches to another LOD (level of detail), meaning that it switches from 33x33 points to 17x17 points, and finally to 9x9 points. The sculpties we are talking about do not like lossy compression: they are such that as soon as you throw away points the result is pure junk. LOD simply doesn't work for such sculpties (it works for rocks, not for chairs, or staircases). As a result, the designers of sculpties are forced to restrict themselves to 9x9 grids in the first place (8x8 rectangles): thus, the scultpie exists of 64 flat rectangles, where each rectangle exists of 32 triangles! That is 30 triangles MORE than needed :(. [ There is an additional problem that I ran into: for some scultpies the viewer doesn't even switch to 8x8/9x9, but switches to a totally unrelated 'sphere' shape. I have not yet been able to figure out under what circumstances this happens. If anyone can tell me why this happens and how it can be avoid, please! ] I have the following proposal: Currently sculpties work as follows: Consider an image of 64x64 pixels (24 bits each) 63 * + * + * + ... 62 * + * + * + ... + + + + + + ... 60 * + * + * + ... + + + + + + ... . . . + + + + + + ... 0 * + * + * + ... 0 2 4 ... Then in the highest LOD, all *'s are used, that is: All pixels with even coordinates, and instead of row and column 64, row and column 63 is used (because row/col 64 don't exist). Then, depending on the stitching type, some/all points in row's 0 and 63 and some/all points column 63 are also ignored. But in the 'plane' stitching type, all 33 rows and cols are used. One level of detail lower (17x17), the following points are used: 63 * + + + * + ... 62 + + + + + + ... + + + + + + ... 60 * + + + * + ... + + + + + + ... . . . + + + + + + ... 0 * + + + * + ... 0 2 4 ... In other words, continuing to consider 63 as 64, every row and column that is a multiple of 4. Wouldn't it make a lot more sense to use the 33x33 square of pixels with coordinates (x, y), where 0 <= x <= 32, and 0 <= y <= 32 for the highest LOD, and then use 33 <= x,y <= 50 for the next LOD and 51 <= x,y <= 59 for the last LOD? That way people can define their own LOD. Even better would be to not degrade the LOD at all these type of sculpties: that is simply not possible and doing so only demands to design 8x8 sculpties in order to make them still look acceptable at larger distances :( -- Carlo Wood From gigstaggart at gmail.com Fri Mar 20 11:55:59 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri, 20 Mar 2009 14:55:59 -0400 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> References: <001001c9a916$94ef1180$6500a8c0@hp> <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> Message-ID: <49C3E6BF.50703@gmail.com> Gordon Wendt wrote: > If You haven't already then pop an email off to licensing at lindenlab.com > as mentioned in the massively article > and hope for the best. On the broader issue, I'm no lawyer but I'm sure > the people in LL's legal team realize that selective or nonenforcement > of their rights makes it tougher for them to enforce their rights when > they choose to You are probably thinking of trademark law. Copyright does not have much of a concept of laches, because it has an express limitations period. A court might not be sympathetic if you allowed infringement just to increase the damages; such as waiting until a work you knew was infringing hit public release to get more out of the lawsuit... but other than that, you don't lose much by not enforcing a copyright promptly. -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/20090320/5466d0a0/attachment.bin From gareth at litesim.com Fri Mar 20 12:49:47 2009 From: gareth at litesim.com (Gareth Nelson) Date: Fri, 20 Mar 2009 19:49:47 +0000 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <49C3E6BF.50703@gmail.com> References: <001001c9a916$94ef1180$6500a8c0@hp> <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> <49C3E6BF.50703@gmail.com> Message-ID: <61dbdd7d0903201249x7e1373bcv444ddf01192200@mail.gmail.com> The bigger issue is the appearance of being lax. Even if they do eventually enforce the license terms, if it takes a long time to do so, then others aren't going to take it seriously. Personally I clamp down hard and fast on people who violate the GPL on my own work, I would hope that LL would clamp down hard too. On Fri, Mar 20, 2009 at 6:55 PM, Jason Giglio wrote: > Gordon Wendt wrote: >> If You haven't already then pop an email off to licensing at lindenlab.com >> as mentioned in the massively article >> and hope for the best. ?On the broader issue, I'm no lawyer but I'm sure >> the people in LL's legal team realize that selective or nonenforcement >> of their rights makes it tougher for them to enforce their rights when >> they choose to > > You are probably thinking of trademark law. ?Copyright does not have > much of a concept of laches, because it has an express limitations period. > > A court might not be sympathetic if you allowed infringement just to > increase the damages; such as waiting until a work you knew was > infringing hit public release to get more out of the lawsuit... but > other than that, you don't lose much by not enforcing a copyright promptly. > > -Jason > > _______________________________________________ > 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 Fri Mar 20 14:02:13 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 20 Mar 2009 14:02:13 -0700 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <001001c9a916$94ef1180$6500a8c0@hp> References: <001001c9a916$94ef1180$6500a8c0@hp> Message-ID: <49C40455.9060000@lindenlab.com> On 3/19/09 9:44 PM, Boy Lane wrote: > > I would like to ask everybody here, including Linden's, what your > opinion about this is, and what eventual follow up actions would make > sense. That's not about being a GPL fascist as Henri likes to say, but > I think OLG / Sakai went here a bit too far. It concerns everyone who > works with the viewer. For more details you may want to have a look at > http://www.sluniverse.com/php/vb/other-grids-virtual-worlds/26798-openlifegrid-continues-violate-gpl.html > Insisting on GPL compliance is not fascism. The license is quite generous, far more than most proprietary software licenses. My recommendation is that you make high-quality GPL violation reports to the licensing at lindenlab.com alias. What I mean by "high quality": the date which you received the binaries, the date which you requested the source code, any correspondence that would indicate that compliance is not forthcoming, and in particular, which part of the GPL you believe the violator is in violation of. Imagine your email being submitted as evidence/testimony in a legal action. Linden Lab will rarely, if ever, publicize legal disputes with third parties, since that tends to have a negative effect on any conversation intended to resolve the dispute. So, please don't assume that lack of public action is the same as lack of action. That said, you should never assume that we know about a particular violation, or that someone else has surely already reported all of the information needed to document the violation in such a way as to make it actionable. Rob From gareth at litesim.com Fri Mar 20 14:18:07 2009 From: gareth at litesim.com (Gareth Nelson) Date: Fri, 20 Mar 2009 21:18:07 +0000 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <49C40455.9060000@lindenlab.com> References: <001001c9a916$94ef1180$6500a8c0@hp> <49C40455.9060000@lindenlab.com> Message-ID: <61dbdd7d0903201418u14c9d728oa83fe865f09ad029@mail.gmail.com> For reference, a good set of questions to include answers to: http://www.fsf.org/licensing/licenses/gpl-violation.html On Fri, Mar 20, 2009 at 9:02 PM, Rob Lanphier wrote: > On 3/19/09 9:44 PM, Boy Lane wrote: >> >> I would like to ask everybody here, including Linden's, what your >> opinion about this is, and what eventual follow up actions would make >> sense. That's not about being a GPL fascist as Henri likes to say, but >> I think OLG / Sakai went here a bit too far. It concerns everyone who >> works with the viewer. For more details you may want to have a look at >> http://www.sluniverse.com/php/vb/other-grids-virtual-worlds/26798-openlifegrid-continues-violate-gpl.html >> > > > Insisting on GPL compliance is not fascism. ?The license is quite > generous, far more than most proprietary software licenses. > > My recommendation is that you make high-quality GPL violation reports to > the licensing at lindenlab.com alias. ?What I mean by "high quality": ?the > date which you received the binaries, the date which you requested the > source code, any correspondence that would indicate that compliance is > not forthcoming, and in particular, which part of the GPL you believe > the violator is in violation of. ?Imagine your email being submitted as > evidence/testimony in a legal action. > > Linden Lab will rarely, if ever, publicize legal disputes with third > parties, since that tends to have a negative effect on any conversation > intended to resolve the dispute. ?So, please don't assume that lack of > public action is the same as lack of action. ?That said, you should > never assume that we know about a particular violation, or that someone > else has surely already reported all of the information needed to > document the violation in such a way as to make it actionable. > > 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 > From khyota at redhyena.net Fri Mar 20 15:34:43 2009 From: khyota at redhyena.net (Khyota) Date: Fri, 20 Mar 2009 18:34:43 -0400 Subject: [sldev] Linux standalone built WITH llmozlib In-Reply-To: <20090320022203.53277.qmail@web3708.mail.tnz.yahoo.co.jp> References: <20090320022203.53277.qmail@web3708.mail.tnz.yahoo.co.jp> Message-ID: <200903201834.43234.khyota@redhyena.net> On Thursday 19 March 2009 10:22:03 Alissa Sabre wrote: > Hi, > > I have a question. How can I make a standalone build WITH llmozlib support > on Linux? I'm currently working on 1.22.11 source, BTW. We have mozlib packages for ubuntu, debian, arch, and gentoo, if your using another distroy ou may need to compile it on your own. Ive never compiled the old llmozlib, but the new qtwebkit version. pretty easy :) http://wiki.secondlife.com/wiki/QtWebKit old llmozlib http://wiki.secondlife.com/wiki/Compiling_the_viewer_libraries_LLMozLib_(Linux) From alissa_sabre at yahoo.co.jp Fri Mar 20 20:05:09 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat, 21 Mar 2009 12:05:09 +0900 Subject: [sldev] How can I use distcc outside LL? Message-ID: <1G64f76ds8feefe5eY9u8rds.alissa_sabre@yahoo.co.jp> Developers, Another question. Although I'm not sure, I have a feeling that the current develop.py enables distcc on Linux only when invoked in LL. It seems that develop.py creates makefiles containing hard-coded /usr/bin/g++ in them when invoked outside LL. How can I use distcc to build viewer? Thanks again in advance, Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From tateru.nino at gmail.com Sat Mar 21 05:23:32 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 21 Mar 2009 23:23:32 +1100 Subject: [sldev] Continued GPL violations by Openlifegrid.com - Options? In-Reply-To: <49C3E6BF.50703@gmail.com> References: <001001c9a916$94ef1180$6500a8c0@hp> <493033a70903200023te68a286p3ae72ee6b7ee5c62@mail.gmail.com> <49C3E6BF.50703@gmail.com> Message-ID: <49C4DC44.3070903@gmail.com> It seems to me, though, that because there are multiple copyright holders here (due to patches, contribution agreements, etc) - copyright holders *other* than Linden Lab will likely seek to take action if the Lab doesn't tell its fellow copyright holders what action it is taking or doesn't take any soon. That's the vibe I'm getting from all of this at the moment. If it were me, I'd probably have shot off a C&D already, but I'm old and tired and my copyrights get infringed many times a year, so perhaps I'm less patient on the matter than some. After the first couple of hundred infringements or so you tend to dispense with the notion that someone's cashing-in on your work out of ignorance, or that they're planning to comply but aren't quite there yet. Especially when someone else makes more money from your own work than you are :) Jason Giglio wrote: > Gordon Wendt wrote: > >> If You haven't already then pop an email off to licensing at lindenlab.com >> as mentioned in the massively article >> and hope for the best. On the broader issue, I'm no lawyer but I'm sure >> the people in LL's legal team realize that selective or nonenforcement >> of their rights makes it tougher for them to enforce their rights when >> they choose to >> > > You are probably thinking of trademark law. Copyright does not have > much of a concept of laches, because it has an express limitations period. > > A court might not be sympathetic if you allowed infringement just to > increase the damages; such as waiting until a work you knew was > infringing hit public release to get more out of the lawsuit... but > other than that, you don't lose much by not enforcing a copyright promptly. > > -Jason > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20090321/2f3ef493/attachment.htm From robin.cornelius at gmail.com Sat Mar 21 16:18:04 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat, 21 Mar 2009 23:18:04 +0000 Subject: [sldev] Linux standalone built WITH llmozlib In-Reply-To: <200903201834.43234.khyota@redhyena.net> References: <20090320022203.53277.qmail@web3708.mail.tnz.yahoo.co.jp> <200903201834.43234.khyota@redhyena.net> Message-ID: <49C575AC.7030801@gmail.com> Khyota wrote: > > http://wiki.secondlife.com/wiki/QtWebKit > > old llmozlib > The xulrunner based one i did for standalone was detailed at :- http://www.byteme.org.uk/mozlib.html but you also need a tiny viewer patch to get the linkage correct which is in my debain repro if you are interested and i could fish it out for you. Or you can build your own mozilla based on as Khyota already linked you too. 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/20090321/c2ff49fa/attachment.pgp From alissa_sabre at yahoo.co.jp Sat Mar 21 20:28:53 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 22 Mar 2009 12:28:53 +0900 Subject: [sldev] Linux standalone built WITH llmozlib In-Reply-To: <200903201834.43234.khyota@redhyena.net> References: <200903201834.43234.khyota@redhyena.net> Message-ID: <74ds4s0idu9ds4L39ds6nif.alissa_sabre@yahoo.co.jp> > > I have a question. How can I make a standalone build WITH llmozlib support > > on Linux? I'm currently working on 1.22.11 source, BTW. > > We have mozlib packages for ubuntu, debian, arch, and gentoo, if your using > another distro you may need to compile it on your own. I'm using Fedora. So, I was just unlucky picking up a *wrong* distribution from the beginning... (I've been using Fedora before got involved in SL.) Anyway, thank you for the answer. > the new qtwebkit version > > http://wiki.secondlife.com/wiki/QtWebKit Qt? I'm very afraid SL switches to Qt from GTK, because I've been investing a lot to GTK now... (See VWR-2261 to know what I'm doing.) -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From alissa_sabre at yahoo.co.jp Sat Mar 21 20:40:50 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 22 Mar 2009 12:40:50 +0900 Subject: [sldev] How can I use distcc outside LL? In-Reply-To: <1G64f76ds8feefe5eY9u8rds.alissa_sabre@yahoo.co.jp> References: <1G64f76ds8feefe5eY9u8rds.alissa_sabre@yahoo.co.jp> Message-ID: <1dvdkwGGdcdsh24xfY5ccd5.alissa_sabre@yahoo.co.jp> > How can I use distcc to build viewer? I got an answer inworld. This message is for a record. The current develop.py *does* support distcc outside LL, although we need to specify it in a strange way. What we need to do to use distcc is to pass an environment variable CXX containing distcc command prefix when invoking develop.py, e.g., CXX="distcc i386-redhat-linux-g++" python develop.py configure The generated makefiles always use distcc, then. This is just an execuse, but I was confused to see a lot of distcc-specific codes and an option (--no-distcc) in develop.py and to find that all those distcc features are only for LL developpers... Alissa -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From alissa_sabre at yahoo.co.jp Sat Mar 21 21:24:07 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 22 Mar 2009 13:24:07 +0900 Subject: [sldev] Build procedure for viewer from svn trunk? Message-ID: <79dsdkwcf14dsdmzfe24fP4r.alissa_sabre@yahoo.co.jp> Yet another question. I grabbed the set of viewer source from the public subversion repository as: svn co https://svn.secondlife.com/svn/linden/trunk I found the trunk tree lacks several files and develop.py configure fails. I found that most (if not all; I'm not sure) of the missing files are those distributed in artwork bundle in tarball. Where are the artwork files that match with the trunc viewer? What is the appropriate procedure to build the viewer from svn trunk? What pages of SL wiki I should read to know these? Thanks in advance, Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From johnniecarling at gmail.com Sat Mar 21 21:46:33 2009 From: johnniecarling at gmail.com (Johnnie Carling) Date: Sun, 22 Mar 2009 00:46:33 -0400 Subject: [sldev] Build procedure for viewer from svn trunk? In-Reply-To: <79dsdkwcf14dsdmzfe24fP4r.alissa_sabre@yahoo.co.jp> References: <79dsdkwcf14dsdmzfe24fP4r.alissa_sabre@yahoo.co.jp> Message-ID: <200903220046.33366.johnniecarling@gmail.com> > Where are the artwork files that match with the trunc viewer? What is > the appropriate procedure to build the viewer from svn trunk? You can find the URLs in /doc/asset_urls.txt I use a bash script to grab them (mostly taken from one of Henri's scripts) #!/bin/bash PATH_TO_SOURCES="/home/johnnie/projects/secondlife/trunk" chmod +x $PATH_TO_SOURCES/doc/asset_urls.txt . $PATH_TO_SOURCES/doc/asset_urls.txt echo "Removing old downloaded packages....." # clean up old downloaded packages rm -fr linden/ rm -f slviewer-artwork* rm -f slviewer-*-libs* echo "done" # Download new artwork and libs echo "Downloading new artwork and lib packages" wget $SLASSET_ART wget $SLASSET_LIBS_LINUXI386 unzip slviewer-artwork* tar -xvzf slviewer-*-libs* echo "done" echo "Copying to source directory" cp linden/* $PATH_TO_SOURCES/ -r echo "done" echo "finished" From robin.cornelius at gmail.com Sun Mar 22 03:11:30 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun, 22 Mar 2009 10:11:30 +0000 Subject: [sldev] Linux standalone built WITH llmozlib In-Reply-To: <74ds4s0idu9ds4L39ds6nif.alissa_sabre@yahoo.co.jp> References: <200903201834.43234.khyota@redhyena.net> <74ds4s0idu9ds4L39ds6nif.alissa_sabre@yahoo.co.jp> Message-ID: <49C60ED2.3090306@gmail.com> Alissa Sabre wrote: >>> I have a question. How can I make a standalone build WITH llmozlib support >>> on Linux? I'm currently working on 1.22.11 source, BTW. >> We have mozlib packages for ubuntu, debian, arch, and gentoo, if your using >> another distro you may need to compile it on your own. > > I'm using Fedora. So, I was just unlucky picking up a *wrong* > distribution from the beginning... (I've been using Fedora before got > involved in SL.) > > Anyway, thank you for the answer. > >> the new qtwebkit version >> >> http://wiki.secondlife.com/wiki/QtWebKit > > Qt? > > I'm very afraid SL switches to Qt from GTK, because I've been > investing a lot to GTK now... (See VWR-2261 to know what I'm doing.) The mozlib engine and if its Qt/Gtk or anything else has very little/zero impact on the rest of the viewer so I would not fear that it will impact your other work. In theory the mozlib could drop Qt and implement a pure webkit backend, however this is quite a bit of work and currently the Qt implementation of webkit provides the foundations necessary. 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/20090322/f1bc2c20/attachment.pgp From sllists at boroon.dasgupta.ch Sun Mar 22 05:13:12 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 22 Mar 2009 13:13:12 +0100 Subject: [sldev] Build procedure for viewer from svn trunk? In-Reply-To: <79dsdkwcf14dsdmzfe24fP4r.alissa_sabre@yahoo.co.jp> References: <79dsdkwcf14dsdmzfe24fP4r.alissa_sabre@yahoo.co.jp> Message-ID: <49C62B58.5030604@boroon.dasgupta.ch> Alissa Sabre schrieb: > What is > the appropriate procedure to build the viewer from svn trunk? What > pages of SL wiki I should read to know these? http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake is probably still the most complete guide in the wiki for non custom builds. cheers Boroondas From dale at daleglass.net Sun Mar 22 11:11:31 2009 From: dale at daleglass.net (Dale Glass) Date: Sun, 22 Mar 2009 19:11:31 +0100 Subject: [sldev] Group voting is going to be removed? Message-ID: <200903221911.37217.dale@daleglass.net> Hi! As a part of getting development things going again, I fixed a bug with the group proposals history ( http://jira.secondlife.com/browse/VWR-12532 ), but some time later I found a post by Soft at the bottom of this bug: http://jira.secondlife.com/browse/VWR-1146: > Soft Linden added a comment - 19/Jan/09 02:38 PM > Group voting won't exist anymore as of ~1.23 viewers. People I asked in-world didn't seem to be aware of this, and there was no other explanation, so I wanted to know: Why is this functionality being removed, and will anything replace it? -------------- 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/20090322/3b555513/attachment-0001.pgp From soft at lindenlab.com Sun Mar 22 11:32:03 2009 From: soft at lindenlab.com (Soft) Date: Sun, 22 Mar 2009 13:32:03 -0500 Subject: [sldev] Group voting is going to be removed? In-Reply-To: <200903221911.37217.dale@daleglass.net> References: <200903221911.37217.dale@daleglass.net> Message-ID: On Sun, Mar 22, 2009 at 1:11 PM, Dale Glass wrote: > Hi! > > As a part of getting development things going again, I fixed a bug with the > group proposals history ( http://jira.secondlife.com/browse/VWR-12532 ), > but some time later I found a post by Soft at the bottom of this bug: > http://jira.secondlife.com/browse/VWR-1146: > >> Soft Linden added a comment - 19/Jan/09 02:38 PM >> Group voting won't exist anymore as of ~1.23 viewers. > > People I asked in-world didn't seem to be aware of this, and there was no > other explanation, so I wanted to know: Why is this functionality being > removed, and will anything replace it? It's being removed because there are still a number of bugs (including significant database load issues) in the voting system, however the metrics team found that the feature is virtually unused. There is little engineering work in removing group voting, while there would be significant work in making the feature work and scale well. There isn't any replacement built into the viewer. The functionality could be reproduced with scripted objects or, where the voters are trusted, a SurveyMonkey link in a group announcement. From tom at streamsense.net Sun Mar 22 11:45:38 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Sun, 22 Mar 2009 18:45:38 +0000 Subject: [sldev] Group voting is going to be removed? Message-ID: <49C68752.3070106@streamsense.net> Soft wrote: > > It's being removed because there are still a number of bugs (including > significant database load issues) in the voting system, however the > metrics team found that the feature is virtually unused. If it's unused then it's not going to cause any load, is it? This seems pretty typical backwards thinking, to be honest... ~Tom From soft at lindenlab.com Sun Mar 22 11:57:04 2009 From: soft at lindenlab.com (Soft) Date: Sun, 22 Mar 2009 13:57:04 -0500 Subject: [sldev] Group voting is going to be removed? In-Reply-To: <49C68752.3070106@streamsense.net> References: <49C68752.3070106@streamsense.net> Message-ID: On Sun, Mar 22, 2009 at 1:45 PM, Thomas Grimshaw wrote: > Soft wrote: >> >> It's being removed because there are still a number of bugs (including >> significant database load issues) in the voting system, however the >> metrics team found that the feature is virtually unused. > > If it's unused then it's not going to cause any load, is it? ?This seems > pretty typical backwards thinking, to be honest... There are queries such as checking each group for active proposals that, as currently implemented, create load even if the feature isn't used. It's like 80,000 systems hanging off a mailserver. Even if no mail is being sent, that server isn't idle. From ordinal.malaprop at fastmail.fm Sun Mar 22 12:01:54 2009 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop at fastmail.fm) Date: Sun, 22 Mar 2009 19:01:54 +0000 Subject: [sldev] Group voting is going to be removed? In-Reply-To: References: <49C68752.3070106@streamsense.net> Message-ID: On 22 Mar 2009, at 18:57, Soft wrote: > There are queries such as checking each group for active proposals > that, as currently implemented, create load even if the feature isn't > used. It's like 80,000 systems hanging off a mailserver. Even if no > mail is being sent, that server isn't idle. I see the point with voting - it really isn't used a lot at all in my experience, though it is a useful function when it is - but can I ask whether there is a specific current push to fix _other_ group functions which create immense load and don't work very well? I'm sure you'd agree that, say, group chat is a bit of a horror. From dale at daleglass.net Sun Mar 22 12:01:58 2009 From: dale at daleglass.net (Dale Glass) Date: Sun, 22 Mar 2009 20:01:58 +0100 Subject: [sldev] Group voting is going to be removed? In-Reply-To: <49C68752.3070106@streamsense.net> References: <49C68752.3070106@streamsense.net> Message-ID: <200903222002.03938.dale@daleglass.net> On ??????????? 22 ????? 2009 19:45:38 Thomas Grimshaw wrote: > Soft wrote: > > It's being removed because there are still a number of bugs (including > > significant database load issues) in the voting system, however the > > metrics team found that the feature is virtually unused. > > If it's unused then it's not going to cause any load, is it? This seems > pretty typical backwards thinking, to be honest... > ~Tom Yeah, it sounds strange to me as well. I also noticed that the Proposals screen seems to load itself twice, so there you have a way to cut the load in half by fixing that. -------------- 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/20090322/fa5224e5/attachment.pgp From soft at lindenlab.com Sun Mar 22 12:11:25 2009 From: soft at lindenlab.com (Soft) Date: Sun, 22 Mar 2009 14:11:25 -0500 Subject: [sldev] Group voting is going to be removed? In-Reply-To: References: <49C68752.3070106@streamsense.net> Message-ID: On Sun, Mar 22, 2009 at 2:01 PM, wrote: > > On 22 Mar 2009, at 18:57, Soft wrote: > >> There are queries such as checking each group for active proposals >> that, as currently implemented, create load even if the feature isn't >> used. It's like 80,000 systems hanging off a mailserver. Even if no >> mail is being sent, that server isn't idle. > > I see the point with voting - it really isn't used a lot at all in my > experience, though it is a useful function when it is - but can I ask > whether there is a specific current push to fix _other_ group functions > which create immense load and don't work very well? I'm sure you'd agree > that, say, group chat is a bit of a horror. Yup. Generally, there's work on severing database dependencies so group, user, land, etc can be split apart and scaled and tuned independently. I'm not the best Linden to ask about that work - but the details I've seen are pretty cool. It could be worth a post to the tech section of our blog if you ask for more about it there. It's not really an sldev/open source issue. From TammyNowotny at mac.com Sun Mar 22 12:21:20 2009 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Sun, 22 Mar 2009 15:21:20 -0400 Subject: [sldev] Group voting is going to be removed? In-Reply-To: <200903221911.37217.dale@daleglass.net> References: <200903221911.37217.dale@daleglass.net> Message-ID: <49C68FB0.5@mac.com> Group voting has been periodically abused a lot by members who don't have group notice privileges as a means of spamming the group. Most large groups have disabled it. --Tammy Nowotny Dale Glass wrote: > Hi! > > As a part of getting development things going again, I fixed a bug with the > group proposals history ( http://jira.secondlife.com/browse/VWR-12532 ), > but some time later I found a post by Soft at the bottom of this bug: > http://jira.secondlife.com/browse/VWR-1146: > > >> Soft Linden added a comment - 19/Jan/09 02:38 PM >> Group voting won't exist anymore as of ~1.23 viewers. >> > > People I asked in-world didn't seem to be aware of this, and there was no > other explanation, so I wanted to know: Why is this functionality being > removed, and will anything replace it? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20090322/03b28fc3/attachment.htm From dale at daleglass.net Sun Mar 22 12:42:19 2009 From: dale at daleglass.net (Dale Glass) Date: Sun, 22 Mar 2009 20:42:19 +0100 Subject: [sldev] Group voting is going to be removed? In-Reply-To: <49C68FB0.5@mac.com> References: <200903221911.37217.dale@daleglass.net> <49C68FB0.5@mac.com> Message-ID: <200903222042.24473.dale@daleglass.net> On ??????????? 22 ????? 2009 20:21:20 Tammy Nowotny wrote: > Group voting has been periodically abused a lot by members who don't > have group notice privileges as a means of spamming the group. Most > large groups have disabled it. So were particles, and objects, and scripts, and... But that doesn't mean there's no good use for it. -------------- 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/20090322/8887b8c2/attachment.pgp From open at autistici.org Sun Mar 22 13:37:40 2009 From: open at autistici.org (Opensource Obscure) Date: Sun, 22 Mar 2009 20:37:40 +0000 Subject: [sldev] =?utf-8?q?Group__voting_is_going_to_be_removed=3F?= In-Reply-To: <200903222042.24473.dale@daleglass.net> References: <200903221911.37217.dale@daleglass.net> <49C68FB0.5@mac.com> <200903222042.24473.dale@daleglass.net> Message-ID: <6ace59258d95ffc5eee53e1761812e8f@localhost> On Sun, 22 Mar 2009 20:42:19 +0100, Dale Glass wrote: > On ??????????? 22 ????? 2009 20:21:20 Tammy Nowotny wrote: >> Group voting has been periodically abused a lot by members who don't >> have group notice privileges as a means of spamming the group. Most >> large groups have disabled it. > > So were particles, and objects, and scripts, and... > > But that doesn't mean there's no good use for it. In principle. But in practice, while all features you mentioned are very relevant to most SL activities and usecases, group voting brought little value to SL, according to my experience. This also meant that group owners rarely bothered to learn how to correctly set up permissions related to this feature. I'm not happy in principle with removing any existing feature, but in this specific case I think it's a sound move - especially because removing this feature is supposed to improve the reliability of another (more important) feature. FWIW Opensource Obscure From dale at daleglass.net Sun Mar 22 13:39:51 2009 From: dale at daleglass.net (Dale Glass) Date: Sun, 22 Mar 2009 21:39:51 +0100 Subject: [sldev] Group voting is going to be removed? In-Reply-To: References: <200903221911.37217.dale@daleglass.net> <200903222042.24473.dale@daleglass.net> Message-ID: <200903222139.55615.dale@daleglass.net> On ??????????? 22 ????? 2009 21:12:20 Lear Cale wrote: > Voting isn't used simply because IT DOESN'T WORK. You never get to see > the results. > > If it WORKED, it might get used. The "nobody uses it" argument is > invalid. Doesn't work in what way? If you mean that in some groups, it gets struck forever on "retrieving", then I fixed that yesterday. -------------- 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/20090322/fa0a4abc/attachment.pgp From problem.quandry at gmail.com Sun Mar 22 21:08:11 2009 From: problem.quandry at gmail.com (Problem Quandry) Date: Sun, 22 Mar 2009 21:08:11 -0700 Subject: [sldev] LLViewerObject and hover text Message-ID: I'm trying to understand the viewer source code a bit better, but I'm still new to it and I'm stumped trying to figure something out. Hopefully someone can help me out. Objects rendered by the viewer seem to be of type LLViewerObject, and objects can have hover text set on them. So, I assume there's probably some way that the text is connected to the LLViewerObject, but I can't figure out how. Could someone give me an example of referencing an object's hover text using an instance of LLViewerObject object? Something like: LLViewerObject obj; obj->mText???? Also, if there's some resource that shows a class architecture diagram or any other useful design info on the viewer's code organization, I'd love a hint on where to find it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090322/9677a971/attachment.htm From alissa_sabre at yahoo.co.jp Sun Mar 22 20:56:30 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon, 23 Mar 2009 12:56:30 +0900 Subject: [sldev] Linux standalone built WITH llmozlib In-Reply-To: <49C60ED2.3090306@gmail.com> References: <200903201834.43234.khyota@redhyena.net> <74ds4s0idu9ds4L39ds6nif.alissa_sabre@yahoo.co.jp> <49C60ED2.3090306@gmail.com> Message-ID: <78fuads5ds4ds8eL8G94ds6.alissa_sabre@yahoo.co.jp> > > Qt? > > > > I'm very afraid SL switches to Qt from GTK, because I've been > > investing a lot to GTK now... (See VWR-2261 to know what I'm doing.) > > The mozlib engine and if its Qt/Gtk or anything else has very > little/zero impact on the rest of the viewer so I would not fear that it > will impact your other work. I'm still have some difficulty regarding an issue identified by SL-35450. That is, llmozlib's use of some GTK API affected the SL viewer's own XML parsing, and the viewer crushed under some condition. The exact cause is related to GTK's assumption of raw X11 event handling and the process' locale management. (If you want more details on this, please searc hthe old SLDev archive with the above issue id.) Currently, the workaround is included in the class LLWindowSDL, assuming the SL viewer's use of GTK API is limited. Because I'm working on the area, I need to workaround (or, to eliminate if possible) this issue ina different way. I guess Qt has it's own event loop and locale management policy. One possibility is switching to Qt solves the issue at all, but another possibility is it makes things work. Anyway I can't easily believe the change of llmozlib has no impact. I will test the new QtWebKit based llmozlib to see what happens, anyway. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From q at lindenlab.com Mon Mar 23 06:19:32 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon, 23 Mar 2009 09:19:32 -0400 Subject: [sldev] LLViewerObject and hover text In-Reply-To: References: Message-ID: <66E871E7-158B-4D59-BE9F-259DF0EAB39A@lindenlab.com> Well, I haven't worked with this area specifically, but from a quick look through the code, I think what you want is an instance of the LLHudText class (which is the type of the mText object). In llviewerobject.cpp, there's this code: // Setup object text if (!mText) { mText = (LLHUDText *)LLHUDObject::addHUDObject(LLHUDObject::LL_HUD_TEXT); mText->setFont(LLFontGL::sSansSerif); mText->setVertAlignment(LLHUDText::ALIGN_VERT_TOP); mText->setMaxLines(-1); mText->setSourceObject(this); mText->setOnHUDAttachment(isHUDAttachment()); } and then: mText->setColor(LLColor4(coloru)); mText->setStringUTF8(temp_string); Is that the hint you're looking for? See llhudtext.h/cpp for more. Q On Mar 23, 2009, at 12:08 AM, Problem Quandry wrote: > I'm trying to understand the viewer source code a bit better, but > I'm still new to it and I'm stumped trying to figure something out. > Hopefully someone can help me out. > > Objects rendered by the viewer seem to be of type LLViewerObject, > and objects can have hover text set on them. So, I assume there's > probably some way that the text is connected to the LLViewerObject, > but I can't figure out how. Could someone give me an example of > referencing an object's hover text using an instance of > LLViewerObject object? > > Something like: > > LLViewerObject obj; > obj->mText???? > > Also, if there's some resource that shows a class architecture > diagram or any other useful design info on the viewer's code > organization, I'd love a hint on where to find it. > > _______________________________________________ > 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 alissa_sabre at yahoo.co.jp Mon Mar 23 20:57:40 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue, 24 Mar 2009 12:57:40 +0900 Subject: [sldev] Filing a bug of svn trunk version? In-Reply-To: <200903220046.33366.johnniecarling@gmail.com> References: <200903220046.33366.johnniecarling@gmail.com> <49C62B58.5030604@boroon.dasgupta.ch> <79dsdkwcf14dsdmzfe24fP4r.alissa_sabre@yahoo.co.jp> Message-ID: <74ds4e44e6xkzzeL76owwnQd.alissa_sabre@yahoo.co.jp> Hi, there. Alissa, again. Thank you, Johnnie and Boroondas, for build instructions. I could build the trunk viewer on Linux, and am trying on Windos and MacOS, too. BTW, I found some issues on trunk viewer. What is the expecte channel to file a bug on svn trunk source? Should I submit the issue on public JIRA as usual? Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From soft at lindenlab.com Tue Mar 24 05:19:23 2009 From: soft at lindenlab.com (Soft) Date: Tue, 24 Mar 2009 07:19:23 -0500 Subject: [sldev] Filing a bug of svn trunk version? In-Reply-To: <74ds4e44e6xkzzeL76owwnQd.alissa_sabre@yahoo.co.jp> References: <49C62B58.5030604@boroon.dasgupta.ch> <200903220046.33366.johnniecarling@gmail.com> <74ds4e44e6xkzzeL76owwnQd.alissa_sabre@yahoo.co.jp> Message-ID: On Mon, Mar 23, 2009 at 10:57 PM, Alissa Sabre wrote: > Hi, there. ?Alissa, again. > > Thank you, Johnnie and Boroondas, for build instructions. ?I could > build the trunk viewer on Linux, and am trying on Windos and MacOS, > too. > > BTW, I found some issues on trunk viewer. ?What is the expecte channel > to file a bug on svn trunk source? ?Should I submit the issue on > public JIRA as usual? Yup. For the version, you can specify "source code" - it wouldn't hurt to include 1.23 in addition. Until that's exported on its own, there's a fair chance that anything you see in trunk/ is destined for 1.23. From chaosstar at gmail.com Tue Mar 24 05:59:19 2009 From: chaosstar at gmail.com (Ambrosia) Date: Tue, 24 Mar 2009 13:59:19 +0100 Subject: [sldev] Can anybody reproduce this trunk bug..? Message-ID: <9bb32d430903240559g1774f974m86374489aa3e208e@mail.gmail.com> Greetings, I was wondering, before I file a JIRA, can anybody confirm and/or reproduce the following bug with the 1.23 trunk code: * Take a notecard that contains an embedded object. Not a texture, not a script, but an actual object. * Try to take said object out of the notecard. My observation is a hang/crash of the viewer, and If I recall correctly, this isn't quite new, tho I've not seen it mentioned before. The reason I ask for reproduction is, given that normally such a bug would be found quickly, I'm not sure if it's something merely on my end of code things. --Chalice Yao From open at autistici.org Tue Mar 24 06:11:04 2009 From: open at autistici.org (Opensource Obscure) Date: Tue, 24 Mar 2009 13:11:04 +0000 Subject: [sldev] =?utf-8?q?Filing_a_bug_of_svn_trunk_version=3F?= In-Reply-To: References: <49C62B58.5030604@boroon.dasgupta.ch> <200903220046.33366.johnniecarling@gmail.com> <74ds4e44e6xkzzeL76owwnQd.alissa_sabre@yahoo.co.jp> Message-ID: <07d23f593f3d6ab5b46c70ffcbcca7ac@localhost> On Tue, 24 Mar 2009 07:19:23 -0500, Soft wrote: > On Mon, Mar 23, 2009 at 10:57 PM, Alissa Sabre > wrote: >> BTW, I found some issues on trunk viewer. ?What is the expecte channel >> to file a bug on svn trunk source? ?Should I submit the issue on >> public JIRA as usual? > > Yup. For the version, you can specify "source code" - it wouldn't hurt > to include 1.23 in addition. Until that's exported on its own, there's > a fair chance that anything you see in trunk/ is destined for 1.23. Yesterday I filed two bugs against the render-pipeline branch: http://jira.secondlife.com/browse/VWR-12555 http://jira.secondlife.com/browse/VWR-12556 I just updated them so that they read now "render-pipeline branch" in the Title field, "source code" in the Affects Version/s field and "Second Life 1.23.0 (114978) Mar 21 2009 19:06:43 (Developer)" in the Environment field. Is this ok? By the way, in which Office Hour are discussions about realtime shadows most welcome? I made a couple of videos using a render-pipeline viewer where some glitches can be seen and I'd like to discuss about them. I didn't report these ones into PJIRA yet. http://www.youtube.com/watch?v=c5VCcO7NFpo http://www.youtube.com/watch?v=cps7xYyEF7U ciao, Opensource Obscure From soft at lindenlab.com Tue Mar 24 06:19:26 2009 From: soft at lindenlab.com (Soft) Date: Tue, 24 Mar 2009 08:19:26 -0500 Subject: [sldev] Filing a bug of svn trunk version? In-Reply-To: <07d23f593f3d6ab5b46c70ffcbcca7ac@localhost> References: <49C62B58.5030604@boroon.dasgupta.ch> <200903220046.33366.johnniecarling@gmail.com> <07d23f593f3d6ab5b46c70ffcbcca7ac@localhost> Message-ID: On Tue, Mar 24, 2009 at 8:11 AM, Opensource Obscure wrote: > On Tue, 24 Mar 2009 07:19:23 -0500, Soft wrote: >> On Mon, Mar 23, 2009 at 10:57 PM, Alissa Sabre >> wrote: > >>> BTW, I found some issues on trunk viewer. ?What is the expecte channel >>> to file a bug on svn trunk source? ?Should I submit the issue on >>> public JIRA as usual? >> >> Yup. For the version, you can specify "source code" - it wouldn't hurt >> to include 1.23 in addition. Until that's exported on its own, there's >> a fair chance that anything you see in trunk/ is destined for 1.23. > > Yesterday I filed two bugs against the render-pipeline branch: > http://jira.secondlife.com/browse/VWR-12555 > http://jira.secondlife.com/browse/VWR-12556 > > I just updated them so that they read now > > "render-pipeline branch" in the Title field, > "source code" in the Affects Version/s field and > "Second Life 1.23.0 (114978) Mar 21 2009 19:06:43 (Developer)" in the > Environment field. > > Is this ok? Great! > By the way, in which Office Hour are discussions about realtime > shadows most welcome? I made a couple of videos using a > render-pipeline viewer where some glitches can be seen and I'd like > to discuss about them. I didn't report these ones into PJIRA yet. > http://www.youtube.com/watch?v=c5VCcO7NFpo > http://www.youtube.com/watch?v=cps7xYyEF7U You could add questions to the open source meeting agenda and note that here. Then we can see if one of the devs thinks it would be productive to attend, or if they could answer some things in advance. From lenglish5 at cox.net Tue Mar 24 12:36:18 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 24 Mar 2009 12:36:18 -0700 Subject: [sldev] [Fwd: [AWG][mmox] BOF meeting today at 15:20 PDT; here's the remote access info] Message-ID: <49C93632.3090008@cox.net> ALSO note: Patnad is trying to set up everything: audio, slideshow, interworld chat bridge (jabber chatbridge if he can manage): you can attend the IETF MMOX BoF meeting in-world at: http://slurl.com/secondlife/RezzMe/56/219/1996 you need to register first: http://www.rezzme.com/mmoxregister.aspx This morning's groupies meeting also covered yesterday's IETF presentations on MMOX and rhttp by Zero Linden and Zha Ewry: https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2009-03-24 Forwarded From Latha Seva: I've collected all the info I know about how to remotely access the MMOX BOF meeting. Here it is. The BOF meeting happens today, Tuesday March 24 at 15:20 PDT (22:20 UTC), as part of IETF 74 in San Francisco. Here's the agenda. http://tools.ietf.org/agenda/74/mmox.html The IETF provides audio streaming and a Jabber chat room. I'm using http://videolab.uoregon.edu/events/ietf/ietf74.m3u as an index page (playlist) to access all of the IETF audio streams -- just choose the "Continental 1&2" sub-channel for our meeting. The direct link to our room's sub-channel, in case the above URL doesn't agree with your setup, is http://feed.verilan.com:8000/continental_1-2 and is an Icecast stream, 44100Hz, 2ch, 64kbps MP3. It has been known to die and be restarted, so if your audio dies, you may have to try to re-connect multiple times until you get it back. The text chat for our meeting will be happening on Jabber, mmox @ jabber.ietf.org . There will be someone to relay questions from Jabber to the room, but we don't know who's going to be drafted yet. Jabber client setup is beyond the scope of this note, but I had an easy time with the SamePlace plugin for Firefox and a Google Talk account. PDF slides for each of the talks on the MMOX agenda are in the MMOX section of https://datatracker.ietf.org/meeting/74/materials.html and may be updated throughout the day. The above audio, text chat, and slides, are the way I plan to attend the BOF. Also, if you're looking for a place to park your avatar during the meeting, meeting rooms are being set up in Second Life, OSGrid, and Reaction Grid, by the avatar I know in SL as Patnad Babii. His signup URL for those rooms is http://rezzme.com/mmoxregister.aspx , and he's trying to bring as much of all this in-world as he can manage. A bit of info I only learned today: David Levine / Zha Ewry gave an overview of MMOX and OGP at the "apparea" session yesterday, and his slides are at http://www.ietf.org/proceedings/09mar/slides/apparea-9.pdf . And finally, two links to the background info we probably all have already. The agenda at http://tools.ietf.org/agenda/74/mmox.html has a pointer to each of the drafts that we should have read, and Morgaine's unofficial link collection is at http://wiki.secondlife.com/wiki/MMOX . Jeez, I'd better go make sure I've read all those drafts and have decided what I think about them and what comments I'd like to make via Jabber. See you (virtually) at the meeting! Latha Serevi _______________________________________________ mmox mailing list mmox at ietf.org https://www.ietf.org/mailman/listinfo/mmox From open at autistici.org Tue Mar 24 15:38:29 2009 From: open at autistici.org (Opensource Obscure) Date: Tue, 24 Mar 2009 22:38:29 +0000 Subject: [sldev] =?utf-8?q?=5BVWR=2C_LINUX=5D_How_to_compile_=22Debug=22_a?= =?utf-8?q?nd_=22Release=22_viewers=3F?= Message-ID: <192c19083ba4a3712082e73e7d0fa649@localhost> I can consistently reproduce a 1.23-render-pipeline viewer crash, by zooming out fast while in a place with lots of textures that aren't fully loaded yet. I want to document and report this (see bottom of this email for more details), and I thought that a "Debug" build would have produced better information, so I tried to compile one. The Linux viewers I usually make by using ./develop.py configure ./develop.py build are of the "RelWithDebInfo" build type - correct? Surely I'm doing it wrong, because both the "Debug" and the "Release" binaries I made have nearly the same size, and they provide similar logs. What is the correct way to compile a "Debug" and a "Release" viewer? Here's what I did for the "Debug" one: ./develop.py clean ./develop.py configure -DCMAKE_BUILD_TYPE:STRING=Debug ./develop.py build (previously I had already built a viewer from the same sources - that's why I didn't have to copy FMOD here) ciao, Opensource Obscure error message when crashing: 2009-03-24T22:06:43Z llrender/llvertexbuffer.cpp(1199) : error 2009-03-24T22:06:43Z ERROR: setupVertexBuffer: LLVertexBuffer::setupVertexBuffer missing required components for supplied data mask. stack_trace.log: 0: ELF(do_elfio_glibc_backtrace()+0x424) [0x9995fa8] 1: ELF(LLAppViewerLinux::handleSyncCrashTrace()+0xb) [0x99968c7] 2: ELF(LLAppViewer::handleSyncViewerCrash()+0x20) [0x84d311e] 3: ELF(LLApp::runSyncErrorHandler()+0x16) [0x9ed80ec] 4: ELF(LLApp::setError()+0x17) [0x9ed8175] 5: ELF(default_unix_signal_handler(int, siginfo*, void*)+0xd22) [0x9eda07e] 6: [0xb7ffa410] 7: ELF(LLError::crashAndLoop(std::string const&)+0x10) [0x9ee7f26] 8: ELF(errorCallback(std::string const&)+0x9f) [0x84e2dd8] 9: ELF(LLError::Log::flush(std::basic_ostringstream, std::allocator >*, LLError::CallSite const&)+0x9e1) [0x9eeb5c7] 10: ELF(LLVertexBuffer::setupVertexBuffer(unsigned int) const+0x17c) [0x9b98374] 11: ELF(LLVertexBuffer::setBuffer(unsigned int)+0xbd5) [0x9b9bebb] 12: ELF(LLRenderPass::pushBatch(LLDrawInfo&, unsigned int, int)+0x13c) [0x86408c6] 13: ELF(LLRenderPass::pushBatches(unsigned int, unsigned int, int)+0x62) [0x86409f2] 14: ELF(LLRenderPass::renderTexture(unsigned int, unsigned int)+0x2e) [0x863c6ce] 15: ELF(LLDrawPoolSimple::render(int)+0x81) [0x864cf0d] 16: ELF(LLPipeline::renderGeom(LLCamera&, int)+0xd45) [0x99686cd] 17: ELF(display(int, float, int, int)+0x4050) [0x94bb04a] 18: ELF(LLAppViewer::mainLoop()+0xd25) [0x84f5ccf] 19: ELF(main+0x213) [0x999769c] 20: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb6756685] 21: bin/do-not-directly-run-secondlife-bin [0x847c8e1] From soft at lindenlab.com Tue Mar 24 15:45:28 2009 From: soft at lindenlab.com (Soft) Date: Tue, 24 Mar 2009 17:45:28 -0500 Subject: [sldev] [VWR, LINUX] How to compile "Debug" and "Release" viewers? In-Reply-To: <192c19083ba4a3712082e73e7d0fa649@localhost> References: <192c19083ba4a3712082e73e7d0fa649@localhost> Message-ID: On Tue, Mar 24, 2009 at 5:38 PM, Opensource Obscure wrote: > > I thought that a "Debug" build would have > produced better information, so I tried to compile one. > > The Linux viewers I usually make by using > ./develop.py configure > ./develop.py build > are of the "RelWithDebInfo" build type - correct? > > Surely I'm doing it wrong, because both the "Debug" and the > "Release" binaries I made have nearly the same size, > and they provide similar logs. > > What is the correct way to compile a "Debug" and a "Release" viewer? Check the --type option in ./develop.py --help From khyota at redhyena.net Tue Mar 24 16:08:00 2009 From: khyota at redhyena.net (Khyota) Date: Tue, 24 Mar 2009 19:08:00 -0400 Subject: [sldev] [VWR, LINUX] How to compile "Debug" and "Release" viewers? In-Reply-To: <192c19083ba4a3712082e73e7d0fa649@localhost> References: <192c19083ba4a3712082e73e7d0fa649@localhost> Message-ID: <200903241908.01261.khyota@redhyena.net> On Tuesday 24 March 2009 6:38:29 Opensource Obscure wrote: > I can consistently reproduce a 1.23-render-pipeline viewer crash, > by zooming out fast while in a place with lots of textures that > aren't fully loaded yet. > I want to document and report this (see bottom of this email > for more details), and I thought that a "Debug" build would have > produced better information, so I tried to compile one. > > The Linux viewers I usually make by using > ./develop.py configure > ./develop.py build > are of the "RelWithDebInfo" build type - correct? > > Surely I'm doing it wrong, because both the "Debug" and the > "Release" binaries I made have nearly the same size, > and they provide similar logs. > > What is the correct way to compile a "Debug" and a "Release" viewer? > > Here's what I did for the "Debug" one: > ./develop.py clean > ./develop.py configure -DCMAKE_BUILD_TYPE:STRING=Debug > ./develop.py build > > (previously I had already built a viewer from the same > sources - that's why I didn't have to copy FMOD here) > > ciao, > Opensource Obscure > RelWithDebInfo is default For debug i use ./develop.py -t Debug configure && ./develop.py -t Debug build For Release ./develop.py -t Release configure && ./develop.py -t Release build you need to specify it for both the configure and the build line, for some reason i couldnt get DCMAKE_BUILD_TYPE:STRING to work directly last time i tried you should have a sepreate directory for each build like viewer-linux-x86_64-release and viewer-linux-x86_64-debug Khyota :) From seg at haxxed.com Tue Mar 24 12:53:26 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 24 Mar 2009 14:53:26 -0500 Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder In-Reply-To: References: <1237072563.19095.98.camel@localhost.localdomain> Message-ID: <1237924406.24750.2.camel@localhost.localdomain> On Mon, 2009-03-16 at 12:20 -0700, Bryan O'Sullivan wrote: > Yes, it is. It's a one-off experiment we've been running within Linden Lab to see how Topcoder's services work out. OpenJPEG decoding performance seemed like a good target to aim at because its success is easy to measure. -------------- 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/20090324/3840709c/attachment.pgp From seg at haxxed.com Tue Mar 24 17:45:16 2009 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 24 Mar 2009 19:45:16 -0500 Subject: [sldev] Linden Lab OpenJPEG contest on TopCoder In-Reply-To: References: <1237072563.19095.98.camel@localhost.localdomain> Message-ID: <1237941916.24750.293.camel@localhost.localdomain> On Mon, 2009-03-16 at 12:20 -0700, Bryan O'Sullivan wrote: > Yes, it is. It's a one-off experiment we've been running within Linden > Lab to see how Topcoder's services work out. OpenJPEG decoding > performance seemed like a good target to aim at because its success is > easy to measure. I don't find it so easy to write off $5000 as an "experiment". Oh well I've entered. If I get screwed it won't be the first time. -------------- 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/20090324/14e13014/attachment.pgp From gigstaggart at gmail.com Tue Mar 24 18:05:34 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue, 24 Mar 2009 21:05:34 -0400 Subject: [sldev] [VWR, LINUX] How to compile "Debug" and "Release" viewers? In-Reply-To: <192c19083ba4a3712082e73e7d0fa649@localhost> References: <192c19083ba4a3712082e73e7d0fa649@localhost> Message-ID: <49C9835E.6000209@gmail.com> Opensource Obscure wrote: > Surely I'm doing it wrong, because both the "Debug" and the > "Release" binaries I made have nearly the same size, > and they provide similar logs. I never compile debug. It turns on asserts and other nastiness that just gets in the way of actual debugging. What I do is edit the makefile and change the strip command to cp. Crude, I know, but it works and is easy to change back. The unstripped "release" binary has all the debug info you need. -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/20090324/f224e0b4/attachment.bin From alissa_sabre at yahoo.co.jp Wed Mar 25 06:33:42 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed, 25 Mar 2009 22:33:42 +0900 Subject: [sldev] Filing a bug of svn trunk version? In-Reply-To: References: <49C62B58.5030604@boroon.dasgupta.ch> <200903220046.33366.johnniecarling@gmail.com> <74ds4e44e6xkzzeL76owwnQd.alissa_sabre@yahoo.co.jp> Message-ID: <1G4wds4ds7dsdm686owwrJ6G.alissa_sabre@yahoo.co.jp> Thanks, Soft. > > What is the expected channel > > to file a bug on svn trunk source? Should I submit the issue on > > public JIRA as usual? > > Yup. For the version, you can specify "source code" - it wouldn't hurt > to include 1.23 in addition. Until that's exported on its own, there's > a fair chance that anything you see in trunk/ is destined for 1.23. I filed one of the bugs as VWR-12569. If you have any comment on the issue filing format, please let me know. (Also, this issue is a _fun_ thing, and it may attract wider audiences... :-) Alissa Sabre # No, I don't speak Spanish. -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From jpirkola at gmail.com Wed Mar 25 09:02:07 2009 From: jpirkola at gmail.com (Jani Pirkola) Date: Wed, 25 Mar 2009 18:02:07 +0200 Subject: [sldev] [META] Article: IT giants back up open source 3D Web Message-ID: <6c9557390903250902s27795136j82ad1c7622b5904b@mail.gmail.com> http://www.cybertechnews.org/?p=1303 hope to see your comments on the post! Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090325/d23bed56/attachment.htm From carlo at alinoe.com Wed Mar 25 20:48:11 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 26 Mar 2009 04:48:11 +0100 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? Message-ID: <20090326034811.GA25411@alinoe.com> I'm trying to understand the texture pipeline by reading the code (unfortunately there is no documentation). Doing so, I ran into the following that appears to be a bug. The class LLTextureCacheRemoteWorker has an element called mOffset. Because of code like this: mState = mOffset < TEXTURE_CACHE_ENTRY_SIZE ? HEADER : BODY; it seems that mOffset is the data that was read so far. Note that there are two sizes: data size (the whole image) and file size. Those two differ because the first TEXTURE_CACHE_ENTRY_SIZE bytes (600) are written to the texture.cache file and the remaining bytes are written to the cache/textures/?/* files. So again, I think that mOffset is the *data* that was read previously. A bit further in LLTextureCacheRemoteWorker::doRead in we see the following code however: if (mState == BODY) { std::string filename = mCache->getTextureFileName(mID); S32 filesize = ll_apr_file_size(filename, mCache->getFileAPRPool()); S32 bytes_read = 0; if (filesize > mOffset) { S32 datasize = TEXTURE_CACHE_ENTRY_SIZE + filesize; mDataSize = llmin(datasize, mDataSize); S32 data_offset = TEXTURE_CACHE_ENTRY_SIZE - mOffset; data_offset = llmax(data_offset, 0); S32 file_size = mDataSize - data_offset; S32 file_offset = mOffset - TEXTURE_CACHE_ENTRY_SIZE; file_offset = llmax(file_offset, 0); ... Clearly, 'filesize' is the size of the "cache/textures/?/*" file (the BODY), and thus 'datasize' is TEXTURE_CACHE_ENTRY_SIZE + filesize. data_offset has mOffset subtracted, again indicating that mOffset is a DATA offset, not a file offset. The (remaining) file_size is then indeed mDataSize - data_offset, and 'file_offset' is set to 'mOffset - TEXTURE_CACHE_ENTRY_SIZE', again very clearly indicating that mOffset is the total (data) offset. Therefore... the ' if (filesize > mOffset) ' must be a bug! You can't compare the filesize (the size of the "cache/textures/?/*" file with a data offset! For example, at this point we could have read 900 bytes already before so that mOffset == 900. The total data size then can be anything >= 900, and thus filesize can be anything >= 300. The result of that condition seems therefore rather arbitrary. If the condition fails, mDataSize is set to 600 bytes and that's it... So, an image of 900 bytes would get cut off at 600 bytes if mOffset is > 300 at that point... That can't be right, right? Anyone? -- Carlo Wood From merov at lindenlab.com Wed Mar 25 22:31:37 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 25 Mar 2009 22:31:37 -0700 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: <20090326034811.GA25411@alinoe.com> References: <20090326034811.GA25411@alinoe.com> Message-ID: <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> Hi Carlo, How uncanny, it just happens that I'm starting to work on documenting that piece of code. I'm still trying to get my bearing through the various threads and mutex involved so I might be missing something but I'll be giving my best shot at an explanation. On Mar 25, 2009, at 8:48 PM, Carlo Wood wrote: > I'm trying to understand the texture pipeline by > reading the code (unfortunately there is no documentation). Yup, this is coming (see above). > Doing so, I ran into the following that appears to > be a bug. > > The class LLTextureCacheRemoteWorker has an > element called mOffset. > > Because of code like this: > > mState = mOffset < TEXTURE_CACHE_ENTRY_SIZE ? HEADER : BODY; > > it seems that mOffset is the data that was read so far. mOffset is actually the data that's reserved for the header in the formatted image buffer at creation *before* the readFromCache() is invoked (see LLTextureFetchWorker::doWork() in lltexturefetch.cpp). This quantity is fixed and never changed. What we've read so far is *at most* TEXTURE_CACHE_ENTRY_SIZE from the header cache. The cache system writes all the cached files "headers" in a special file so to access the basic image info rapidly. Each entry to that file is *fixed* and stores TEXTURE_CACHE_ENTRY_SIZE of data, header *and all*. So, sometimes that entry actually stores real data (pixels so to speak...) that needs to be read before we read the body. This is what the mState == HEADER section will actually do. Sometimes, the header is actually bigger than TEXTURE_CACHE_ENTRY_SIZE and part of the header of the file will leak into the body section and will have to be accounted for there. This is the reason of the mind boggling code you encountered... So, the idea in the line of code you mentioned here above is that, if the header (mOffset) is smaller than TEXTURE_CACHE_ENTRY_SIZE, then there is some data we'll have to get from here and that'll be done in the mState == HEADER section of the doWork(). Otherwise, we go to the BODY section directly. Note that, in truth, the (mState == HEADER) section actually doesn't read the header (this is done in getHeaderCacheEntry()) but rather deals with the left over of body data in that buffer... > Note that there are two sizes: data size (the whole image) > and file size. Those two differ because the first > TEXTURE_CACHE_ENTRY_SIZE bytes (600) are written to the > texture.cache file and the remaining bytes are written > to the cache/textures/?/* files. > > So again, I think that mOffset is the *data* that was read > previously. getHeaderCacheEntry() read TEXTURE_CACHE_ENTRY_SIZE bytes *at most* that do truly belonged to the original file (and are not duplicated in the other part of the cache) so it reads min(mOffset, TEXTURE_CACHE_ENTRY_SIZE). When you realize that, the algorithm here under makes sense (though it's really acrobatic I agree...) > A bit further in LLTextureCacheRemoteWorker::doRead in > we see the following code however: > > if (mState == BODY) > { > std::string filename = mCache->getTextureFileName(mID); > S32 filesize = ll_apr_file_size(filename, mCache- > >getFileAPRPool()); > S32 bytes_read = 0; > if (filesize > mOffset) > { > S32 datasize = TEXTURE_CACHE_ENTRY_SIZE + > filesize; > mDataSize = llmin(datasize, mDataSize); > S32 data_offset = TEXTURE_CACHE_ENTRY_SIZE - > mOffset; > data_offset = llmax(data_offset, 0); > S32 file_size = mDataSize - data_offset; > S32 file_offset = mOffset - > TEXTURE_CACHE_ENTRY_SIZE; > file_offset = llmax(file_offset, 0); > ... > > Clearly, 'filesize' is the size of the "cache/textures/?/*" file > (the BODY), and thus 'datasize' is TEXTURE_CACHE_ENTRY_SIZE + > filesize. > > data_offset has mOffset subtracted, again indicating that mOffset is > a DATA offset, not a file offset. > > The (remaining) file_size is then indeed mDataSize - data_offset, > and 'file_offset' is set to 'mOffset - TEXTURE_CACHE_ENTRY_SIZE', > again very clearly indicating that mOffset is the total (data) offset. > > Therefore... the ' if (filesize > mOffset) ' must be a bug! Well, if (filesize <= mOffset), the file was all contained in the header cache to start with and there's nothing else left to read. It was all read in the getHeaderCacheEntry() call and transfered in the relevant buffer in the (mState == HEADER) section. If you execute the computation here above for the 2 cases (mOffset <= TEXTURE_CACHE_ENTRY_SIZE) and (mOffset > TEXTURE_CACHE_ENTRY_SIZE) you get: if (mOffset <= TEXTURE_CACHE_ENTRY_SIZE) file_size = filesize + mOffset file_offset = 0 That's the "normal" case, the one where the header is small. We'll read the whole body (we'll add the extra bytes coming from the header cache in a memcpy() later), there's no offset to worry about and the whole file is the addition of both header and data. if (mOffset > TEXTURE_CACHE_ENTRY_SIZE) file_size = filesize + TEXTURE_CACHE_ENTRY_SIZE file_offset = mOffset - TEXTURE_CACHE_ENTRY_SIZE // a negative value, allowing the reading of the remainder of the header In that case, the header overflown the header cache so, in reality, the file size is one max buffer (TEXTURE_CACHE_ENTRY_SIZE) plus the body but the data is really starting at (header size - TEXTURE_CACHE_ENTRY_SIZE). If you ask me, that piece of code could be rewritten without loss of performance or generality by simply spelling out the 2 cases as I just did. At least, it's intent would be made plain and it'd be easier to read... It might even make the absence of documentation less painful. That being said, I might have missed something in my interpretation of that code so may be someone else could jump in and show us what to think of all this. Cheers, - Merov From carlo at alinoe.com Thu Mar 26 08:58:28 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 26 Mar 2009 16:58:28 +0100 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> References: <20090326034811.GA25411@alinoe.com> <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> Message-ID: <20090326155828.GA24487@alinoe.com> On Wed, Mar 25, 2009 at 10:31:37PM -0700, Philippe Bossut (Merov Linden) wrote: > mOffset is actually the data that's reserved for the header in the > formatted image buffer at creation *before* the readFromCache() is > invoked (see LLTextureFetchWorker::doWork() in lltexturefetch.cpp). This > quantity is fixed and never changed. What we've read so far is *at most* > TEXTURE_CACHE_ENTRY_SIZE from the header cache. Before I react to the rest of you mail (thanks!), I really need to understand this mOffet better. When you say 'header', you seem to refer to something else than the header of the image, right? Also jpeg2000 files (and tga files) start with a header before the actual pixel data starts. So, what is this "header in the formatted image buffer"? How is the size of it determined? Aren't all files in the cache jpeg 2000 files? Because in that case I can't think of a reason for a need of extra data before the image(-header). Right now my picture is this (assuming mOffset < 600): TEXTURE_CACHE_ENTRY_SIZE <---------------------------><-------------cache file------------> <----mOffset----><----JPEG2000 header----><-----pixel data-------> And I have no idea what kind of data goes in the mOffset part or how large it is. -- Carlo Wood From merov at lindenlab.com Thu Mar 26 09:46:36 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 26 Mar 2009 09:46:36 -0700 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: <20090326155828.GA24487@alinoe.com> References: <20090326034811.GA25411@alinoe.com> <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> <20090326155828.GA24487@alinoe.com> Message-ID: Hi Carlo, On Mar 26, 2009, at 8:58 AM, Carlo Wood wrote: > On Wed, Mar 25, 2009 at 10:31:37PM -0700, Philippe Bossut (Merov > Linden) wrote: >> mOffset is actually the data that's reserved for the header in the >> formatted image buffer at creation *before* the readFromCache() is >> invoked (see LLTextureFetchWorker::doWork() in lltexturefetch.cpp). >> This >> quantity is fixed and never changed. What we've read so far is *at >> most* >> TEXTURE_CACHE_ENTRY_SIZE from the header cache. > > Before I react to the rest of you mail (thanks!), I really need to > understand this mOffet better. Actually, I had a classic "late night email morning after remorse" when waking up, thinking that part of my talk had to be wrong or, at least, not telling the whole story. Not that I hid anything but rather that I don't know the full answer yet and need more time tinkering and reading the code. Clearly, this "mOffset" name is a misnomer and equating it with the size of the header (metadata and all I suppose) is not telling the whole story... I'll be trying to decipher that today. > When you say 'header', you seem to refer to something else than > the header of the image, right? Also jpeg2000 files (and tga files) > start with a header before the actual pixel data starts. My understanding is that this "header" contains general image info (size, compression scheme, dimension, color model, etc..) and that it's valuable to access them fast without opening and decoding the whole file. That's the reasoning behind storing this first kilo byte of file info into a specific header cache file containing all those chunks in one seamless stream. > So, what is this "header in the formatted image buffer"? > How is the size of it determined? > Aren't all files in the cache jpeg 2000 files? Because in that > case I can't think of a reason for a need of extra data before > the image(-header). It seems this header is simply the first kilo byte chunk of data from the file and mOffset is the size of the whole metadata chunk in the file (could be less or more than 1 kbyte). That's about clear. Also the cache does store j2c and tga files but, as far as I can tell, all tga files are local files and are loaded by the LLTextureCacheLocalFileWorker, not the LLTextureCacheRemoteWorker. The code however is written in a general way without making any assumption on the file type. It's then possible that the "non-j2c" code path is never exercised and could very well be buggy. I'm guessing that our investigation might make that clear. (BTW, this is a good reason why we should add unit tests to this code, another thing I'm working on right now... but that's another story...) > Right now my picture is this (assuming mOffset < 600): > > TEXTURE_CACHE_ENTRY_SIZE > <---------------------------><-------------cache file------------> > <----mOffset----><----JPEG2000 header----><-----pixel data-------> > > And I have no idea what kind of data goes in the mOffset part > or how large it is. Hmmm... You might well be right with that though that would mean that LL is adding a different header to j2c files... I'll be investigating more this morning and report my findings here. Cheers, - Merov From dale at daleglass.net Thu Mar 26 10:20:59 2009 From: dale at daleglass.net (Dale Glass) Date: Thu, 26 Mar 2009 18:20:59 +0100 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed Message-ID: <200903261821.16410.dale@daleglass.net> Hi! I made a small patch to display the title of the currently playing song in the chat log. I only use SL on Linux, so only a gstreamer implementation is included so far. Pretty much all that's needed is to add the required code to llmediaimplquicktime.cpp, and then call: LLMediaEvent event(self, song_title); self->getEventEmitter().update( &LLMediaObserver::onMediaTitleChange, event); Criticism of the idea and the implementation would be appreciated. Currently I stuck the title announcing code into lloverlaybar.cpp, but that's probably not the best place for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: streaming_info.patch Type: text/x-patch Size: 5161 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090326/a3566a2d/attachment.bin -------------- 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/20090326/a3566a2d/attachment.pgp From soft at lindenlab.com Thu Mar 26 10:29:16 2009 From: soft at lindenlab.com (Soft) Date: Thu, 26 Mar 2009 12:29:16 -0500 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <200903261821.16410.dale@daleglass.net> References: <200903261821.16410.dale@daleglass.net> Message-ID: On Thu, Mar 26, 2009 at 12:20 PM, Dale Glass wrote: > Hi! > > I made a small patch to display the title of the currently playing song in > the chat log. I only use SL on Linux, so only a gstreamer implementation is > included so far. > > Pretty much all that's needed is to add the required code to > llmediaimplquicktime.cpp, and then call: > > LLMediaEvent event(self, song_title); > self->getEventEmitter().update( &LLMediaObserver::onMediaTitleChange, > event); > > Criticism of the idea and the implementation would be appreciated. > Currently I stuck the title announcing code into lloverlaybar.cpp, but > that's probably not the best place for it. This is an *awesome* idea - would be great to have this for all platforms! From dale at daleglass.net Thu Mar 26 11:47:29 2009 From: dale at daleglass.net (Dale Glass) Date: Thu, 26 Mar 2009 19:47:29 +0100 Subject: [sldev] Is VWR-8773 (Closing parenthesis ")" breaks urls) being worked on? Message-ID: <200903261947.36803.dale@daleglass.net> Link: https://jira.secondlife.com/browse/VWR-8773 The last comment by Quarl is on 08/Jan/09 about rescinding his objection to getting this issue fixed. There's also a comment from McCabe Maxsted who tried something that works great, but I don't know what it is. The bug is still present in the latest version. I looked at the code and think I figured out the way to fix it, so if nobody is working on it, I'll go and do that. -------------- 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/20090326/c2fd83c8/attachment.pgp From sldev at free.fr Thu Mar 26 11:53:58 2009 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 26 Mar 2009 19:53:58 +0100 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: References: <200903261821.16410.dale@daleglass.net> Message-ID: <20090326195358.155e3c3a.sldev@free.fr> On Thu, 26 Mar 2009 12:29:16 -0500, Soft wrote: > On Thu, Mar 26, 2009 at 12:20 PM, Dale Glass wrote: > > Hi! > > > > I made a small patch to display the title of the currently playing song in > > the chat log. I only use SL on Linux, so only a gstreamer implementation is > > included so far. > > > > Pretty much all that's needed is to add the required code to > > llmediaimplquicktime.cpp, and then call: > > > > LLMediaEvent event(self, song_title); > > self->getEventEmitter().update( &LLMediaObserver::onMediaTitleChange, > > event); > > > > Criticism of the idea and the implementation would be appreciated. > > Currently I stuck the title announcing code into lloverlaybar.cpp, but > > that's probably not the best place for it. > > This is an *awesome* idea - would be great to have this for all platforms! Awesome ?... Hmmm... Yes, *as long as* it can be easily *disabled* via a setting in the preferences floater, because, as a role-player, I *hate* having "spam" polluting the chat log (and there is enough such spam already with all the notices that go there: I hope that sometime in the future, the viewer will gain its own notices log floater and that the chat log will only hold actual chat lines). Henri. From danteferret at gmail.com Thu Mar 26 12:15:04 2009 From: danteferret at gmail.com (Dante Tucker) Date: Thu, 26 Mar 2009 15:15:04 -0400 Subject: [sldev] Is VWR-8773 (Closing parenthesis ")" breaks urls) being worked on? In-Reply-To: <200903261947.36803.dale@daleglass.net> References: <200903261947.36803.dale@daleglass.net> Message-ID: <4d211a610903261215s5397a116wb0de6537a99a95bf@mail.gmail.com> It's fixed in an internal branch, coming soon to a viewer near you.... At least thats what the jira says. On Thu, Mar 26, 2009 at 2:47 PM, Dale Glass wrote: > Link: https://jira.secondlife.com/browse/VWR-8773 > > The last comment by Quarl is on 08/Jan/09 about rescinding his objection to > getting this issue fixed. > > There's also a comment from McCabe Maxsted who tried something that works > great, but I don't know what it is. The bug is still present in the latest > version. > > I looked at the code and think I figured out the way to fix it, so if > nobody > is working on it, I'll go and do that. > > > _______________________________________________ > 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/20090326/d92d1479/attachment.htm From hakushakukun at gmail.com Thu Mar 26 12:35:30 2009 From: hakushakukun at gmail.com (Adric R) Date: Thu, 26 Mar 2009 12:35:30 -0700 Subject: [sldev] SLDev Digest, Vol 27, Issue 40 In-Reply-To: References: Message-ID: <781e4b420903261235k35a19dcchba757919a191d360@mail.gmail.com> VWR-8773 has already been implemented by Qarl. You can find the code here: http://svn.secondlife.com/trac/linden/changeset/1705 We've been using it in Imprudence for months now. A note: it may or may not cause a crash when "show end of last IM conversation" is enabled. It did for us, but it's been ages since I last compiled the SL viewer so I don't know if that applies or has been fixed on their end or what. -- McCabe 2009/3/26 > Send SLDev mailing list submissions to > sldev at 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 at lists.secondlife.com > > You can reach the person managing the list at > sldev-owner at 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. Is VWR-8773 (Closing parenthesis ")" breaks urls) being > worked on? (Dale Glass) > 2. Re: Added streaming info for Linux, Windows/Mac version > needed (Henri Beauchamp) > > > ---------- Forwarded message ---------- > From: Dale Glass > To: Second Life Developer Mailing List > Date: Thu, 26 Mar 2009 19:47:29 +0100 > Subject: [sldev] Is VWR-8773 (Closing parenthesis ")" breaks urls) being > worked on? > Link: https://jira.secondlife.com/browse/VWR-8773 > > The last comment by Quarl is on 08/Jan/09 about rescinding his objection to > getting this issue fixed. > > There's also a comment from McCabe Maxsted who tried something that works > great, but I don't know what it is. The bug is still present in the latest > version. > > I looked at the code and think I figured out the way to fix it, so if > nobody > is working on it, I'll go and do that. > > > > ---------- Forwarded message ---------- > From: Henri Beauchamp > To: sldev at lists.secondlife.com > Date: Thu, 26 Mar 2009 19:53:58 +0100 > Subject: Re: [sldev] Added streaming info for Linux, Windows/Mac version > needed > On Thu, 26 Mar 2009 12:29:16 -0500, Soft wrote: > > > On Thu, Mar 26, 2009 at 12:20 PM, Dale Glass wrote: > > > Hi! > > > > > > I made a small patch to display the title of the currently playing song > in > > > the chat log. I only use SL on Linux, so only a gstreamer > implementation is > > > included so far. > > > > > > Pretty much all that's needed is to add the required code to > > > llmediaimplquicktime.cpp, and then call: > > > > > > LLMediaEvent event(self, song_title); > > > self->getEventEmitter().update( &LLMediaObserver::onMediaTitleChange, > > > event); > > > > > > Criticism of the idea and the implementation would be appreciated. > > > Currently I stuck the title announcing code into lloverlaybar.cpp, but > > > that's probably not the best place for it. > > > > This is an *awesome* idea - would be great to have this for all > platforms! > > Awesome ?... Hmmm... Yes, *as long as* it can be easily *disabled* via a > setting in the preferences floater, because, as a role-player, I *hate* > having "spam" polluting the chat log (and there is enough such spam already > with all the notices that go there: I hope that sometime in the future, the > viewer will gain its own notices log floater and that the chat log will > only hold actual chat lines). > > Henri. > > > _______________________________________________ > SLDev mailing list > SLDev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- "Work is love made visible." ? Kahlil Gibran "We will not walk in fear, one of another. We will not be driven by fear into an age of unreason if we dig deep in our history and doctrine and remember that we are not descended from fearful men, not from men who feared to write, to speak, to associate and to defend causes which were for the moment unpopular. We can deny our heritage and our history, but we cannot escape responsibility for the result. There is no way for a citizen of the Republic to abdicate his responsibility." -- Edward R. Murrow, March 9, 1954 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090326/b9d94da8/attachment.htm From armin.weatherwax at googlemail.com Thu Mar 26 13:05:01 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Thu, 26 Mar 2009 21:05:01 +0100 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <200903261821.16410.dale@daleglass.net> References: <200903261821.16410.dale@daleglass.net> Message-ID: <200903262105.01626.Armin.Weatherwax@gmail.com> > Criticism of the idea and the implementation would be appreciated. Love the idea very much:) What you think about showing it as a notifybox (like http://github.com/ArminW/imprudence/commit/e8688b47ef921aa9e1e4cba69ef49473f11e6d50#diff-7 does) ? The title poping up gives me always kind of an amarok-feeling ... :) Armin From colin.kern at gmail.com Thu Mar 26 13:08:34 2009 From: colin.kern at gmail.com (Colin Kern) Date: Thu, 26 Mar 2009 16:08:34 -0400 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <200903261821.16410.dale@daleglass.net> References: <200903261821.16410.dale@daleglass.net> Message-ID: <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> On Thu, Mar 26, 2009 at 1:20 PM, Dale Glass wrote: > Hi! > > I made a small patch to display the title of the currently playing song in > the chat log. I only use SL on Linux, so only a gstreamer implementation is > included so far. > I think this a great idea too! The next step is to have support for last.fm scrobbling :D Colin From dale at daleglass.net Thu Mar 26 13:19:57 2009 From: dale at daleglass.net (Dale Glass) Date: Thu, 26 Mar 2009 21:19:57 +0100 Subject: [sldev] SLDev Digest, Vol 27, Issue 40 In-Reply-To: <781e4b420903261235k35a19dcchba757919a191d360@mail.gmail.com> References: <781e4b420903261235k35a19dcchba757919a191d360@mail.gmail.com> Message-ID: <200903262120.01945.dale@daleglass.net> On ??????? 26 ????? 2009 20:35:30 Adric R wrote: > VWR-8773 has already been implemented by Qarl. You can find the code > here: > > http://svn.secondlife.com/trac/linden/changeset/1705 > > We've been using it in Imprudence for months now. A note: it may or may > not cause a crash when "show end of last IM conversation" is enabled. It > did for us, but it's been ages since I last compiled the SL viewer so I > don't know if that applies or has been fixed on their end or what. >Ahh, I see. I had something more complicated in mind. Maybe this is contrived, but: http://www.google.com/search?hl=ru&q=[](){}<>><&btnG=?????+?+Google&lr= It'll still choke on that one, the URL is as it appears in Konqueror. My idea was to keep a stack, and deal with every possible delimiter. But guess I'll wait to see if this works good enough before doing the above. -------------- 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/20090326/bf7572ad/attachment.pgp From dale at daleglass.net Thu Mar 26 13:25:24 2009 From: dale at daleglass.net (Dale Glass) Date: Thu, 26 Mar 2009 21:25:24 +0100 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <20090326195358.155e3c3a.sldev@free.fr> References: <200903261821.16410.dale@daleglass.net> <20090326195358.155e3c3a.sldev@free.fr> Message-ID: <200903262125.25198.dale@daleglass.net> On ??????? 26 ????? 2009 19:53:58 Henri Beauchamp wrote: > Awesome ?... Hmmm... Yes, *as long as* it can be easily *disabled* via > a setting in the preferences floater, because, as a role-player, I > *hate* having "spam" polluting the chat log (and there is enough such Sure, I'll add an option to the Audio & Video page. This is a proof of concept, the presentation is open to change. I was thinking that maybe there could be an optional title scroller, or something of that sort, that'd be shown with a ^ button (like the volume settings) > spam already with all the notices that go there: I hope that sometime in > the future, the viewer will gain its own notices log floater and that > the chat log will only hold actual chat lines). Why hope when you could get it done? It should be doable in a day or two. -------------- 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/20090326/185b9608/attachment.pgp From sheet.spotter at gmail.com Thu Mar 26 18:57:13 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Thu, 26 Mar 2009 20:57:13 -0500 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: References: <20090326034811.GA25411@alinoe.com><57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com><20090326155828.GA24487@alinoe.com> Message-ID: <52138949D50741469B62E7E4BE7882B7@kenb> > On Wed, Mar 26, 2009 at 11:47 AM -0700, Philippe Bossut (Merov > Linden) wrote: > It seems this header is simply the first kilo byte chunk of data from > the file and mOffset is the size of the whole metadata chunk in the > file (could be less or more than 1 kbyte). I had a simpler understanding for the first 600 bytes being stored in a special file where every record is a fixed size... Every texture download starts with a packet of 600 bytes of data (or less?). It's this first packet that is stored in a special file. Any additional packets that are required to describe the rest of the texture are stored in a separate external file. The external file continues from where the first 600 byte packet ended. The wiki entry that describes the texture cache describes the 600 byte entries as "first 600 bytes of .j2c file". http://wiki.secondlife.com/wiki/Texture_cache Sheet Spotter From vector at leafpile.com Thu Mar 26 19:37:12 2009 From: vector at leafpile.com (Vector Hastings) Date: Thu, 26 Mar 2009 19:37:12 -0700 Subject: [sldev] Looking for source for KirstenLee's SD5 In-Reply-To: <3b410a290903261759p1c966bb3i8bd39c876150ada9@mail.gmail.com> Message-ID: He won't. Says he's moved onto other interests. Hopefully someday the trunk/1.23 will catch up. -----Original Message----- From: Fatbear Flamand [mailto:fatbearflamand at gmail.com] Sent: Thursday, March 26, 2009 6:00 PM To: Vector Hastings Subject: Re: [sldev] Looking for source for KirstenLee's SD5 Damn!!! Thats sad... and he surely won?t want to try to find again the solutions! {}Overtake On Tue, Mar 24, 2009 at 6:12 AM, Vector Hastings wrote: lol! I completely empathize with the lack of time. It's killing me, almost literally. Trying to keep cheerful, Vector. PS: I just got done chatting again with KirstenLee, who says SD5 source was never shared and lost in a harddrive crash. Sigh. -----Original Message----- From: Sylvio Deutsch [mailto:fatbearflamand at gmail.com] Sent: Monday, March 23, 2009 12:43 PM To: Vector Hastings Subject: Re: [sldev] Looking for source for KirstenLee's SD5 Hi Vector Amazing, that's great to know! When are you starting to sell your viewer? (((: Here I barely got all the programs to start trying, have no time, and the little free time I?m using to fight cable company that is using something to detect our router and turn the speed way down when the second computer gets online... Of course they swear they?re not doing that... {}Overtake (Changed my account, for some reason the messages I send to any SL list from my old account aren?t delivered, nor returned. Another mystery.) On Fri, Mar 13, 2009 at 8:57 PM, Vector Hastings wrote: There's a .rar archive out there for his S16 viewer, but alas, no SD5. On a happy note, I finally managed to whack changeset 870 into his SD2_R7, which has enough fixes in it to be quite useable. (for example, no more missing shadows as reported in https://jira.secondlife.com/browse/VWR-12314 , but I have no idea what part of his changes fix it) -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Glen Canaday Sent: Friday, March 13, 2009 4:45 PM To: sldev at lists.secondlife.com Subject: Re: [sldev] Looking for source for KirstenLee's SD5 Sounds like the fixes will have to be reproduced :( sux0rz. didn't someone say that they're available as a .rar archive? --GC On Friday 13 March 2009 7:38:39 pm Thomas Shikami wrote: > Tigro Spottystripes wrote: > > I thought the issue was only about the source code for older versions.... > > The issue is about KirstenLee distributing binaries of OpenLife without > providing sources for it. KirstenLee took the binaries down, but still > does not comply with releasing sources. > _______________________________________________ > 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/20090326/9b9740ea/attachment.htm From secret.argent at gmail.com Fri Mar 27 04:49:06 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 27 Mar 2009 06:49:06 -0500 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> References: <200903261821.16410.dale@daleglass.net> <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> Message-ID: On 2009-03-26, at 15:08, Colin Kern wrote: > I think this a great idea too! The next step is to have support for > last.fm scrobbling :D Crikey, that would be bonza! From sldev at free.fr Fri Mar 27 05:28:28 2009 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 27 Mar 2009 13:28:28 +0100 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <200903262125.25198.dale@daleglass.net> References: <200903261821.16410.dale@daleglass.net> <20090326195358.155e3c3a.sldev@free.fr> <200903262125.25198.dale@daleglass.net> Message-ID: <20090327132828.2fb93dad.sldev@free.fr> On Thu, 26 Mar 2009 21:25:24 +0100, Dale Glass wrote: > > I hope that sometime in > > the future, the viewer will gain its own notices log floater and that > > the chat log will only hold actual chat lines). > > Why hope when you could get it done? It should be doable in a day or two. Don't count on me: too many higher priority projects going on here. From dale at daleglass.net Fri Mar 27 07:22:09 2009 From: dale at daleglass.net (Dale Glass) Date: Fri, 27 Mar 2009 15:22:09 +0100 Subject: [sldev] =?utf-8?q?Added_streaming_info_for_Linux=2C_Windows/Mac_v?= =?utf-8?q?ersion_=09needed?= In-Reply-To: References: <200903261821.16410.dale@daleglass.net> <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> Message-ID: <200903271522.16515.dale@daleglass.net> On ??????? 27 ????? 2009 12:49:06 Argent Stonecutter wrote: > On 2009-03-26, at 15:08, Colin Kern wrote: > > I think this a great idea too! The next step is to have support for > > last.fm scrobbling :D > > Crikey, that would be bonza! I've thought of that, but I think it'd be better to give the user more control first. How about: An user configurable default stream, to play when there's no parcel stream set. And a way for the user to override the stream, if they don't like it for instance. -------------- 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/20090327/3ddcb18e/attachment.pgp From carlo at alinoe.com Fri Mar 27 09:03:26 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 27 Mar 2009 17:03:26 +0100 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: References: <20090326034811.GA25411@alinoe.com> <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> <20090326155828.GA24487@alinoe.com> Message-ID: <20090327160326.GA11218@alinoe.com> Did you figure it out yet what mOffset exactly is? I'd really like to hear from you :) On Thu, Mar 26, 2009 at 09:46:36AM -0700, Philippe Bossut (Merov Linden) wrote: > is adding a different header to j2c files... I'll be investigating more > this morning and report my findings here. -- Carlo Wood From robla at lindenlab.com Fri Mar 27 12:08:27 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 27 Mar 2009 12:08:27 -0700 Subject: [sldev] OpenLife source code Message-ID: <49CD242B.7010302@lindenlab.com> Hi folks, We're in the middle of analyzing the oft-discussed 3DX (Open Life Grid) source code. It appears they've recently posted some source code here: http://3dxviewer.com/download-source-code.aspx Is this the source everyone is looking for? Please let us know if anything appears to be missing (mail me personally and cc licensing at lindenlab.com) Thanks Rob From tom at streamsense.net Fri Mar 27 12:31:40 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 27 Mar 2009 19:31:40 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <49CD242B.7010302@lindenlab.com> References: <49CD242B.7010302@lindenlab.com> Message-ID: <49CD299C.90405@streamsense.net> Yes, they finally posted the source code that they should have posted a month ago.. but better late than never. This seems to be current, build 160. ~T Rob Lanphier wrote: > Hi folks, > > We're in the middle of analyzing the oft-discussed 3DX (Open Life Grid) > source code. It appears they've recently posted some source code here: > http://3dxviewer.com/download-source-code.aspx > > Is this the source everyone is looking for? Please let us know if > anything appears to be missing (mail me personally and cc > licensing at lindenlab.com) > > Thanks > 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 > From dale at daleglass.net Fri Mar 27 13:10:49 2009 From: dale at daleglass.net (Dale Glass) Date: Fri, 27 Mar 2009 21:10:49 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <49CD299C.90405@streamsense.net> References: <49CD242B.7010302@lindenlab.com> <49CD299C.90405@streamsense.net> Message-ID: <200903272110.55693.dale@daleglass.net> On ??????? 27 ????? 2009 20:31:40 Thomas Grimshaw wrote: > Yes, they finally posted the source code that they should have posted a > month ago.. but better late than never. > > This seems to be current, build 160. Well, R16.3.rar doesn't pass develop.py: $ ./develop.py --standalone Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELEASE -G \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE -DSTANDALONE:BOOL=TRUE - DUNATTENDED:BOOL=FALSE "" \'/home/olg/R16_3/indra\'' in 'viewer-linux- x86_64' -- 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 CMake Error at CMakeLists.txt:21 (include): include could not find load file: Ogre http://3dxviewer.com/media/3DXviewer R16 Series Source.zip does seem to fare better, though there are many compile errors under gcc 4.3.2. This seems to be based on a fairly old LL branch, as I remember some of those errors from before, like fprintf(fd, "foo") instead of fprintf(fd, "%s", foo). I'm working on getting it to build, and will post a patch when done. -------------- 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/20090327/051f3bcf/attachment.pgp From gareth at garethnelson.com Fri Mar 27 13:22:37 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 20:22:37 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <200903272110.55693.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com> <49CD299C.90405@streamsense.net> <200903272110.55693.dale@daleglass.net> Message-ID: <4ebfc1100903271322m62f192ccwdd25df4ef475bba4@mail.gmail.com> Does it assume OGRE to be preinstalled on the system, or is this something missing from the release? On Fri, Mar 27, 2009 at 8:10 PM, Dale Glass wrote: > On ??????? 27 ????? 2009 20:31:40 Thomas Grimshaw wrote: >> Yes, they finally posted the source code that they should have posted a >> month ago.. but better late than never. >> >> This seems to be current, build 160. > Well, R16.3.rar doesn't pass develop.py: > > $ ./develop.py --standalone > Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELEASE -G \'Unix > Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE -DSTANDALONE:BOOL=TRUE - > DUNATTENDED:BOOL=FALSE "" \'/home/olg/R16_3/indra\'' in 'viewer-linux- > x86_64' > -- 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 > CMake Error at CMakeLists.txt:21 (include): > include could not find load file: > > Ogre > > http://3dxviewer.com/media/3DXviewer R16 Series Source.zip does seem to > fare better, though there are many compile errors under gcc 4.3.2. This > seems to be based on a fairly old LL branch, as I remember some of those > errors from before, like fprintf(fd, "foo") instead of fprintf(fd, "%s", > foo). > > I'm working on getting it to build, and will post a patch when done. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From gareth at garethnelson.com Fri Mar 27 13:26:08 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 20:26:08 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271322m62f192ccwdd25df4ef475bba4@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <49CD299C.90405@streamsense.net> <200903272110.55693.dale@daleglass.net> <4ebfc1100903271322m62f192ccwdd25df4ef475bba4@mail.gmail.com> Message-ID: <4ebfc1100903271326l4a29fa19ubc3267aff042ebe3@mail.gmail.com> Please note - don't include licensing at lindenlab.com in your replies, I don't think LL's licensing team needs every single post on this list forwarded to them ;) 2009/3/27 Gareth Nelson : > Does it assume OGRE to be preinstalled on the system, or is this > something missing from the release? > > On Fri, Mar 27, 2009 at 8:10 PM, Dale Glass wrote: >> On ??????? 27 ????? 2009 20:31:40 Thomas Grimshaw wrote: >>> Yes, they finally posted the source code that they should have posted a >>> month ago.. but better late than never. >>> >>> This seems to be current, build 160. >> Well, R16.3.rar doesn't pass develop.py: >> >> $ ./develop.py --standalone >> Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELEASE -G \'Unix >> Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE -DSTANDALONE:BOOL=TRUE - >> DUNATTENDED:BOOL=FALSE "" \'/home/olg/R16_3/indra\'' in 'viewer-linux- >> x86_64' >> -- 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 >> CMake Error at CMakeLists.txt:21 (include): >> include could not find load file: >> >> Ogre >> >> http://3dxviewer.com/media/3DXviewer R16 Series Source.zip does seem to >> fare better, though there are many compile errors under gcc 4.3.2. This >> seems to be based on a fairly old LL branch, as I remember some of those >> errors from before, like fprintf(fd, "foo") instead of fprintf(fd, "%s", >> foo). >> >> I'm working on getting it to build, and will post a patch when done. >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > > > -- > "Lanie, I'm going to print more printers. Lots more printers. One for > everyone. That's worth going to jail for. That's worth anything." - > Printcrime by Cory Doctrow > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > -- "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dale at daleglass.net Fri Mar 27 13:31:17 2009 From: dale at daleglass.net (Dale Glass) Date: Fri, 27 Mar 2009 21:31:17 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271322m62f192ccwdd25df4ef475bba4@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <200903272110.55693.dale@daleglass.net> <4ebfc1100903271322m62f192ccwdd25df4ef475bba4@mail.gmail.com> Message-ID: <200903272131.22523.dale@daleglass.net> On ??????? 27 ????? 2009 21:22:37 Gareth Nelson wrote: > Does it assume OGRE to be preinstalled on the system, or is this > something missing from the release? I don't know much about CMake yet, but my impression is that something is missing from the release. CMakeLists.txt, lines 20 and 21: include(Variables) include(Ogre) indra/cmake/Variables.cmake exists indra/cmake/Ogre.cmake doesn't. strace confirms that this is what it's looking for: [pid 18388] access("/home/olg/R16_3/indra/cmake/Ogre.cmake", R_OK) = -1 ENOENT (No such file or directory) [pid 18388] access("/usr/share/cmake-2.6/Modules/Ogre.cmake", R_OK) = -1 ENOENT (No such file or directory) [pid 18388] access("/home/olg/R16_3/indra/Ogre", R_OK) = -1 ENOENT (No such file or directory) -------------- 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/20090327/49deec4a/attachment.pgp From merov at lindenlab.com Fri Mar 27 13:33:07 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 27 Mar 2009 13:33:07 -0700 Subject: [sldev] Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: <20090327160326.GA11218@alinoe.com> References: <20090326034811.GA25411@alinoe.com> <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> <20090326155828.GA24487@alinoe.com> <20090327160326.GA11218@alinoe.com> Message-ID: <3504330C-B6C5-42DC-B0CA-A64D00410251@lindenlab.com> Hi Carlo, Sorry about the delay. Things were a little bit more complex for me to figure out as I'm working on a branch with lots of differences on how the cache works compared to the trunk (more on this later may be) so I wanted to make sure that I was not confusing everybody (including myself) mixing up the 2 versions of the code. First, "header" size: as Sheet Spotter said, it is 600 bytes, not 1 K as I said (I let out an expletive when I realized that the comment in lltexturecache.cpp was lying...). Second, mOffset is not the size of the "raw file header" data (whatever that's supposed to be...) as I thought but the size of a "header" the viewer could be stuffing in front of the raw data. For j2c files (the only type of file cached that way right now), it is always 0 and, so far, I haven't found one instance where that was different. So, the complex code you've been pointing to has, more than likely, never been exercised with anything else than (mOffset == 0)... which is a sort of degenerate case anyway. Your schema is correct: <------TEXTURE_CACHE_ENTRY_SIZE------><-------------cache file------------> <----mOffset----><----JPEG2000 header----><-----pixel data-------> But as for what is in the mOffset section, we're pretty much on our own since it's always 0... Extra info on images? Padding? Don't know but it's clear in the code that the whole acrobatics you asked about in your initial post is about skipping that section when rebuilding the whole raw stream of data from the "header cache" and the "body cache" (cache file in your schema) before stuffing that into a decoder. For the rest, the wiki is short but correct: http://wiki.secondlife.com/wiki/Texture_cache I'm working now on documenting the various threads. Cheers, - Merov On Mar 27, 2009, at 9:03 AM, Carlo Wood wrote: > Did you figure it out yet what mOffset exactly is? > I'd really like to hear from you :) > > On Thu, Mar 26, 2009 at 09:46:36AM -0700, Philippe Bossut (Merov > Linden) wrote: >> is adding a different header to j2c files... I'll be investigating >> more >> this morning and report my findings here. > > -- > Carlo Wood -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090327/6b6c49ea/attachment-0001.htm From gareth at garethnelson.com Fri Mar 27 13:39:54 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 20:39:54 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <200903272131.22523.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com> <200903272110.55693.dale@daleglass.net> <4ebfc1100903271322m62f192ccwdd25df4ef475bba4@mail.gmail.com> <200903272131.22523.dale@daleglass.net> Message-ID: <4ebfc1100903271339p2edd108fnc11e23a8bca2ce77@mail.gmail.com> Then there's a problem there :) 2009/3/27 Dale Glass : > On ??????? 27 ????? 2009 21:22:37 Gareth Nelson wrote: >> Does it assume OGRE to be preinstalled on the system, or is this >> something missing from the release? > I don't know much about CMake yet, but my impression is that something is > missing from the release. > > > CMakeLists.txt, lines 20 and 21: > include(Variables) > include(Ogre) > > indra/cmake/Variables.cmake exists > indra/cmake/Ogre.cmake doesn't. > > strace confirms that this is what it's looking for: > > [pid 18388] access("/home/olg/R16_3/indra/cmake/Ogre.cmake", R_OK) = -1 > ENOENT (No such file or directory) > [pid 18388] access("/usr/share/cmake-2.6/Modules/Ogre.cmake", R_OK) = -1 > ENOENT (No such file or directory) > [pid 18388] access("/home/olg/R16_3/indra/Ogre", R_OK) = -1 ENOENT (No such > file or directory) > > -- "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dale at daleglass.net Fri Mar 27 14:23:55 2009 From: dale at daleglass.net (Dale Glass) Date: Fri, 27 Mar 2009 22:23:55 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271339p2edd108fnc11e23a8bca2ce77@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <200903272131.22523.dale@daleglass.net> <4ebfc1100903271339p2edd108fnc11e23a8bca2ce77@mail.gmail.com> Message-ID: <200903272224.00647.dale@daleglass.net> On ??????? 27 ????? 2009 21:26:08 Gareth Nelson wrote: > Please note - don't include licensing at lindenlab.com in your replies, I > don't think LL's licensing team needs every single post on this list > forwarded to them ;) Whoops. Bad habit of always hitting 'a'. My apologies ^_^;; On ??????? 27 ????? 2009 21:39:54 Gareth Nelson wrote: > Then there's a problem there :) Well, I built it, and it fails to log in. Says: Login failed. The Version you are using is either out of date or incorrect. Please visit http://openlifegrid.com to download and install the latest Viewer. This one identifies itself as: (Openlife R16) 1.16.3 (84). The version available for download is: http://dl1.3dxviewer.com/3DXViewer/OpenLife R16_3_Linux-i686(R4).tar.lzma Now what's left to figure out is: is it doing a MD5 check against the built binary (fine according to GPL2, and easily worked around), or is there anything in the login process that's not included in the release (which would not be ok) Quick and dirty patch to get it to build attached. With this it should build fine on Ubuntu Intrepid at least. Additional instructions for Linux: rename the source folder to one without spaces in it. The packaging stage doesn't like it. chmod +x develop.py dos2unix develop.py dos2unix newview/app_settings/*.ini -------------- next part -------------- A non-text attachment was scrubbed... Name: 3dx_gcc4.patch Type: text/x-patch Size: 4920 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090327/0b5795e5/attachment.bin -------------- 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/20090327/0b5795e5/attachment.pgp From robla at lindenlab.com Fri Mar 27 14:36:53 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 27 Mar 2009 14:36:53 -0700 Subject: [sldev] OpenLife source code In-Reply-To: <200903272224.00647.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com><200903272131.22523.dale@daleglass.net><4ebfc1100903271339p2edd108fnc11e23a8bca2ce77@ mail.gmail.com> <200903272224.00647.dale@daleglass.net> Message-ID: <49CD46F5.2080600@lindenlab.com> Dale and everyone else, Thanks very much for your quick and incredibly useful replies here. We're really interested in making sure that they've included all of the source code necessary to fully recreate the binary they distribute. Rob On 03/27/2009 02:23 PM, Dale Glass wrote: > On ??????? 27 ????? 2009 21:26:08 Gareth Nelson wrote: > >> Please note - don't include licensing at lindenlab.com in your replies, I >> don't think LL's licensing team needs every single post on this list >> forwarded to them ;) >> > Whoops. Bad habit of always hitting 'a'. > My apologies ^_^;; > > On ??????? 27 ????? 2009 21:39:54 Gareth Nelson wrote: > >> Then there's a problem there :) >> > > Well, I built it, and it fails to log in. Says: > > Login failed. > The Version you are using is either out of date or incorrect. Please visit > http://openlifegrid.com to download and install the latest Viewer. > > This one identifies itself as: (Openlife R16) 1.16.3 (84). > > The version available for download is: > http://dl1.3dxviewer.com/3DXViewer/OpenLife R16_3_Linux-i686(R4).tar.lzma > > Now what's left to figure out is: is it doing a MD5 check against the built > binary (fine according to GPL2, and easily worked around), or is there > anything in the login process that's not included in the release (which > would not be ok) > > Quick and dirty patch to get it to build attached. With this it should > build fine on Ubuntu Intrepid at least. Additional instructions for Linux: > > rename the source folder to one without spaces in it. The packaging stage > doesn't like it. > > chmod +x develop.py > dos2unix develop.py > dos2unix newview/app_settings/*.ini > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 gareth at garethnelson.com Fri Mar 27 14:45:24 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 21:45:24 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <200903272224.00647.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com> <200903272131.22523.dale@daleglass.net> <4ebfc1100903271339p2edd108fnc11e23a8bca2ce77@mail.gmail.com> <200903272224.00647.dale@daleglass.net> Message-ID: <4ebfc1100903271445x1810755m950abde6fc1179d9@mail.gmail.com> It may be worth testing by hacking it to send the same MD5 as their official binary, if it won't connect then obviously something else is going on. 2009/3/27 Dale Glass : > On ??????? 27 ????? 2009 21:26:08 Gareth Nelson wrote: >> Please note - don't include licensing at lindenlab.com in your replies, I >> don't think LL's licensing team needs every single post on this list >> forwarded to them ;) > Whoops. Bad habit of always hitting 'a'. > My apologies ^_^;; > > On ??????? 27 ????? 2009 21:39:54 Gareth Nelson wrote: >> Then there's a problem there :) > > Well, I built it, and it fails to log in. Says: > > Login failed. > The Version you are using is either out of date or incorrect. Please visit > http://openlifegrid.com to download and install the latest Viewer. > > This one identifies itself as: (Openlife R16) 1.16.3 (84). > > The version available for download is: > http://dl1.3dxviewer.com/3DXViewer/OpenLife R16_3_Linux-i686(R4).tar.lzma > > Now what's left to figure out is: is it doing a MD5 check against the built > binary (fine according to GPL2, and easily worked around), or is there > anything in the login process that's not included in the release (which > would not be ok) > > Quick and dirty patch to get it to build attached. With this it should > build fine on Ubuntu Intrepid at least. Additional instructions for Linux: > > rename the source folder to one without spaces in it. The packaging stage > doesn't like it. > > chmod +x develop.py > dos2unix develop.py > dos2unix newview/app_settings/*.ini > > > -- "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dale at daleglass.net Fri Mar 27 14:52:43 2009 From: dale at daleglass.net (Dale Glass) Date: Fri, 27 Mar 2009 22:52:43 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271445x1810755m950abde6fc1179d9@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <200903272224.00647.dale@daleglass.net> <4ebfc1100903271445x1810755m950abde6fc1179d9@mail.gmail.com> Message-ID: <200903272252.51007.dale@daleglass.net> On ??????? 27 ????? 2009 22:45:24 Gareth Nelson wrote: > It may be worth testing by hacking it to send the same MD5 as their > official binary, if it won't connect then obviously something else is > going on. I'm working on that right now. Can somebody confirm what sort of thing can normally cause a failure to login? I can think of: channel, version, MD5. Anything else of the sort to look for? -------------- 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/20090327/b6ac7d38/attachment.pgp From kf6kjg at gmail.com Fri Mar 27 14:55:42 2009 From: kf6kjg at gmail.com (Ricky) Date: Fri, 27 Mar 2009 14:55:42 -0700 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <200903271522.16515.dale@daleglass.net> References: <200903261821.16410.dale@daleglass.net> <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> <200903271522.16515.dale@daleglass.net> Message-ID: <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> Well, if the user wanted background music... They could just load up their favorite media player. Yet I understand that playing a stream in-viewer which can be interrupted by parcel music would have a cleaner interface. No dual streams for instance. But then, are we adding too much? Does the SL viewer also need to be a media player? After all, the next logical step from user-configurable default streams is user playlists and files... VLC does all that for me quite nicely... However... Maybe the viewer could export a file, or server port, that was a copy of the stream from the current parcel media server? This way I could point my favorite media player at that location and have it handle the selecting another track when the stream stops. Ricky aka Cron Stardust On Fri, Mar 27, 2009 at 7:22 AM, Dale Glass wrote: > On ??????? 27 ????? 2009 12:49:06 Argent Stonecutter wrote: > > On 2009-03-26, at 15:08, Colin Kern wrote: > > > I think this a great idea too! The next step is to have support for > > > last.fm scrobbling :D > > > > Crikey, that would be bonza! > > I've thought of that, but I think it'd be better to give the user more > control first. > > How about: > > An user configurable default stream, to play when there's no parcel stream > set. > > And a way for the user to override the stream, if they don't like it for > instance. > > > > _______________________________________________ > 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/20090327/601c6f16/attachment-0001.htm From gareth at garethnelson.com Fri Mar 27 14:56:14 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 21:56:14 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <200903272252.51007.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com> <200903272224.00647.dale@daleglass.net> <4ebfc1100903271445x1810755m950abde6fc1179d9@mail.gmail.com> <200903272252.51007.dale@daleglass.net> Message-ID: <4ebfc1100903271456t2aefa674x6743cd4870a860ed@mail.gmail.com> From bogus@does.not.exist.com Tue Mar 10 20:13:32 2009 From: bogus@does.not.exist.com () Date: Wed, 11 Mar 2009 03:13:32 -0000 Subject: No subject Message-ID: problems is the user agent string, if you set the version and channel values to be identical to the OLG login request but get the user agent string wrong it fails. Here's what the login XML-RPC looks like as a python dict: (({'last': 'Last', 'platform': 'Win', 'passwd': '$1$PASSWORDHASH', 'start': 'last', 'version': 'Openlife R16 1.16.2.70', 'last_exec_event': 0, 'options': ['inventory-root', 'inventory-skeleton', 'inventory-lib-root', 'inventory-lib-owner', 'inventory-skel-lib', 'initial-outfit', 'gestures', 'event_categories', 'event_notifications', 'classified_categories', 'buddy-list', 'ui-config', 'tutorial_setting', 'login-flags', 'global-textures'], 'channel': 'Openlife R16', 'first': 'First'},), u'login_to_simulator') Yes, it says "Win" for platform even on windows, for reasons known only to = them 2009/3/27 Dale Glass : > On =F0=D1=D4=CE=C9=C3=C1 27 =CD=C1=D2=D4=C1 2009 22:45:24 Gareth Nelson w= rote: >> It may be worth testing by hacking it to send the same MD5 as their >> official binary, if it won't connect then obviously something else is >> going on. > > I'm working on that right now. > > Can somebody confirm what sort of thing can normally cause a failure to > login? I can think of: channel, version, MD5. Anything else of the sort t= o > look for? > > --=20 "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From gareth at garethnelson.com Fri Mar 27 14:56:37 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 21:56:37 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271456t2aefa674x6743cd4870a860ed@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <200903272224.00647.dale@daleglass.net> <4ebfc1100903271445x1810755m950abde6fc1179d9@mail.gmail.com> <200903272252.51007.dale@daleglass.net> <4ebfc1100903271456t2aefa674x6743cd4870a860ed@mail.gmail.com> Message-ID: <4ebfc1100903271456qfe6ea0ubb2d716882da73e0@mail.gmail.com> err, "even on linux" /me drinks more red bull 2009/3/27 Gareth Nelson : > From my own experiments with their viewer, the main thing which causes > problems is the user agent string, if you set the version and channel > values to be identical to the OLG login request but get the user agent > string wrong it fails. > Here's what the login XML-RPC looks like as a python dict: > (({'last': 'Last', 'platform': 'Win', 'passwd': '$1$PASSWORDHASH', > 'start': 'last', 'version': 'Openlife R16 1.16.2.70', > 'last_exec_event': 0, 'options': ['inventory-root', > 'inventory-skeleton', 'inventory-lib-root', 'inventory-lib-owner', > 'inventory-skel-lib', 'initial-outfit', 'gestures', > 'event_categories', 'event_notifications', 'classified_categories', > 'buddy-list', 'ui-config', 'tutorial_setting', 'login-flags', > 'global-textures'], 'channel': 'Openlife R16', 'first': 'First'},), > u'login_to_simulator') > > Yes, it says "Win" for platform even on windows, for reasons known only to them > > 2009/3/27 Dale Glass : >> On ??????? 27 ????? 2009 22:45:24 Gareth Nelson wrote: >>> It may be worth testing by hacking it to send the same MD5 as their >>> official binary, if it won't connect then obviously something else is >>> going on. >> >> I'm working on that right now. >> >> Can somebody confirm what sort of thing can normally cause a failure to >> login? I can think of: channel, version, MD5. Anything else of the sort to >> look for? >> >> > > > > -- > "Lanie, I'm going to print more printers. Lots more printers. One for > everyone. That's worth going to jail for. That's worth anything." - > Printcrime by Cory Doctrow > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > -- "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From robla at lindenlab.com Fri Mar 27 14:59:37 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 27 Mar 2009 14:59:37 -0700 Subject: [sldev] "easybuild" branch, courtesy Kitware Message-ID: <49CD4C49.5080805@lindenlab.com> Hi everyone, As you may recall from December, we issued an RFP for improving our build process: https://jira.secondlife.com/browse/VWR-11114 We got a couple of great proposals, and selected Kitware (makers of CMake) for doing that work. Work has commenced now. Kitware convinced us that an important first step is to move develop.py out of the way, and just have developers invoke CMake in order to start a build. The really astute among you may have already noticed this work here: http://svn.secondlife.com/trac/linden/browser/projects/2009/easybuild We'll have more details later about how that work is going by next week, but I've been meaning to get this note out for a while. Rob From tom at streamsense.net Fri Mar 27 16:04:53 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 27 Mar 2009 23:04:53 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <200903272224.00647.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com> <200903272131.22523.dale@daleglass.net> <4ebfc1100903271339p2edd108fnc11e23a8bca2ce77@mail.gmail.com> <200903272224.00647.dale@daleglass.net> Message-ID: <49CD5B95.9070302@streamsense.net> Dale Glass wrote: > This one identifies itself as: (Openlife R16) 1.16.3 (84). I don't think so, llversionviewer.h shows build 160, which is current, are you sure you downloaded the correct package? The viewer can login fine if the version string is set to Openlife R16 1.16.3.160 I've been maintaining a third party viewer at http://www.virtumesh.com/remedyviewer/ which was based on build 84 with hacks to spoof build 160 - but they have actively tried to block the viewer by tweaking their login proxy.. Basically ladies and gents, I believe they're currently in compliance with the linden license (though perhaps not the ogre license), however they do /not/ publish the source code in a prompt manner, and their practices are very counterproductive to the open source community. I was met with anger, personal attacks and slander by openlife affiliates when I released the viewer based on kirsten's code. One to watch closely, I feel. ~Tomm From dale at daleglass.net Fri Mar 27 16:20:19 2009 From: dale at daleglass.net (Dale Glass) Date: Sat, 28 Mar 2009 00:20:19 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271456t2aefa674x6743cd4870a860ed@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <200903272252.51007.dale@daleglass.net> <4ebfc1100903271456t2aefa674x6743cd4870a860ed@mail.gmail.com> Message-ID: <200903280020.26636.dale@daleglass.net> Ok, got it to log in. No MD5, just version and channel changes, patch attached. Patch changes the version just in case, but may not be needed. But hm. Ths is not terribly useful. What I managed to compile is 1.16.3.84. What's currently available for download is .160. After looking better, I noticed this in the README of the .160 sources that didn't build: > The R16 is a hybrid Viewer part linden part 3DX part rex. > You will require the libs from a linden lab build > Also Ogre SDK, as well as creating Cmake scripts to link to the SDK This seems go to against point 3.c of the GPL, "complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable" To get it to build, they must have done the required cmake changes. Maybe they added it manually to the generated VS solution file, but they have a Linux build as well, and I find it doubtful they hack it into the auto- generated Makefile every time. -------------- next part -------------- A non-text attachment was scrubbed... Name: olg_login.patch Type: text/x-patch Size: 2154 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090328/fd21818f/attachment.bin -------------- 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/20090328/fd21818f/attachment.pgp From dale at daleglass.net Fri Mar 27 16:30:22 2009 From: dale at daleglass.net (Dale Glass) Date: Sat, 28 Mar 2009 00:30:22 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <49CD5B95.9070302@streamsense.net> References: <49CD242B.7010302@lindenlab.com> <200903272224.00647.dale@daleglass.net> <49CD5B95.9070302@streamsense.net> Message-ID: <200903280030.22902.dale@daleglass.net> On ??????? 28 ????? 2009 00:04:53 Thomas Grimshaw wrote: > Dale Glass wrote: > > This one identifies itself as: (Openlife R16) 1.16.3 (84). > > I don't think so, llversionviewer.h shows build 160, which is current, > are you sure you downloaded the correct package? 3DX offers two downloads at http://3dxviewer.com/download-source-code.aspx > Grab the newest R16.3 Series Source Code Package (.rar): > http://dl1.3dxviewer.com/Source/R16.3.rar This doesn't work at least on Linux, develop.py produces a CMake error about Ogre, as I explained in another post. The README helpfully says you have to write that one file yourself. I'm rather doubtful this is compliant with the GPL. > Grab the current R16 Series Source Code Package (.zip): > http://3dxviewer.com/media/3DXviewer R16 Series Source.zip This one does build, but it is old. If you're able to compile this one, could you explain what you did to make it work? > The viewer can login fine if the version string is set to Openlife R16 > 1.16.3.160 > > I've been maintaining a third party viewer at > http://www.virtumesh.com/remedyviewer/ which was based on build 84 with > hacks to spoof build 160 - but they have actively tried to block the > viewer by tweaking their login proxy.. Heheh, what are they changing? I'm interested in this, I'll probably make my own viewer (new version should be out soon, at last) able to log into OLG as well. > Basically ladies and gents, I believe they're currently in compliance > with the linden license (though perhaps not the ogre license), however > they do /not/ publish the source code in a prompt manner, and their > practices are very counterproductive to the open source community. I'm not so sure they're completely compliant yet. They're perhaps *mostly* compliant, but they make building .160 difficult, and based on what I heard it's probably completely intentional, and most likely not compliant with the GPL, which specifically requires sources AND the build scripts required. > I was met with anger, personal attacks and slander by openlife > affiliates when I released the viewer based on kirsten's code. Yeah, I had some issues of my own. This is probably not the best place to discuss it, but the interactions I had left a rather sour taste in my mouth. -------------- 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/20090328/73b70a45/attachment.pgp From dale at daleglass.net Fri Mar 27 16:34:31 2009 From: dale at daleglass.net (Dale Glass) Date: Sat, 28 Mar 2009 00:34:31 +0100 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> References: <200903261821.16410.dale@daleglass.net> <200903271522.16515.dale@daleglass.net> <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> Message-ID: <200903280034.31902.dale@daleglass.net> On ??????? 27 ????? 2009 22:55:42 Ricky wrote: > Well, if the user wanted background music... They could just load up > their favorite media player. > > Yet I understand that playing a stream in-viewer which can be > interrupted by parcel music would have a cleaner interface. No dual > streams for instance. But then, are we adding too much? Does the SL > viewer also need to be a media player? After all, the next logical step > from user-configurable default streams is user playlists and files... > VLC does all that for me quite nicely... Well, I am not sure how many people will agree with me on this, but I think that SL, as a "virtual world" should be complete enough that you don't need to get out of it. Especially, if you can play music, then it should work well enough that you don't need an external player. I don't think a full blown media player is needed, but in RL, if I don't like what's on TV in a bar I can pull out my own player. I think SL could use an equivalent of that. Also, I think this would make things in SL better. I notice that most people use an external player. This is mostly because they don't like the current stream or there isn't any. But then they may not find out when something interesting does start playing. > However... Maybe the viewer could export a file, or server port, that > was a copy of the stream from the current parcel media server? This way > I could point my favorite media player at that location and have it > handle the selecting another track when the stream stops. Hmm, I'd prefer something else: Have the possibility of using a LSL HUD to command the viewer to perform streaming tasks. Then I could have my "slpod" attached and use it to override the parcel stream if I want. -------------- 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/20090328/c7926b14/attachment-0001.pgp From gareth at garethnelson.com Fri Mar 27 16:46:24 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 27 Mar 2009 23:46:24 +0000 Subject: [sldev] OpenLife source code In-Reply-To: <200903280020.26636.dale@daleglass.net> References: <49CD242B.7010302@lindenlab.com> <200903272252.51007.dale@daleglass.net> <4ebfc1100903271456t2aefa674x6743cd4870a860ed@mail.gmail.com> <200903280020.26636.dale@daleglass.net> Message-ID: <4ebfc1100903271646m3caa0768m8644ca8032152697@mail.gmail.com> > This seems go to against point 3.c of the GPL, "complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control compilation and > installation of the executable" Indeed, it's VERY unlikely they hack the makefile by hand every time, something ain't right here. Perhaps poke licensing at lindenlab.com on this one properly? -- ?Lanie, I?m going to print more printers. Lots more printers. One for everyone. That?s worth going to jail for. That?s worth anything.? - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From dale at daleglass.net Fri Mar 27 17:28:11 2009 From: dale at daleglass.net (Dale Glass) Date: Sat, 28 Mar 2009 01:28:11 +0100 Subject: [sldev] OpenLife source code In-Reply-To: <4ebfc1100903271646m3caa0768m8644ca8032152697@mail.gmail.com> References: <49CD242B.7010302@lindenlab.com> <200903280020.26636.dale@daleglass.net> <4ebfc1100903271646m3caa0768m8644ca8032152697@mail.gmail.com> Message-ID: <200903280128.18377.dale@daleglass.net> On ??????? 28 ????? 2009 00:46:24 Gareth Nelson wrote: > > This seems go to against point 3.c of the GPL, "complete source code > > means all the source code for all modules it contains, plus any > > associated interface definition files, plus the scripts used to > > control compilation and installation of the executable" > > Indeed, it's VERY unlikely they hack the makefile by hand every time, > something ain't right here. > Perhaps poke licensing at lindenlab.com on this one properly? Ok, resuming the current situation. The latest released OLG Linux viewer is version .160. There are two downloads offered, http://3dxviewer.com/media/3DXviewer R16 Series Source.zip, which has version 1.16.3 (84), and compiles, but is out of date. There also is http://dl1.3dxviewer.com/Source/R16.3.rar, which has version 1.16.3 (160), but which doesn't build as delivered. It fails with: > CMake Error at CMakeLists.txt:21 (include): > include could not find load file: > Ogre The Build R16 README.txt file mentions this, and says: > The R16 is a hybrid Viewer part linden part 3DX part rex. > You will require the libs from a linden lab build > Also Ogre SDK, as well as creating Cmake scripts to link to the SDK I believe this is not compliant with the GPL2, section 3.c, which requires all the scripts required to compile the viewer to be included. If any changes were made to the cmake-generated Makefile or Visual Studio solution files, I believe they still fall under the GPL, and must be included, since I am entitled to receive the source code the binary I got was generated from. Since the latest version currently doesn't compile, it's difficult to perform a more thorough verification of whether everything that should be included has been delivered. I plan to try to compare the compiled binary with the one delivered on the website to make sure, as soon as I get it to build. -------------- 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/20090328/e8bc5fc5/attachment.pgp From robla at lindenlab.com Fri Mar 27 18:11:41 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 27 Mar 2009 18:11:41 -0700 Subject: [sldev] svn.secondlife.com downtime tonight Message-ID: <49CD794D.6010402@lindenlab.com> Hi folks, Our service provider be upgrading our public SVN server (svn.secondlife.com) to 1.5 on tonight, between 10pm and 2am PDT. The downtime should be approximately one hour during that window, and should not affect any other services. Rob From boy.lane at yahoo.com Fri Mar 27 20:22:08 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Sat, 28 Mar 2009 11:22:08 +0800 Subject: [sldev] SLDev Digest, Vol 27, Issue 45 References: Message-ID: <000e01c9af54$61b4c3c0$6500a8c0@hp> A couple of things to note here. The current b160 sources were reportedly posted on 3dxviewer.com at 22nd/23rd March. And they were backdated to 9th March to make them looking like they were in compliance earlier. It is a current source tree that fits their binary, however Dale is right. They try to make it difficult to compile a working version and they obviously want to prevent that anyone builds a 3rd party viewer other then KirstenLee's that can connect to their grid. They have said that several times and actively block all other viewers and tools by some obscure undocumented protocol change. Perhaps it's indeed only the version string :). What is missing in the source tree are a cmake file to include the OGRE SDK. That is mentioned in the 5 lines readme. What is also missing are some resources, icons if I remember correctly. Minor things and I don't think that was intentionally left out. GPL doesn't require to include libraries into a published source but as Dale wrote the required scripts to incorporated them (here cmake) should be there (GPL2 3.c) I was able to build the 160 viewer by manually installing the libs (easiest way to do so is by copying them from KirstenLee's older b84 sources), adding the missing resources the compiler complained about and commenting out two "include (Ogre)" lines in indra/CMakeLists.txt and indra/newview/CMakeLists.txt. It was successful and it could connect to OLG. There was a lot of discussion about the whole issue in http://www.sluniverse.com/php/vb/other-grids-virtual-worlds/26798-openlifegrid-continues-violate-gpl.html Please refer to that for more details. Boy > Message: 6 > Date: Sat, 28 Mar 2009 00:30:22 +0100 > From: Dale Glass > Subject: Re: [sldev] OpenLife source code > To: Thomas Grimshaw > Cc: sldev at lists.secondlife.com > Message-ID: <200903280030.22902.dale at daleglass.net> > Content-Type: text/plain; charset="utf-8" > > On ??????? 28 ????? 2009 00:04:53 Thomas Grimshaw wrote: >> Dale Glass wrote: >> > This one identifies itself as: (Openlife R16) 1.16.3 (84). >> >> I don't think so, llversionviewer.h shows build 160, which is current, >> are you sure you downloaded the correct package? > 3DX offers two downloads at http://3dxviewer.com/download-source-code.aspx > >> Grab the newest R16.3 Series Source Code Package (.rar): >> http://dl1.3dxviewer.com/Source/R16.3.rar > > This doesn't work at least on Linux, develop.py produces a CMake error > about Ogre, as I explained in another post. The README helpfully says you > have to write that one file yourself. I'm rather doubtful this is > compliant > with the GPL. > > >> Grab the current R16 Series Source Code Package (.zip): >> http://3dxviewer.com/media/3DXviewer R16 Series Source.zip > > This one does build, but it is old. > > If you're able to compile this one, could you explain what you did to make > it work? > > >> The viewer can login fine if the version string is set to Openlife R16 >> 1.16.3.160 >> >> I've been maintaining a third party viewer at >> http://www.virtumesh.com/remedyviewer/ which was based on build 84 with >> hacks to spoof build 160 - but they have actively tried to block the >> viewer by tweaking their login proxy.. > Heheh, what are they changing? > > I'm interested in this, I'll probably make my own viewer (new version > should be out soon, at last) able to log into OLG as well. > >> Basically ladies and gents, I believe they're currently in compliance >> with the linden license (though perhaps not the ogre license), however >> they do /not/ publish the source code in a prompt manner, and their >> practices are very counterproductive to the open source community. > I'm not so sure they're completely compliant yet. > > They're perhaps *mostly* compliant, but they make building .160 difficult, > and based on what I heard it's probably completely intentional, and most > likely not compliant with the GPL, which specifically requires sources AND > the build scripts required. > >> I was met with anger, personal attacks and slander by openlife >> affiliates when I released the viewer based on kirsten's code. > Yeah, I had some issues of my own. This is probably not the best place to > discuss it, but the interactions I had left a rather sour taste in my > mouth. > From lists.secondlife.com at trap.wereanimal.net Sat Mar 28 01:33:43 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Sat, 28 Mar 2009 04:33:43 -0400 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <49CD4C49.5080805@lindenlab.com> References: <49CD4C49.5080805@lindenlab.com> Message-ID: <200903280433.43256.lists.secondlife.com@trap.wereanimal.net> On Friday 27 March 2009 05:59:37 pm Rob Lanphier wrote: > > Work has commenced now. Kitware convinced us that an important first > step is to move develop.py out of the way, and just have developers > invoke CMake in order to start a build. > YES!!!! I wrote and maintain a few ebuilds. They all use a cmake macro provided by portage cmake eclass. Out of curiosity, I tried doing a manual build using develop.py and it failed miserly. I have read and grok develop.py to make sure I was passing the right stuff to cmake. Dumping develope.py and using cmake configure/build would make the life of a linux distro packager a lot easier. Now to see if viewer_masifest.py can be replace by a simple cmake install. It took me the better part of a week to shoehorn viwer_manifest.py into an ebuild. --Techwolf Lupindo From armin.weatherwax at googlemail.com Sat Mar 28 02:23:45 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Sat, 28 Mar 2009 10:23:45 +0100 Subject: [sldev] =?iso-8859-15?q?Added_streaming_info_for_Linux=2C_Windows?= =?iso-8859-15?q?/Mac_version_=09needed?= In-Reply-To: <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> References: <200903261821.16410.dale@daleglass.net> <200903271522.16515.dale@daleglass.net> <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> Message-ID: <200903281023.45406.Armin.Weatherwax@gmail.com> Am Friday 27 March 2009 22:55:42 schrieb Ricky: > After all, the next logical step from > user-configurable default streams is user playlists and files... VLC does > all that for me quite nicely... Playlist support would also make it easier to maintain parcel streams, which VLC can not do. :) From gareth at garethnelson.com Sat Mar 28 04:44:37 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Sat, 28 Mar 2009 11:44:37 +0000 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <49CD4C49.5080805@lindenlab.com> References: <49CD4C49.5080805@lindenlab.com> Message-ID: <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> Personally I find SCons much much easier to work with, especially for porting work - is there any way SCons could be brought back alongside cmake perhaps? On Fri, Mar 27, 2009 at 9:59 PM, Rob Lanphier wrote: > Hi everyone, > > As you may recall from December, we issued an RFP for improving our > build process: > https://jira.secondlife.com/browse/VWR-11114 > > We got a couple of great proposals, and selected Kitware (makers of > CMake) for doing that work. > > Work has commenced now. ?Kitware convinced us that an important first > step is to move develop.py out of the way, and just have developers > invoke CMake in order to start a build. > > The really astute among you may have already noticed this work here: > http://svn.secondlife.com/trac/linden/browser/projects/2009/easybuild > > We'll have more details later about how that work is going by next week, > but I've been meaning to get this note out for a while. > > 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 > -- ?Lanie, I?m going to print more printers. Lots more printers. One for everyone. That?s worth going to jail for. That?s worth anything.? - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From jan.ciger at gmail.com Sat Mar 28 06:54:51 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat, 28 Mar 2009 14:54:51 +0100 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> Message-ID: <49CE2C2B.8010204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gareth Nelson wrote: > Personally I find SCons much much easier to work with, especially for > porting work - is there any way SCons could be brought back > alongside cmake perhaps? SCons is nice, seconded. However, it needs Python and especially Windows users have a lot of trouble with getting the combination to work :( Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJziwrn11XseNj94gRAuugAKC1QHQk0anTjgexivuv63m5ZJBucACgizox G5zZ1qF479zULhknKFxaYgw= =HiIS -----END PGP SIGNATURE----- From tom at streamsense.net Sat Mar 28 06:57:21 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Sat, 28 Mar 2009 13:57:21 +0000 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <49CE2C2B.8010204@gmail.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <49CE2C2B.8010204@gmail.com> Message-ID: <49CE2CC1.9060300@streamsense.net> Jan Ciger wrote: > SCons is nice, seconded. However, it needs Python and especially Windows > users have a lot of trouble with getting the combination to work :( Python is required for the build anyway, so that's a non issue... as for windows compatibility as a whole, i've never had problems with scons.. ~T From gareth at litesim.com Sat Mar 28 06:57:38 2009 From: gareth at litesim.com (Gareth Nelson) Date: Sat, 28 Mar 2009 13:57:38 +0000 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <49CE2C2B.8010204@gmail.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <49CE2C2B.8010204@gmail.com> Message-ID: <61dbdd7d0903280657v58d1d88doc7c26f29ef154092@mail.gmail.com> cmake requires........ cmake The whole thing requires development tools, on windows you need visual studio too On Sat, Mar 28, 2009 at 1:54 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gareth Nelson wrote: >> Personally I find SCons much much easier to work with, especially for >> ?porting work - is there any way ?SCons could be brought back >> alongside cmake perhaps? > > SCons is nice, seconded. However, it needs Python and especially Windows > users have a lot of trouble with getting the combination to work :( > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFJziwrn11XseNj94gRAuugAKC1QHQk0anTjgexivuv63m5ZJBucACgizox > G5zZ1qF479zULhknKFxaYgw= > =HiIS > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Sat Mar 28 07:24:20 2009 From: soft at lindenlab.com (Soft) Date: Sat, 28 Mar 2009 09:24:20 -0500 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> Message-ID: cmake does everything Linden Lab needs at present, so signing up to maintain another build system ourselves wouldn't be a good investment for us. If you, or anyone, want to maintain scons on the side, we could certainly make a home for that project in subversion. Or you could maintain it as a patch set in JIRA the way people used to maintain VS2005 project files. On Sat, Mar 28, 2009 at 6:44 AM, Gareth Nelson wrote: > Personally I find SCons much much easier to work with, especially for > porting work - is there any way ?SCons could be brought back alongside > cmake perhaps? > > On Fri, Mar 27, 2009 at 9:59 PM, Rob Lanphier wrote: >> Hi everyone, >> >> As you may recall from December, we issued an RFP for improving our >> build process: >> https://jira.secondlife.com/browse/VWR-11114 >> >> We got a couple of great proposals, and selected Kitware (makers of >> CMake) for doing that work. >> >> Work has commenced now. ?Kitware convinced us that an important first >> step is to move develop.py out of the way, and just have developers >> invoke CMake in order to start a build. >> >> The really astute among you may have already noticed this work here: >> http://svn.secondlife.com/trac/linden/browser/projects/2009/easybuild >> >> We'll have more details later about how that work is going by next week, >> but I've been meaning to get this note out for a while. >> >> 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 >> > > > > -- > ?Lanie, I?m going to print more printers. Lots more printers. One for > everyone. That?s worth going to jail for. That?s worth anything.? - > Printcrime by Cory Doctrow > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > _______________________________________________ > 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 gcanaday at gmail.com Sat Mar 28 07:40:09 2009 From: gcanaday at gmail.com (Glen) Date: Sat, 28 Mar 2009 10:40:09 -0400 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> Message-ID: <49CE36C9.7050903@gmail.com> When do they expect to have it done again? I'm eager to try it. Do they plan to have the OSS libraries auto-download as source, with the closed ones downloaded per architecture? 64-bit closed libraries is kind of important I think, since if we can't build them ourselves we'll at least need them for the right architecture. Vivox comes to mind - I don't want to lose something that's working now. Questions abound. --GC Soft wrote: > cmake does everything Linden Lab needs at present, so signing up to > maintain another build system ourselves wouldn't be a good investment > for us. If you, or anyone, want to maintain scons on the side, we > could certainly make a home for that project in subversion. Or you > could maintain it as a patch set in JIRA the way people used to > maintain VS2005 project files. > > On Sat, Mar 28, 2009 at 6:44 AM, Gareth Nelson wrote: >> Personally I find SCons much much easier to work with, especially for >> porting work - is there any way SCons could be brought back alongside >> cmake perhaps? >> >> On Fri, Mar 27, 2009 at 9:59 PM, Rob Lanphier wrote: >>> Hi everyone, >>> >>> As you may recall from December, we issued an RFP for improving our >>> build process: >>> https://jira.secondlife.com/browse/VWR-11114 >>> >>> We got a couple of great proposals, and selected Kitware (makers of >>> CMake) for doing that work. >>> >>> Work has commenced now. Kitware convinced us that an important first >>> step is to move develop.py out of the way, and just have developers >>> invoke CMake in order to start a build. >>> >>> The really astute among you may have already noticed this work here: >>> http://svn.secondlife.com/trac/linden/browser/projects/2009/easybuild >>> >>> We'll have more details later about how that work is going by next week, >>> but I've been meaning to get this note out for a while. >>> >>> 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 >>> >> >> >> -- >> ?Lanie, I?m going to print more printers. Lots more printers. One for >> everyone. That?s worth going to jail for. That?s worth anything.? - >> Printcrime by Cory Doctrow >> >> Please avoid sending me Word or PowerPoint attachments. >> See http://www.gnu.org/philosophy/no-word-attachments.html >> _______________________________________________ >> 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 dale at daleglass.net Sat Mar 28 07:48:09 2009 From: dale at daleglass.net (Dale Glass) Date: Sat, 28 Mar 2009 15:48:09 +0100 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> Message-ID: <200903281548.18090.dale@daleglass.net> On ??????? 28 ????? 2009 12:44:37 Gareth Nelson wrote: > Personally I find SCons much much easier to work with, especially for > porting work - is there any way SCons could be brought back alongside > cmake perhaps? But SCons doesn't have any way of generating project files, AFAIK. So CMake made things a lot easier for me. With scons I couldn't make my viewer build on OS X, and getting it to build on Windows involved repeating the changes made to scons. The best I could do was to say "Add files X, Y and Z to the project, and it should work", but that's problematic. -------------- 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/20090328/ee672d0f/attachment.pgp From gareth at garethnelson.com Sat Mar 28 09:04:29 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Sat, 28 Mar 2009 16:04:29 +0000 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <200903281548.18090.dale@daleglass.net> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <200903281548.18090.dale@daleglass.net> Message-ID: <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> It does however have a means of building using the standalone VS compiler on windows or gcc for OSX, i've used it myself for both these platforms with minimal issues. On Sat, Mar 28, 2009 at 2:48 PM, Dale Glass wrote: > On ??????? 28 ????? 2009 12:44:37 Gareth Nelson wrote: >> Personally I find SCons much much easier to work with, especially for >> porting work - is there any way SCons could be brought back alongside >> cmake perhaps? > > But SCons doesn't have any way of generating project files, AFAIK. > > So CMake made things a lot easier for me. With scons I couldn't make my > viewer build on OS X, and getting it to build on Windows involved repeating > the changes made to scons. > > The best I could do was to say "Add files X, Y and Z to the project, and it > should work", but that's problematic. > > -- "Lanie, I'm going to print more printers. Lots more printers. One for everyone. That's worth going to jail for. That's worth anything." - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From lists.secondlife.com at trap.wereanimal.net Sat Mar 28 10:24:48 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Sat, 28 Mar 2009 13:24:48 -0400 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <49CE36C9.7050903@gmail.com> References: <49CD4C49.5080805@lindenlab.com> <49CE36C9.7050903@gmail.com> Message-ID: <200903281324.48869.lists.secondlife.com@trap.wereanimal.net> On Saturday 28 March 2009 10:40:09 am Glen wrote: > When do they expect to have it done again? I'm eager to try it. > > Do they plan to have the OSS libraries auto-download as source, with the > closed ones downloaded per architecture? 64-bit closed libraries is kind > of important I think, since if we can't build them ourselves we'll at > least need them for the right architecture. Vivox comes to mind - I > don't want to lose something that's working now. > > Questions abound. > > --GC > I've discovered that the 32 bit vivox binary will work with a 64 bit build of the SL client. What needed to be done was to make sure it was installed in the right place. SLvoice in bin/ and the lib in lib/. Only other requirement was the 32-bit emulation libs. Most distros have these available in there package management system. --Techwolf Lupindo From dale at daleglass.net Sat Mar 28 10:46:50 2009 From: dale at daleglass.net (Dale Glass) Date: Sat, 28 Mar 2009 18:46:50 +0100 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <200903281324.48869.lists.secondlife.com@trap.wereanimal.net> References: <49CD4C49.5080805@lindenlab.com> <49CE36C9.7050903@gmail.com> <200903281324.48869.lists.secondlife.com@trap.wereanimal.net> Message-ID: <200903281846.57802.dale@daleglass.net> On ??????? 28 ????? 2009 18:24:48 lists.secondlife.com at trap.wereanimal.net > I've discovered that the 32 bit vivox binary will work with a 64 bit > build of the SL client. What needed to be done was to make sure it was > installed in the right place. SLvoice in bin/ and the lib in lib/. Only > other requirement was the 32-bit emulation libs. Most distros have these > available in there package management system. Of course it will, it's a separate executable and not a loadable library, so there's no problem with it being a 32 bit binary. However, I'd still really like a 64 bit version. Compatibility libraries can be a pain, especially when the distro doesn't ship some particular library, or ships a different version. Also, since it's an audio processing application perhaps it performs a bit better on 64 bit. Ideally though, what I'd *really* like is an open source implementation. Right now for some reason SLVoice refuses to record, while it lets me hear just fine. I don't know why it does that, and can't really debug it, which is *very* annoying. -------------- 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/20090328/0965667c/attachment.pgp From gcanaday at gmail.com Sat Mar 28 11:41:20 2009 From: gcanaday at gmail.com (Glen) Date: Sat, 28 Mar 2009 14:41:20 -0400 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <200903281324.48869.lists.secondlife.com@trap.wereanimal.net> References: <49CD4C49.5080805@lindenlab.com> <49CE36C9.7050903@gmail.com> <200903281324.48869.lists.secondlife.com@trap.wereanimal.net> Message-ID: <49CE6F50.40206@gmail.com> Yeah, it works right now. I use the ia32 stuff to run the production client. Wish I didn't have to. --GC lists.secondlife.com at trap.wereanimal.net wrote: > On Saturday 28 March 2009 10:40:09 am Glen wrote: >> When do they expect to have it done again? I'm eager to try it. >> >> Do they plan to have the OSS libraries auto-download as source, with the >> closed ones downloaded per architecture? 64-bit closed libraries is kind >> of important I think, since if we can't build them ourselves we'll at >> least need them for the right architecture. Vivox comes to mind - I >> don't want to lose something that's working now. >> >> Questions abound. >> >> --GC >> > > I've discovered that the 32 bit vivox binary will work with a 64 bit build of > the SL client. What needed to be done was to make sure it was installed in the > right place. SLvoice in bin/ and the lib in lib/. Only other requirement was > the 32-bit emulation libs. Most distros have these available in there package > management system. > > --Techwolf Lupindo > _______________________________________________ > 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 Sat Mar 28 19:24:19 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 28 Mar 2009 21:24:19 -0500 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> References: <200903261821.16410.dale@daleglass.net> <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> <200903271522.16515.dale@daleglass.net> <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> Message-ID: <17C87F67-7BEE-4316-815C-B000ABCE99AA@gmail.com> On 2009-03-27, at 16:55, Ricky wrote: > Yet I understand that playing a stream in-viewer which can be > interrupted by parcel music would have a cleaner interface. No dual > streams for instance. But then, are we adding too much? Does the > SL viewer also need to be a media player? After all, the next > logical step from user-configurable default streams is user > playlists and files... VLC does all that for me quite nicely... I don't want SL to be a general media player, but I would like to have what I'm listening to in SL scrobbled without messing with an external program. Alternatively, being able to map programs outside SL onto some equivalent of media textures IN SL would be nice. Trivial in X11 (make SL your window manager :) ) but probably harder in Windows or OS X. From alissa_sabre at yahoo.co.jp Sat Mar 28 20:43:30 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 29 Mar 2009 12:43:30 +0900 Subject: [sldev] tunk viewer build fails on MacOS Message-ID: <1kwz8zwwok5GJPGee.alissa_sabre@yahoo.co.jp> I'm wondering I should file this on JIRA, or I can get a quick solution on this list. I grabbed the SL viewer source from public svn trunk (r1928) and tried to build. It failed. The error I got was: ld: can't vm_allocate() buffer for output file of size 1130223472 ((os/kern) no space available) I searched the Internet and found that MacOS (Xcode) ld has a limit of 1GB on any output file, and the above message means output from ld was literary GIGAntic (i.e., exceeded 1GB). Unfortunately, I could find any solution to it, except "stop staying 32 bit and go 64 bit development." However, as you all know, SL program itself is around 50MB in size. It should easily fit in 32 bit space. It is debugging information that makes the resulting executable too big. So, what should I do? Lindens, how are you building the latest viewer on MacOS? Alissa Sabre P.S., I'm still using MacOS 10.4 and Xcode 2.5. I'm also wondering newer MacOS/Xcode automatically solve this... -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From soft at lindenlab.com Sat Mar 28 21:30:28 2009 From: soft at lindenlab.com (Soft) Date: Sat, 28 Mar 2009 23:30:28 -0500 Subject: [sldev] tunk viewer build fails on MacOS In-Reply-To: <1kwz8zwwok5GJPGee.alissa_sabre@yahoo.co.jp> References: <1kwz8zwwok5GJPGee.alissa_sabre@yahoo.co.jp> Message-ID: On Sat, Mar 28, 2009 at 10:43 PM, Alissa Sabre wrote: > I'm wondering I should file this on JIRA, or I can get a quick > solution on this list. > > I grabbed the SL viewer source from public svn trunk (r1928) and tried > to build. ?It failed. > > The error I got was: > > ld: can't vm_allocate() buffer for output file of size 1130223472 ((os/kern) no space available) > > I searched the Internet and found that MacOS (Xcode) ld has a limit of > 1GB on any output file, and the above message means output from ld was > literary GIGAntic (i.e., exceeded 1GB). ?Unfortunately, I could find > any solution to it, except "stop staying 32 bit and go 64 bit > development." > > However, as you all know, SL program itself is around 50MB in size. > It should easily fit in 32 bit space. ?It is debugging information > that makes the resulting executable too big. > > So, what should I do? ?Lindens, how are you building the latest viewer > on MacOS? > > ? ?Alissa Sabre > > P.S., I'm still using MacOS 10.4 and Xcode 2.5. ?I'm also wondering > newer MacOS/Xcode automatically solve this... An OS/compiler issue is likely. We're all on 10.5 and Xcode 3.1.2 at the Lab. trunk/ is building just fine on Parabuild. I'm only a few small commits away from head, and my trunk/ build is fine as well. That said, it would be nice to still be backward compatible. If it is an issue with Tiger or 2.5, we can take in a fix. Anyone have an idea of what could be going on here, without resorting to chopping through trunk version builds? From sllists at boroon.dasgupta.ch Sun Mar 29 04:39:25 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 29 Mar 2009 13:39:25 +0200 Subject: [sldev] [IDEA] SL as window manager (was: Added streaming info for Linux, Windows/Mac version needed) In-Reply-To: <17C87F67-7BEE-4316-815C-B000ABCE99AA@gmail.com> References: <200903261821.16410.dale@daleglass.net> <77c421f00903261308i190e12b9mf666491539ad54f0@mail.gmail.com> <200903271522.16515.dale@daleglass.net> <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> <17C87F67-7BEE-4316-815C-B000ABCE99AA@gmail.com> Message-ID: <49CF5DED.2060006@boroon.dasgupta.ch> Argent Stonecutter schrieb: > Alternatively, being able to map programs outside SL onto some > equivalent of media textures IN SL would be nice. Trivial in X11 (make > SL your window manager :) ) That'd be fun anyway. I already thought about trying to make a GTK+ theme in the style of the SL GUI, but having local programs run "within" SL would be way cooler. Bonus points if one can dynamically switch between display in floaters and on prims and choose whether/what to share with others. Just don't transform Thunderbird's toaster-notifications into blue SL pop-ups :-P ... dreams Boroondas From rgwells at techno-logix.com Sun Mar 29 08:33:25 2009 From: rgwells at techno-logix.com (Russell G. Wells) Date: Sun, 29 Mar 2009 08:33:25 -0700 Subject: [sldev] "easybuild" branch, courtesy Kitware In-Reply-To: <49CE6F50.40206@gmail.com> References: <49CD4C49.5080805@lindenlab.com> <200903281324.48869.lists.secondlife.com@trap.wereanimal.net> <49CE6F50.40206@gmail.com> Message-ID: <200903290833.26028.rgwells@techno-logix.com> (this is not really on topic but....) Not all distributions support 32bit version of all the libraries needed. I have 64bit versions of OpenSuse 11.0 and Kubuntu 8.04 installed and i have had to manually install different 32 bit version of libraries on each system to resolve the dependencies of the second life viewer and SLVoice. Even after getting all the 32 bit libraries in place, I still can't hear or use the voice feature. What I getting at is that linux systems have a huge variety of options and differences that can be difficult to manage. Having said that, getting everything consolidated under an "easybuild" using cmake is a great idea, but should include EVERY component possible. Russell G. Wells On Saturday 28 March 2009 11:41:20 Glen wrote: > Yeah, it works right now. I use the ia32 stuff to run the production > client. Wish I didn't have to. > > --GC > > lists.secondlife.com at trap.wereanimal.net wrote: > > On Saturday 28 March 2009 10:40:09 am Glen wrote: > >> When do they expect to have it done again? I'm eager to try it. > >> > >> Do they plan to have the OSS libraries auto-download as source, with the > >> closed ones downloaded per architecture? 64-bit closed libraries is kind > >> of important I think, since if we can't build them ourselves we'll at > >> least need them for the right architecture. Vivox comes to mind - I > >> don't want to lose something that's working now. > >> > >> Questions abound. > >> > >> --GC > > > > I've discovered that the 32 bit vivox binary will work with a 64 bit > > build of the SL client. What needed to be done was to make sure it was > > installed in the right place. SLvoice in bin/ and the lib in lib/. Only > > other requirement was the 32-bit emulation libs. Most distros have these > > available in there package management system. > > > > --Techwolf Lupindo > > _______________________________________________ > > 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 alissa_sabre at yahoo.co.jp Sun Mar 29 08:48:11 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon, 30 Mar 2009 00:48:11 +0900 Subject: [sldev] [VWR, LINUX] How to compile "Debug" and "Release" viewers? In-Reply-To: <49C9835E.6000209@gmail.com> References: <49C9835E.6000209@gmail.com> Message-ID: <7ws0eeeauJQdY4ds7ms96odf.alissa_sabre@yahoo.co.jp> Jason: > What I do is edit the makefile and change the strip command to cp. > Crude, I know, but it works and is easy to change back. > > The unstripped "release" binary has all the debug info you need. Regardless of the build type (Release/RelWithDebInfo/Debug), after building the viewer, a file of name "secondlife-bin" is left in the build directory. It is an unstripped version of the executable with full debug info. When you want to debug the program, you can run it directly, you can overwrite the stripped version do-not-directly-run-secondlife-bin with it, or you can instruct gdb to read debug info from secondlife-bin (with symbol-file command) while running the stripped version of the executable. Opensource Obscure: > > Surely I'm doing it wrong, because both the "Debug" and the > > "Release" binaries I made have nearly the same size, > > and they provide similar logs. Hmm. Release and Debug binaries should have very different sizes. In my case, the resulting do-not-directly-run-secondlife-bin have 35MB when Release and 54MB when Debug. I need to agree that you have done it in a wrong way. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From kf6kjg at gmail.com Sun Mar 29 09:47:05 2009 From: kf6kjg at gmail.com (Ricky) Date: Sun, 29 Mar 2009 09:47:05 -0700 Subject: [sldev] Added streaming info for Linux, Windows/Mac version needed In-Reply-To: <200903280034.31902.dale@daleglass.net> References: <200903261821.16410.dale@daleglass.net> <200903271522.16515.dale@daleglass.net> <3bb9647e0903271455y23486994o5e0ec13c6187b082@mail.gmail.com> <200903280034.31902.dale@daleglass.net> Message-ID: <3bb9647e0903290947q6a80e9fao7d82673b08bc7754@mail.gmail.com> Ok. Maybe then using another external dependency, like libVLC http://wiki.videolan.org/Libvlc , would allow us to incorporate a fully-cross platform media player that can be set up to do whatever the user wished: Play parcel media with a default stream or file list for when there is none, do cross-fading between streams, etc. This could possibly even take over the gstreamer/etc dependency, but I'm not sure. This way we don't have to write mediaplayer functionality ourselves, we just leverage an existing GPL'd application designed to do the task, and all we have to do is implement the UI side to integrate it into the viewer along with whatever else we want to make things tick the way we like... Ricky aka Cron Stardust On Fri, Mar 27, 2009 at 4:34 PM, Dale Glass wrote: > On ??????? 27 ????? 2009 22:55:42 Ricky wrote: > > Well, if the user wanted background music... They could just load up > > their favorite media player. > > > > Yet I understand that playing a stream in-viewer which can be > > interrupted by parcel music would have a cleaner interface. No dual > > streams for instance. But then, are we adding too much? Does the SL > > viewer also need to be a media player? After all, the next logical step > > from user-configurable default streams is user playlists and files... > > VLC does all that for me quite nicely... > Well, I am not sure how many people will agree with me on this, but I think > that SL, as a "virtual world" should be complete enough that you don't need > to get out of it. Especially, if you can play music, then it should work > well enough that you don't need an external player. > > I don't think a full blown media player is needed, but in RL, if I don't > like what's on TV in a bar I can pull out my own player. I think SL could > use an equivalent of that. > > Also, I think this would make things in SL better. I notice that most > people use an external player. This is mostly because they don't like the > current stream or there isn't any. But then they may not find out when > something interesting does start playing. > > > However... Maybe the viewer could export a file, or server port, that > > was a copy of the stream from the current parcel media server? This way > > I could point my favorite media player at that location and have it > > handle the selecting another track when the stream stops. > Hmm, I'd prefer something else: Have the possibility of using a LSL HUD to > command the viewer to perform streaming tasks. Then I could have my "slpod" > attached and use it to override the parcel stream if I want. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090329/adbd03ca/attachment.htm From hawk.carter at unix-dev.de Sun Mar 29 10:07:46 2009 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Sun, 29 Mar 2009 19:07:46 +0200 Subject: [sldev] Render-Pipeline broken for today ? Message-ID: Hello all, i compiled the Render-Pipeline with many Linkwarnings...but it compiled without errors, but if i try to start the Viewer these error came up in secondlife.log : 2009-03-29T13:20:48Z WARNING: LLVOAvatarBoneInfo::parseXml: Bone without position 2009-03-29T13:20:48Z WARNING: LLVOAvatarSkeletonInfo::parseXml: Error parsing bone in skeleton file 2009-03-29T13:20:48Z ../../newview/llvoavatar.cpp(1401) : error 2009-03-29T13:20:48Z ERROR: LLVOAvatar::initClass: Error parsing skeleton XML file: C:\Lindentest2\character\avatar_skeleton.xml Somebody a idea ? Greetings Hawk Carter Here are the Linkwarnings : Linking... Creating library C:\linden2\indra\build-VC80\newview\Release\secondlife-bin.lib and object C:\linden2\indra\build-VC80\newview\Release\secondlife-bin.exp xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_ParserFree imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_ErrorString imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentByteCount imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentByteIndex imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentColumnNumber imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentLineNumber imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetErrorCode imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_Parse imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_SetUserData imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_SetCharacterDataHandler imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_SetElementHandler imported in function _xml_elem_parse_buf xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_ParserCreate imported in function _xml_elem_parse_buf freetype.lib(autohint.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info freetype.lib(bdf.obj) : warning LNK4099: PDB 'vc80_ib_2.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_2.pdb'; linking object as if no debug info freetype.lib(cff.obj) : warning LNK4099: PDB 'vc80_ib_3.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_3.pdb'; linking object as if no debug info freetype.lib(ftbase.obj) : warning LNK4099: PDB 'vc80_ib_4.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_4.pdb'; linking object as if no debug info freetype.lib(ftglyph.obj) : warning LNK4099: PDB 'vc80_ib_7.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_7.pdb'; linking object as if no debug info freetype.lib(ftgzip.obj) : warning LNK4099: PDB 'vc80_ib_8.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_8.pdb'; linking object as if no debug info freetype.lib(ftinit.obj) : warning LNK4099: PDB 'vc80_ib_6.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_6.pdb'; linking object as if no debug info freetype.lib(ftsystem.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info freetype.lib(pcf.obj) : warning LNK4099: PDB 'vc80_ib_2.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_2.pdb'; linking object as if no debug info freetype.lib(pfr.obj) : warning LNK4099: PDB 'vc80_ib_5.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_5.pdb'; linking object as if no debug info freetype.lib(psaux.obj) : warning LNK4099: PDB 'vc80_ib_7.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_7.pdb'; linking object as if no debug info freetype.lib(pshinter.obj) : warning LNK4099: PDB 'vc80_ib_8.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_8.pdb'; linking object as if no debug info freetype.lib(psmodule.obj) : warning LNK4099: PDB 'vc80_ib_3.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_3.pdb'; linking object as if no debug info freetype.lib(raster.obj) : warning LNK4099: PDB 'vc80_ib_4.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_4.pdb'; linking object as if no debug info freetype.lib(sfnt.obj) : warning LNK4099: PDB 'vc80_ib_6.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_6.pdb'; linking object as if no debug info freetype.lib(smooth.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info freetype.lib(truetype.obj) : warning LNK4099: PDB 'vc80_ib_7.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_7.pdb'; linking object as if no debug info freetype.lib(type1.obj) : warning LNK4099: PDB 'vc80_ib_8.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_8.pdb'; linking object as if no debug info freetype.lib(type1cid.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info freetype.lib(type42.obj) : warning LNK4099: PDB 'vc80_ib_2.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_2.pdb'; linking object as if no debug info freetype.lib(winfnt.obj) : warning LNK4099: PDB 'vc80_ib_5.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\freetype.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_5.pdb'; linking object as if no debug info libndofdev.lib(ndofdev.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\libndofdev.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info libndofdev.lib(ndofdev_win.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\libndofdev.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info llmozlib2-vc80.lib(llembeddedbrowser.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\llmozlib2-vc80.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info llmozlib2-vc80.lib(llembeddedbrowserwindow.obj) : warning LNK4099: PDB 'vc80_ib_2.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\llmozlib2-vc80.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_2.pdb'; linking object as if no debug info llmozlib2-vc80.lib(llmozlib2.obj) : warning LNK4099: PDB 'vc80_ib_1.pdb' was not found with 'C:\linden2\libraries\i686-win32\lib\release\llmozlib2-vc80.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\vc80_ib_1.pdb'; linking object as if no debug info aprutil-1.lib(apr_base64.obj) : warning LNK4099: PDB 'aprutil-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\aprutil-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\aprutil-1_ib_1.pdb'; linking object as if no debug info apr-1.lib(apr_atomic.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib(dso.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_2.pdb'; linking object as if no debug info apr-1.lib(dir.obj) : warning LNK4099: PDB 'apr-1_ib_4.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_4.pdb'; linking object as if no debug info apr-1.lib(filedup.obj) : warning LNK4099: PDB 'apr-1_ib_6.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_6.pdb'; linking object as if no debug info apr-1.lib(filepath.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_7.pdb'; linking object as if no debug info apr-1.lib(filepath_util.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_8.pdb'; linking object as if no debug info apr-1.lib(filestat.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_9.pdb'; linking object as if no debug info apr-1.lib(filesys.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_10.pdb'; linking object as if no debug info apr-1.lib(flock.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib(fullrw.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_11.pdb'; linking object as if no debug info apr-1.lib(open.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_7.pdb'; linking object as if no debug info apr-1.lib(pipe.obj) : warning LNK4099: PDB 'apr-1_ib_4.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_4.pdb'; linking object as if no debug info apr-1.lib(readwrite.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib(seek.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_2.pdb'; linking object as if no debug info apr-1.lib(thread_cond.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_2.pdb'; linking object as if no debug info apr-1.lib(thread_mutex.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_3.pdb'; linking object as if no debug info apr-1.lib(apr_pools.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_10.pdb'; linking object as if no debug info apr-1.lib(env.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_7.pdb'; linking object as if no debug info apr-1.lib(errorcodes.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_9.pdb'; linking object as if no debug info apr-1.lib(internal.obj) : warning LNK4099: PDB 'apr-1_ib_6.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_6.pdb'; linking object as if no debug info apr-1.lib(misc.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_2.pdb'; linking object as if no debug info apr-1.lib(start.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_8.pdb'; linking object as if no debug info apr-1.lib(utf8.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib(inet_ntop.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_10.pdb'; linking object as if no debug info apr-1.lib(inet_pton.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_3.pdb'; linking object as if no debug info apr-1.lib(sendrecv.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_9.pdb'; linking object as if no debug info apr-1.lib(sockaddr.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_2.pdb'; linking object as if no debug info apr-1.lib(sockets.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_7.pdb'; linking object as if no debug info apr-1.lib(sockopt.obj) : warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib(select.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_8.pdb'; linking object as if no debug info apr-1.lib(apr_cpystrn.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_10.pdb'; linking object as if no debug info apr-1.lib(apr_snprintf.obj) : warning LNK4099: PDB 'apr-1_ib_2.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_2.pdb'; linking object as if no debug info apr-1.lib(apr_strings.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_3.pdb'; linking object as if no debug info apr-1.lib(apr_strtok.obj) : warning LNK4099: PDB 'apr-1_ib_8.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_8.pdb'; linking object as if no debug info apr-1.lib(apr_hash.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_9.pdb'; linking object as if no debug info apr-1.lib(apr_tables.obj) : warning LNK4099: PDB 'apr-1_ib_7.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_7.pdb'; linking object as if no debug info apr-1.lib(proc.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_11.pdb'; linking object as if no debug info apr-1.lib(signals.obj) : warning LNK4099: PDB 'apr-1_ib_9.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_9.pdb'; linking object as if no debug info apr-1.lib(thread.obj) : warning LNK4099: PDB 'apr-1_ib_3.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_3.pdb'; linking object as if no debug info apr-1.lib(time.obj) : warning LNK4099: PDB 'apr-1_ib_10.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\linden2\indra\build-VC80\newview\Release\apr-1_ib_10.pdb'; linking object as if no debug info Embedding manifest... From sllists at boroon.dasgupta.ch Sun Mar 29 10:22:58 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 29 Mar 2009 19:22:58 +0200 Subject: [sldev] Render-Pipeline broken for today ? In-Reply-To: References: Message-ID: <49CFAE72.6090209@boroon.dasgupta.ch> Hawk Carter schrieb: > 2009-03-29T13:20:48Z WARNING: LLVOAvatarBoneInfo::parseXml: Bone without > position > Might be the old locale handling issue popping up once again: http://www.google.com/cse?cx=001010425210852223575%3Aogwhgz5_tue&ie=UTF-8&q=Bone+without++position&sa=Search Can you try to run it with LANG="C" ./secondlife instead of just ./secondlife and see if the error still occurs? If not, it's quite probably the same issue. (Doesn't need to be the same piece of code which is broken, though.) cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090329/fb4553b8/attachment.htm From sllists at boroon.dasgupta.ch Sun Mar 29 10:30:27 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 29 Mar 2009 19:30:27 +0200 Subject: [sldev] Render-Pipeline broken for today ? In-Reply-To: <49CFAE72.6090209@boroon.dasgupta.ch> References: <49CFAE72.6090209@boroon.dasgupta.ch> Message-ID: <49CFB033.9080606@boroon.dasgupta.ch> Boroondas Gupte schrieb: > Hawk Carter schrieb: >> 2009-03-29T13:20:48Z WARNING: LLVOAvatarBoneInfo::parseXml: Bone without >> position >> > Might be the old locale handling issue popping up once again: > http://www.google.com/cse?cx=001010425210852223575%3Aogwhgz5_tue&ie=UTF-8&q=Bone+without++position&sa=Search Um ... wait, no ... Guess my reaction was too Pavlovian ... That was an issue on the unix-like systems, not Windows. Boroondas From hawk.carter at unix-dev.de Sun Mar 29 10:32:46 2009 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Sun, 29 Mar 2009 19:32:46 +0200 Subject: [sldev] Render-Pipeline broken for today ? References: <49CFAE72.6090209@boroon.dasgupta.ch> <49CFB033.9080606@boroon.dasgupta.ch> Message-ID: <103482DBA70D44D7871A0562F6BDB495@nomo> ----- Original Message ----- From: "Boroondas Gupte" Maybe, but i'm using WinXP german VCExpress 2005 english So i'm not really sure how to get rid of it on Windows. :) Greetings Hawk > Boroondas Gupte schrieb: >> Hawk Carter schrieb: >>> 2009-03-29T13:20:48Z WARNING: LLVOAvatarBoneInfo::parseXml: Bone without >>> position >>> >> Might be the old locale handling issue popping up once again: >> http://www.google.com/cse?cx=001010425210852223575%3Aogwhgz5_tue&ie=UTF-8&q=Bone+without++position&sa=Search > Um ... wait, no ... Guess my reaction was too Pavlovian ... That was an > issue on the unix-like systems, not Windows. > > Boroondas > From alissa_sabre at yahoo.co.jp Mon Mar 30 08:04:29 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue, 31 Mar 2009 00:04:29 +0900 Subject: [sldev] Render-Pipeline broken for today ? In-Reply-To: <103482DBA70D44D7871A0562F6BDB495@nomo> References: <103482DBA70D44D7871A0562F6BDB495@nomo> Message-ID: <74ds6f24ducet4ds40wQ8.alissa_sabre@yahoo.co.jp> Hawk, > >>> 2009-03-29T13:20:48Z WARNING: LLVOAvatarBoneInfo::parseXml: Bone without > >>> position > >> Might be the old locale handling issue popping up once again: > > Um ... wait, no ... Guess my reaction was too Pavlovian ... That was an > > issue on the unix-like systems, not Windows. It was a Linux-only issue, since the problematic calls to setlocale() was in a GTK API that Linux version of llmozlib depended. On Windows, llmozlib didn't use GTK and setlocale() was never called, then. However, the direct cause of the problem was the decimal point character (i.e., a comma or a period) of the locale. GTK was just a trigger. Careless calls to setlocale() could lead to the same behaviour on any platform. > WinXP german > VCExpress 2005 english Hmm, German Windows... So, your default decimal bpoint character is a comma, right? It is very suspicious. Can you test your viewer under a setting that decimal point be a period? You can chnge your Windows setting as follows: - Open Windows' Control Panel. - Choose Regional and Language Options. - On Regional Options tab, in Standards and formats, Choose "English (United States)" or click on Customize and adjust "Decimal symbol" and "Digit grouping symbol" on the Numbers tab. - Click OK. Please report back to the list, regardless it made your viewer to run or it made no difference at all. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From missannotoole at yahoo.com Mon Mar 30 12:40:55 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Mon, 30 Mar 2009 12:40:55 -0700 (PDT) Subject: [sldev] Check the blog In-Reply-To: <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <200903281548.18090.dale@daleglass.net> <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> Message-ID: <357831.444.qm@web59106.mail.re1.yahoo.com> Phillip has made a very interesting blog post. Might want to check it out! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090330/5aed7ad0/attachment.htm From ordinal.malaprop at fastmail.fm Mon Mar 30 13:09:15 2009 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop at fastmail.fm) Date: Mon, 30 Mar 2009 21:09:15 +0100 Subject: [sldev] Check the blog In-Reply-To: <357831.444.qm@web59106.mail.re1.yahoo.com> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <200903281548.18090.dale@daleglass.net> <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> <357831.444.qm@web59106.mail.re1.yahoo.com> Message-ID: <03C665A6-C4BA-4051-A1AD-D22DDD408825@fastmail.fm> Er, has he? Where? On 30 Mar 2009, at 20:40, Ann Otoole wrote: > Phillip has made a very interesting blog post. Might want to check > it out! > > _______________________________________________ > 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 evolutie at gmail.com Mon Mar 30 13:18:48 2009 From: evolutie at gmail.com (evolutie) Date: Mon, 30 Mar 2009 22:18:48 +0200 Subject: [sldev] Check the blog In-Reply-To: <03C665A6-C4BA-4051-A1AD-D22DDD408825@fastmail.fm> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <200903281548.18090.dale@daleglass.net> <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> <357831.444.qm@web59106.mail.re1.yahoo.com> <03C665A6-C4BA-4051-A1AD-D22DDD408825@fastmail.fm> Message-ID: <5fb4b1fa0903301318j51a9eca8k9da6b58cc484d8eb@mail.gmail.com> https://blogs.secondlife.com/community/features/blog/2009/03/30/intensifying-open-source-efforts On Mon, Mar 30, 2009 at 10:09 PM, wrote: > Er, has he? Where? > > On 30 Mar 2009, at 20:40, Ann Otoole wrote: > >> Phillip has made a very interesting blog post. Might want to check >> it out! >> >> _______________________________________________ >> 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 > -- http://www.creativemachinery.org From jessesa at gmail.com Mon Mar 30 13:19:15 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Mon, 30 Mar 2009 16:19:15 -0400 Subject: [sldev] Check the blog In-Reply-To: <03C665A6-C4BA-4051-A1AD-D22DDD408825@fastmail.fm> References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <200903281548.18090.dale@daleglass.net> <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> <357831.444.qm@web59106.mail.re1.yahoo.com> <03C665A6-C4BA-4051-A1AD-D22DDD408825@fastmail.fm> Message-ID: https://blogs.secondlife.com/community/features/blog/2009/03/30/intensifying-open-source-efforts On Mon, Mar 30, 2009 at 4:09 PM, wrote: > Er, has he? Where? > > On 30 Mar 2009, at 20:40, Ann Otoole wrote: > > > Phillip has made a very interesting blog post. Might want to check > > it out! > > > > _______________________________________________ > > 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/20090330/07ef3a9e/attachment.htm From tigrospottystripes at gmail.com Mon Mar 30 13:43:57 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 30 Mar 2009 17:43:57 -0300 Subject: [sldev] Check the blog In-Reply-To: References: <49CD4C49.5080805@lindenlab.com> <4ebfc1100903280444g13388ec6jf6366fdbab059da5@mail.gmail.com> <200903281548.18090.dale@daleglass.net> <4ebfc1100903280904l47a11eaq511df659f821dfa6@mail.gmail.com> <357831.444.qm@web59106.mail.re1.yahoo.com> <03C665A6-C4BA-4051-A1AD-D22DDD408825@fastmail.fm> Message-ID: <49D12F0D.7010104@Gmail.com> seems the post was moved, now it is located at https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Jesse Barnett escreveu: > https://blogs.secondlife.com/community/features/blog/2009/03/30/intensifying-open-source-efforts > > On Mon, Mar 30, 2009 at 4:09 PM, > wrote: > > Er, has he? Where? > > On 30 Mar 2009, at 20:40, Ann Otoole wrote: > > > Phillip has made a very interesting blog post. Might want to check > > it out! > > > > _______________________________________________ > > 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 hawk.carter at unix-dev.de Mon Mar 30 17:02:35 2009 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Tue, 31 Mar 2009 02:02:35 +0200 Subject: [sldev] VC++ 2005 Express Users Message-ID: <49D15D9B.5030303@unix-dev.de> On March 31th MS VC++ Express Edition will be discontinued and removed from http://www.microsoft.com/express. Maybe thats a important Message to all who are using this IDE. Hawk Carter. From tom at streamsense.net Mon Mar 30 17:05:26 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue, 31 Mar 2009 01:05:26 +0100 Subject: [sldev] VC++ 2005 Express Users In-Reply-To: <49D15D9B.5030303@unix-dev.de> References: <49D15D9B.5030303@unix-dev.de> Message-ID: <49D15E46.6070002@streamsense.net> Wow, okay.. I think this means that we really need some love at https://jira.secondlife.com/browse/VWR-9541 (Boost Hell!) and to push for VS2008 support round the board. I maintain a viewer which has been patched to support VS2008, so i'll submit the appropriately modified files to the jira in just a moment, /but/ i will need someone to test to make sure the build can still be completed on VS2005 once the modification has been made? ~T Hawk Carter wrote: > On March 31th MS VC++ Express Edition will be discontinued and removed > from http://www.microsoft.com/express. > > Maybe thats a important Message to all who are using this IDE. > > > Hawk Carter. > > _______________________________________________ > 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 hawk.carter at unix-dev.de Mon Mar 30 17:11:50 2009 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Tue, 31 Mar 2009 02:11:50 +0200 Subject: [sldev] Render-Pipeline broken for today ? In-Reply-To: <74ds6f24ducet4ds40wQ8.alissa_sabre@yahoo.co.jp> References: <103482DBA70D44D7871A0562F6BDB495@nomo> <74ds6f24ducet4ds40wQ8.alissa_sabre@yahoo.co.jp> Message-ID: <49D15FC6.70003@unix-dev.de> Alissa Sabre schrieb: Just a change in the source worked allmostly well (Client logged in, but crashed at Appereance, and Colors of the Login was like a negative.) http://jira.secondlife.com/browse/VWR-12161 >> WinXP german >> VCExpress 2005 english >> > > Hmm, German Windows... So, your default decimal bpoint character is a > comma, right? It is very suspicious. Can you test your viewer under > a setting that decimal point be a period? You can chnge your > Windows setting as follows: > > - Open Windows' Control Panel. > - Choose Regional and Language Options. > - On Regional Options tab, in Standards and formats, Choose "English > (United States)" or click on Customize and adjust "Decimal symbol" > and "Digit grouping symbol" on the Numbers tab. > - Click OK. > > Please report back to the list, regardless it made your viewer to run > or it made no difference at all. > > Alissa Sabre > > From dale at daleglass.net Mon Mar 30 17:20:25 2009 From: dale at daleglass.net (Dale Glass) Date: Tue, 31 Mar 2009 02:20:25 +0200 Subject: [sldev] VC++ 2005 Express Users In-Reply-To: <49D15D9B.5030303@unix-dev.de> References: <49D15D9B.5030303@unix-dev.de> Message-ID: <200903310220.32160.dale@daleglass.net> On ??????? 31 ????? 2009 02:02:35 Hawk Carter wrote: > On March 31th MS VC++ Express Edition will be discontinued and removed > from http://www.microsoft.com/express. > > Maybe thats a important Message to all who are using this IDE. Wow, I didn't know about that. Fortunately MS has .iso images here: http://www.microsoft.com/express/2005/download/offline.aspx I'm downloading it right now, in case I need to reinstall things before the 2008 issues are sorted out. -------------- 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/20090331/bc9c9f0c/attachment.pgp From robla at lindenlab.com Mon Mar 30 17:23:55 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 30 Mar 2009 17:23:55 -0700 Subject: [sldev] Code review for those of you with commit access Message-ID: <49D1629B.1030500@lindenlab.com> Hi folks, As you probably saw in Philip's blog post (which if you haven't read it, do so[1]), we're going to be doing a lot more development out in the fishbowl, in a branch with community members who have direct commit access. There's a few of you that already have commit access, and others that I imagine will be asking for it. Here's the procedure we'd like to follow for commits for new committers to the http-texture: * File the patch in JIRA if it isn't already there * Mail sldev with a link to the JIRA issue, and noting you'd like to commit the patch * Nag me in a couple of days if we haven't responded * Assuming you get the nod, commit the change This isn't set in stone....there's a number of aspects about this process I'm going to guess we haven't thought of. We want to be nimble, but we also want to make sure there's lots of eyeballs on every commit. More info can be found here: https://wiki.secondlife.com/wiki/HTTP_Texture_Development Comments welcome. Rob [1] Philip's blog post: https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts From soft at lindenlab.com Mon Mar 30 17:29:58 2009 From: soft at lindenlab.com (Soft) Date: Mon, 30 Mar 2009 19:29:58 -0500 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D1629B.1030500@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> Message-ID: On Mon, Mar 30, 2009 at 7:23 PM, Rob Lanphier wrote: > Hi folks, > > As you probably saw in Philip's blog post (which if you haven't read it, > do so[1]), we're going to be doing a lot more development out in the > fishbowl, in a branch with community members who have direct commit access. > > There's a few of you that already have commit access, and others that I > imagine will be asking for it. ?Here's the procedure we'd like to follow > for commits for new committers to the http-texture: > > * ?File the patch in JIRA if it isn't already there > * ?Mail sldev with a link to the JIRA issue, and noting you'd like to > commit the patch > * ?Nag me in a couple of days if we haven't responded > * ?Assuming you get the nod, commit the change > > This isn't set in stone....there's a number of aspects about this > process I'm going to guess we haven't thought of. ?We want to be nimble, > but we also want to make sure there's lots of eyeballs on every commit. And if you do see a patch linked on sldev - assume it's going to land in the branch unless you find a problem with it. Silence is consent, so follow up on-list with any concerns. Community review is the whole point of posting links. From GordonWendt at gmail.com Mon Mar 30 18:36:21 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 30 Mar 2009 21:36:21 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D1629B.1030500@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> Message-ID: <493033a70903301836v12e974c5p99fcd8eb93763875@mail.gmail.com> I don't know where/if the info is but just a suggestion, it may be useful to link the info page on the wiki (as well as any other documentation pages) to the guidelines and steps to get commit access in the first place since the instructions seem to assume that person already has or knows how to get commit access. -Gordon On Mon, Mar 30, 2009 at 8:23 PM, Rob Lanphier wrote: > Hi folks, > > As you probably saw in Philip's blog post (which if you haven't read it, > do so[1]), we're going to be doing a lot more development out in the > fishbowl, in a branch with community members who have direct commit access. > > There's a few of you that already have commit access, and others that I > imagine will be asking for it. Here's the procedure we'd like to follow > for commits for new committers to the http-texture: > > * File the patch in JIRA if it isn't already there > * Mail sldev with a link to the JIRA issue, and noting you'd like to > commit the patch > * Nag me in a couple of days if we haven't responded > * Assuming you get the nod, commit the change > > This isn't set in stone....there's a number of aspects about this > process I'm going to guess we haven't thought of. We want to be nimble, > but we also want to make sure there's lots of eyeballs on every commit. > > More info can be found here: > https://wiki.secondlife.com/wiki/HTTP_Texture_Development > > Comments welcome. > > Rob > > [1] Philip's blog post: > > https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts > > _______________________________________________ > 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/20090330/1c98d4aa/attachment.htm From GordonWendt at gmail.com Mon Mar 30 18:38:41 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 30 Mar 2009 21:38:41 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <493033a70903301836v12e974c5p99fcd8eb93763875@mail.gmail.com> References: <49D1629B.1030500@lindenlab.com> <493033a70903301836v12e974c5p99fcd8eb93763875@mail.gmail.com> Message-ID: <493033a70903301838s5952f722pcdf6d8223a1639b2@mail.gmail.com> Addendum to my previous posting, Found some info at http://wiki.secondlife.com/wiki/Version_control_repository#Write_access on getting write access but that's sparse at best and I don't know enough about the process to feel comfortable writing up a new set of instructions. -Gordon On Mon, Mar 30, 2009 at 9:36 PM, Gordon Wendt wrote: > I don't know where/if the info is but just a suggestion, it may be useful > to link the info page on the wiki (as well as any other documentation pages) > to the guidelines and steps to get commit access in the first place since > the instructions seem to assume that person already has or knows how to get > commit access. > > -Gordon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090330/a66a7f40/attachment.htm From philip at lindenlab.com Mon Mar 30 20:22:56 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Mon, 30 Mar 2009 20:22:56 -0700 Subject: [sldev] Code review for those of you with commit access In-Reply-To: References: <49D1629B.1030500@lindenlab.com> Message-ID: <49D18C90.3020400@lindenlab.com> Very cool to see this all starting! From my perspective, the most important thing to communicate is that if you are a committer, you now bear the responsibility of checking in only high quality, well tested, sensible work. Solid design, development, and QA is ultimately the final responsibility of the person who hits the enter key and checks in code. Do not count on LL (or anyone else) to do that work for you. P Soft wrote: > On Mon, Mar 30, 2009 at 7:23 PM, Rob Lanphier wrote: > >> Hi folks, >> >> As you probably saw in Philip's blog post (which if you haven't read it, >> do so[1]), we're going to be doing a lot more development out in the >> fishbowl, in a branch with community members who have direct commit access. >> >> There's a few of you that already have commit access, and others that I >> imagine will be asking for it. Here's the procedure we'd like to follow >> for commits for new committers to the http-texture: >> >> * File the patch in JIRA if it isn't already there >> * Mail sldev with a link to the JIRA issue, and noting you'd like to >> commit the patch >> * Nag me in a couple of days if we haven't responded >> * Assuming you get the nod, commit the change >> >> This isn't set in stone....there's a number of aspects about this >> process I'm going to guess we haven't thought of. We want to be nimble, >> but we also want to make sure there's lots of eyeballs on every commit. >> > > And if you do see a patch linked on sldev - assume it's going to land > in the branch unless you find a problem with it. Silence is consent, > so follow up on-list with any concerns. Community review is the whole > point of posting links. > _______________________________________________ > 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/20090330/956b5a4b/attachment.htm From bogus@does.not.exist.com Tue Mar 10 20:13:32 2009 From: bogus@does.not.exist.com () Date: Wed, 11 Mar 2009 03:13:32 -0000 Subject: No subject Message-ID: you are a committer, you now bear the responsibility of checking in only high quality, well tested, sensible work.   Solid design, development, and QA is ultimately the final responsibility of the person who hits the enter key and checks in code.   Do not count on LL (or anyone else) to do that work for you. 

P

Soft wrote: 
On Mon, Mar 30, 2009 at 7:23 PM, Rob Lanphier <robla at lindenlab.com> wrote:
  
Hi folks,

As you probably saw in Philip's blog post (which if you haven't read it,
do so[1]), we're going to be doing a lot more development out in the
fishbowl, in a branch with community members who have direct commit access.

There's a few of you that already have commit access, and others that I
imagine will be asking for it.  Here's the procedure we'd like to follow
for commits for new committers to the http-texture:

*  File the patch in JIRA if it isn't already there
*  Mail sldev with a link to the JIRA issue, and noting you'd like to
commit the patch
*  Nag me in a couple of days if we haven't responded
*  Assuming you get the nod, commit the change

This isn't set in stone....there's a number of aspects about this
process I'm going to guess we haven't thought of.  We want to be nimble,
but we also want to make sure there's lots of eyeballs on every commit.
    

And if you do see a patch linked on sldev - assume it's going to land
in the branch unless you find a problem with it. Silence is consent,
so follow up on-list with any concerns. Community review is the whole
point of posting links.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
--------------080404050501050302080605-- From GordonWendt at gmail.com Mon Mar 30 23:03:20 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue, 31 Mar 2009 02:03:20 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D18C90.3020400@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> <49D18C90.3020400@lindenlab.com> Message-ID: <493033a70903302303v32b99e08yfaa5f9e003d51d46@mail.gmail.com> I'm excited about it Phillip and after going almost insane last time I tried going through the codebase that means a lot. I'm not saying that I'll know enough to start coding and patching and submitting anytime soon but if this inspires more people to learn the code and join the effort and it makes it easier for those already doing open source coding then it's good progress. -Gordon On Mon, Mar 30, 2009 at 11:22 PM, Philip Rosedale wrote: > Very cool to see this all starting! > > From my perspective, the most important thing to communicate is that if you > are a committer, you now bear the responsibility of checking in only high > quality, well tested, sensible work. Solid design, development, and QA is > ultimately the final responsibility of the person who hits the enter key and > checks in code. Do not count on LL (or anyone else) to do that work for > you. > > P > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090331/3dbdf244/attachment.htm From bogus@does.not.exist.com Tue Mar 10 20:13:32 2009 From: bogus@does.not.exist.com () Date: Wed, 11 Mar 2009 03:13:32 -0000 Subject: No subject Message-ID: you are a committer, you now bear the responsibility of checking in only high quality, well tested, sensible work.=A0=A0 Solid design, development, and QA is ultimately the final responsibility of the person who hits the enter key and checks in code.=A0=A0 Do not count on LL (or anyone else) to do that work for you.=A0

P --00163630f2dfe8903e046663f5e8-- From secret.argent at gmail.com Tue Mar 31 04:45:17 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 31 Mar 2009 06:45:17 -0500 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D18C90.3020400@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> <49D18C90.3020400@lindenlab.com> Message-ID: <4D190B9E-219D-4592-974A-9C19A5CC9319@gmail.com> On 2009-03-30, at 22:22, Philip Rosedale wrote: > From my perspective, the most important thing to communicate is that > if you are a committer, you now bear the responsibility of checking > in only high quality, well tested, sensible work. Solid design, > development, and QA is ultimately the final responsibility of the > person who hits the enter key and checks in code. Do not count on > LL (or anyone else) to do that work for you. There still needs to be someone, or some-ones, eyeballing commits (even if after the fact) and doing release tracking and final QA. Open source or not, that's still a necessary role. If Linden Labs isn't going to do that, then we (SLDEV) need to step up to the plate, each of us in the areas we're competent to monitor. From q at lindenlab.com Tue Mar 31 06:47:46 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 31 Mar 2009 09:47:46 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <4D190B9E-219D-4592-974A-9C19A5CC9319@gmail.com> References: <49D1629B.1030500@lindenlab.com><49D18C90.3020400@linden lab.com> <4D190B9E-219D-4592-974A-9C19A5CC9319@gmail.com> Message-ID: <128E1827-99F3-496C-8B37-0219B0ED6A91@lindenlab.com> On Mar 31, 2009, at 7:45 AM, Argent Stonecutter wrote: > On 2009-03-30, at 22:22, Philip Rosedale wrote: >> From my perspective, the most important thing to communicate is that >> if you are a committer, you now bear the responsibility of checking >> in only high quality, well tested, sensible work. Solid design, >> development, and QA is ultimately the final responsibility of the >> person who hits the enter key and checks in code. Do not count on >> LL (or anyone else) to do that work for you. > > There still needs to be someone, or some-ones, eyeballing commits > (even if after the fact) and doing release tracking and final QA. Open > source or not, that's still a necessary role. If Linden Labs isn't > going to do that, then we (SLDEV) need to step up to the plate, each > of us in the areas we're competent to monitor. We (Linden Lab) will definitely still be responsible for the quality of the code that makes it into our releases. But if people aren't doing an adequate job of design, test, and documentation, then it's going to make it a lot harder. Nobody's perfect -- but we're just asking people to think carefully about what they're doing and be professional about it. The bigger the change, the more eyes you should have on it before it goes in. Write test plans and document your intent. In particular, we're pushing internally toward much more extensive unit testing. Once we get some traction and comfort internally, I intend to have a public training session to talk about how we're doing it and how open source devs can help. Watch this space for more news. Q From philip at lindenlab.com Tue Mar 31 07:04:21 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Tue, 31 Mar 2009 07:04:21 -0700 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <128E1827-99F3-496C-8B37-0219B0ED6A91@lindenlab.com> References: <49D1629B.1030500@lindenlab.com><49D18C90.3020400@linden lab.com> <4D190B9E-219D-4592-974A-9C19A5CC9319@gmail.com> <128E1827-99F3-496C-8B37-0219B0ED6A91@lindenlab.com> Message-ID: <49D222E5.7080103@lindenlab.com> I do very much like the idea of folks in dev community also monitoring code and changes in their area, as Argent suggests. Adding unit and automation tests is going to be important, as Q sez. We are working on a test for startup time that can be included in build results - I want to start graphing any changes to that with every build. P Kent Quirk (Q Linden) wrote: > On Mar 31, 2009, at 7:45 AM, Argent Stonecutter wrote: > > >> On 2009-03-30, at 22:22, Philip Rosedale wrote: >> >>> From my perspective, the most important thing to communicate is that >>> if you are a committer, you now bear the responsibility of checking >>> in only high quality, well tested, sensible work. Solid design, >>> development, and QA is ultimately the final responsibility of the >>> person who hits the enter key and checks in code. Do not count on >>> LL (or anyone else) to do that work for you. >>> >> There still needs to be someone, or some-ones, eyeballing commits >> (even if after the fact) and doing release tracking and final QA. Open >> source or not, that's still a necessary role. If Linden Labs isn't >> going to do that, then we (SLDEV) need to step up to the plate, each >> of us in the areas we're competent to monitor. >> > > We (Linden Lab) will definitely still be responsible for the quality > of the code that makes it into our releases. But if people aren't > doing an adequate job of design, test, and documentation, then it's > going to make it a lot harder. > > Nobody's perfect -- but we're just asking people to think carefully > about what they're doing and be professional about it. The bigger the > change, the more eyes you should have on it before it goes in. Write > test plans and document your intent. > > In particular, we're pushing internally toward much more extensive > unit testing. Once we get some traction and comfort internally, I > intend to have a public training session to talk about how we're doing > it and how open source devs can help. Watch this space for more news. > > Q > > > > _______________________________________________ > 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/20090331/cb6a4119/attachment-0001.htm From monkowsk at watson.ibm.com Tue Mar 31 15:36:07 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 31 Mar 2009 18:36:07 -0400 Subject: [sldev] The puppet master? was: Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> References: <20090326034811.GA25411@alinoe.com> <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> Message-ID: <49D29AD7.9040206@watson.ibm.com> "Philippe Bossut (Merov Linden) wrote:" Philippe, are you continuing your Hands Free 3D project as part of Linden Lab? Mike From monkowsk at watson.ibm.com Tue Mar 31 15:49:33 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 31 Mar 2009 18:49:33 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D1629B.1030500@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> Message-ID: <49D29DFD.9070800@watson.ibm.com> Maybe I'm missing something. The blog post seems to talk about an alternate viewer where all kinds of ideas could be quickly implemented. But then, this post points to the HTTP texture project. There's one disconnect. And then how do changes in this alternate viewer get into the official viewer? Or is this just a way to humor the ex-CEO. Tell him he can do his project, but don't give haim any people to work with him, so he has to get volunteers to code his project. What, me cynical? ;-) Mike Rob Lanphier wrote: > Hi folks, > > As you probably saw in Philip's blog post (which if you haven't read it, > do so[1]), we're going to be doing a lot more development out in the > fishbowl, in a branch with community members who have direct commit access. > > There's a few of you that already have commit access, and others that I > imagine will be asking for it. Here's the procedure we'd like to follow > for commits for new committers to the http-texture: > > * File the patch in JIRA if it isn't already there > * Mail sldev with a link to the JIRA issue, and noting you'd like to > commit the patch > * Nag me in a couple of days if we haven't responded > * Assuming you get the nod, commit the change > > This isn't set in stone....there's a number of aspects about this > process I'm going to guess we haven't thought of. We want to be nimble, > but we also want to make sure there's lots of eyeballs on every commit. > > More info can be found here: > https://wiki.secondlife.com/wiki/HTTP_Texture_Development > > Comments welcome. > > Rob > > [1] Philip's blog post: > https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts > > _______________________________________________ > 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 dale at daleglass.net Tue Mar 31 16:20:14 2009 From: dale at daleglass.net (Dale Glass) Date: Wed, 1 Apr 2009 01:20:14 +0200 Subject: [sldev] Updated streaming patch, would like to commit Message-ID: <200904010120.20187.dale@daleglass.net> Hi! Here's a new version. I also added it to Jira: http://jira.secondlife.com/browse/VWR-12655 Changes: * Changed to use notifications. I think this is a better way to do it, and makes it possible to translate, unlike the hardcoded message. * Added setting and preferences panel to make it possible to disable. The default setting is enabled. It adds a "Show stream's title in chat" under "Play Streaming Music When Available". * Removes a debug message that didn't add anything useful. * Fixed the patch (first version was reversed ^_^;;) Left to do: * Windows support. Windows appears to use QuickTime for audio streaming, so I poked around on Apple's website, but didn't turn up anything useful yet. All I found so far is a post to the quicktime mailing list asking how to do it, without answers. * Translation. The only thing to translate is: "Playing: [TITLE]". Windows support should be doable due to mentions of iTunes being able to get the info. I *think* it's probably done by handling the event in mcActionFilterCallBack in llmediaimplquicktime.cpp, but the list of the possible values for the action variable I found doesn't seem to have anything suitable. Help would be very appreciated. Just pointing me to the appropiate documentation would probably be enough. Unless there are any problems with code, I think this could be committed, and would like to do so unless there are any problems with it. -------------- next part -------------- A non-text attachment was scrubbed... Name: streaming-info-v2.patch Type: text/x-patch Size: 8407 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090401/0f509aab/attachment.bin -------------- 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/20090401/0f509aab/attachment.pgp From dale at daleglass.net Tue Mar 31 16:34:17 2009 From: dale at daleglass.net (Dale Glass) Date: Wed, 1 Apr 2009 01:34:17 +0200 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <49D2A5F1.90608@streamsense.net> References: <200904010120.20187.dale@daleglass.net> <49D2A5F1.90608@streamsense.net> Message-ID: <200904010134.23309.dale@daleglass.net> On ????? 01 ?????? 2009 01:23:29 Thomas Grimshaw wrote: > Dale, > > Awesome work, is it possible to add support for FMOD's AAC streaming > capabilities also? > > ~T Unless I'm misunderstanding something, there's no fmod version? In llmedia/, there are media implementations for gstreamer (which handles audio and video), and quicktime (audio, video and images). There's also a mozlib version that handles web content. fmod is only used for sounds and not streaming as far as I can tell. The QuickTime version should provide both Windows and OS X support. -------------- 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/20090401/cf5665fc/attachment.pgp From tofu.linden at lindenlab.com Tue Mar 31 16:43:29 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue, 31 Mar 2009 16:43:29 -0700 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <200904010134.23309.dale@daleglass.net> References: <200904010120.20187.dale@daleglass.net><49D2A5F1.90608@streamsense.net> <200904010134.23309.dale@daleglass.net> Message-ID: <49D2AAA1.5010900@lindenlab.com> Dale Glass wrote: > Unless I'm misunderstanding something, there's no fmod version? > > In llmedia/, there are media implementations for gstreamer (which handles > audio and video), and quicktime (audio, video and images). There's also a > mozlib version that handles web content. > > fmod is only used for sounds and not streaming as far as I can tell. > > The QuickTime version should provide both Windows and OS X support. FMOD has its own streaming audio implementation which is used by default when FMOD is enabled - gst/qt are always used for streaming video, but are only used for streaming *audio* when FMOD is disabled (i.e. you're using OpenAL). HTH. -tofu From dale at daleglass.net Tue Mar 31 17:19:08 2009 From: dale at daleglass.net (Dale Glass) Date: Wed, 1 Apr 2009 02:19:08 +0200 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <49D2AAA1.5010900@lindenlab.com> References: <200904010120.20187.dale@daleglass.net> <200904010134.23309.dale@daleglass.net> <49D2AAA1.5010900@lindenlab.com> Message-ID: <200904010219.22070.dale@daleglass.net> On ????? 01 ?????? 2009 01:43:29 Tofu Linden wrote: > FMOD has its own streaming audio implementation which is used by > default when FMOD is enabled - gst/qt are always used for streaming > video, but are only used for streaming *audio* when FMOD is > disabled (i.e. you're using OpenAL). Ahh, I see I've not been digging deep enough. Ok. And with OpenAL there, what prevents the removal of FMOD? With OpenAL getting added, I imagine FMOD should disappear at some point? But I guess this means fmod support will be needed for the time being at least. I'll try to add support for that as well then. -------------- 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/20090401/e1dc0d93/attachment-0001.pgp From merov at lindenlab.com Tue Mar 31 17:32:55 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 31 Mar 2009 17:32:55 -0700 Subject: [sldev] The puppet master? was: Bug in LLTextureCacheRemoteWorker::doRead ? In-Reply-To: <49D29AD7.9040206@watson.ibm.com> References: <20090326034811.GA25411@alinoe.com> <57A0463D-E14B-4142-A401-8F047700FE52@lindenlab.com> <49D29AD7.9040206@watson.ibm.com> Message-ID: <7B0A3060-B48A-4D45-8F96-4E1A18CEB28A@lindenlab.com> Hi, On Mar 31, 2009, at 3:36 PM, Mike Monkowski wrote: > "Philippe Bossut (Merov Linden) wrote:" > > Philippe, are you continuing your Hands Free 3D project as part of > Linden Lab? Darn! I blew my linden cover! :) I'm actually not working on camera control right now. Been working on map tile rendering (you've seen the result in SLURL I hope), map viewer (which is part of the OS http-texture branch, give it a spin and let us know what you think) and now working with you guys to collaborate on that branch on performance and stability. I hope I'll be working again on puppeteering and/or camera control in a not too far future but that's not my charter right now. But thanks for asking (and for remembering :) ) Cheers, - Merov (Philippe) From robla at lindenlab.com Tue Mar 31 17:37:25 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 31 Mar 2009 17:37:25 -0700 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D29DFD.9070800@watson.ibm.com> References: <49D1629B.1030500@lindenlab.com> <49D29DFD.9070800@watson.ibm.com> Message-ID: <49D2B745.2030709@lindenlab.com> On 3/31/09 3:49 PM, Mike Monkowski wrote: > Maybe I'm missing something. The blog post seems to talk about an > alternate viewer where all kinds of ideas could be quickly > implemented. But then, this post points to the HTTP texture project. > There's one disconnect. We're in the process of coming up with a name for the project. More details soon on that front. In the meantime, we're using the "http-texture" name as one that will almost certainly not stick, so that we're not stuck with our working title as the name of the project. We do want to be focused on HTTP texture and general stability for a while, since moving to HTTP delivery of textures is a big architectural win, and it's going to take determination and focus to get this code to production quality. > And then how do changes in this alternate viewer get into the official > viewer? Or is this just a way to humor the ex-CEO. Tell him he can > do his project, but don't give haim any people to work with him, so he > has to get volunteers to code his project. > > What, me cynical? ;-) No kidding! :) This isn't an "all hands on deck" thing, but it's more than a token project. We don't have all of the details sorted out as to how the changes get into the mainline viewer, but there are a lot of us that are motivated to get those details sorted out. Are you thinking about helping? Rob > Rob Lanphier wrote: >> Hi folks, >> >> As you probably saw in Philip's blog post (which if you haven't read it, >> do so[1]), we're going to be doing a lot more development out in the >> fishbowl, in a branch with community members who have direct commit >> access. >> >> There's a few of you that already have commit access, and others that I >> imagine will be asking for it. Here's the procedure we'd like to follow >> for commits for new committers to the http-texture: >> >> * File the patch in JIRA if it isn't already there >> * Mail sldev with a link to the JIRA issue, and noting you'd like to >> commit the patch >> * Nag me in a couple of days if we haven't responded >> * Assuming you get the nod, commit the change >> >> This isn't set in stone....there's a number of aspects about this >> process I'm going to guess we haven't thought of. We want to be nimble, >> but we also want to make sure there's lots of eyeballs on every commit. >> >> More info can be found here: >> https://wiki.secondlife.com/wiki/HTTP_Texture_Development >> >> Comments welcome. >> >> Rob >> >> [1] Philip's blog post: >> https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts >> >> >> _______________________________________________ >> 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 gcanaday at gmail.com Tue Mar 31 19:29:55 2009 From: gcanaday at gmail.com (Glen) Date: Tue, 31 Mar 2009 22:29:55 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D2B745.2030709@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> <49D29DFD.9070800@watson.ibm.com> <49D2B745.2030709@lindenlab.com> Message-ID: <49D2D1A3.40903@gmail.com> How about "Project Concrete"? Rob Lanphier wrote: > On 3/31/09 3:49 PM, Mike Monkowski wrote: >> Maybe I'm missing something. The blog post seems to talk about an >> alternate viewer where all kinds of ideas could be quickly >> implemented. But then, this post points to the HTTP texture project. >> There's one disconnect. > > We're in the process of coming up with a name for the project. More > details soon on that front. In the meantime, we're using the > "http-texture" name as one that will almost certainly not stick, so that > we're not stuck with our working title as the name of the project. > > We do want to be focused on HTTP texture and general stability for a > while, since moving to HTTP delivery of textures is a big architectural > win, and it's going to take determination and focus to get this code to > production quality. > >> And then how do changes in this alternate viewer get into the official >> viewer? Or is this just a way to humor the ex-CEO. Tell him he can >> do his project, but don't give haim any people to work with him, so he >> has to get volunteers to code his project. >> >> What, me cynical? ;-) > > No kidding! :) > > This isn't an "all hands on deck" thing, but it's more than a token > project. We don't have all of the details sorted out as to how the > changes get into the mainline viewer, but there are a lot of us that are > motivated to get those details sorted out. > > Are you thinking about helping? > > Rob > >> Rob Lanphier wrote: >>> Hi folks, >>> >>> As you probably saw in Philip's blog post (which if you haven't read it, >>> do so[1]), we're going to be doing a lot more development out in the >>> fishbowl, in a branch with community members who have direct commit >>> access. >>> >>> There's a few of you that already have commit access, and others that I >>> imagine will be asking for it. Here's the procedure we'd like to follow >>> for commits for new committers to the http-texture: >>> >>> * File the patch in JIRA if it isn't already there >>> * Mail sldev with a link to the JIRA issue, and noting you'd like to >>> commit the patch >>> * Nag me in a couple of days if we haven't responded >>> * Assuming you get the nod, commit the change >>> >>> This isn't set in stone....there's a number of aspects about this >>> process I'm going to guess we haven't thought of. We want to be nimble, >>> but we also want to make sure there's lots of eyeballs on every commit. >>> >>> More info can be found here: >>> https://wiki.secondlife.com/wiki/HTTP_Texture_Development >>> >>> Comments welcome. >>> >>> Rob >>> >>> [1] Philip's blog post: >>> https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts >>> >>> >>> _______________________________________________ >>> 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 philip at lindenlab.com Tue Mar 31 21:24:22 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Tue, 31 Mar 2009 21:24:22 -0700 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D2D1A3.40903@gmail.com> References: <49D1629B.1030500@lindenlab.com> <49D29DFD.9070800@watson.ibm.com> <49D2B745.2030709@lindenlab.com> <49D2D1A3.40903@gmail.com> Message-ID: <49D2EC76.8020909@lindenlab.com> Man Glen, you are tough! "humor the ex-CEO"... really? Actually I very much wanted to work more on open source. I feel like it is a huge chance for greatness, but that we (as a company) need to do more to support it. Also, I think that the broader question of how people do great work together in an environment which is more open than the conventional work relationship/organization is an important opportunity. There haven't been many open source projects as compared to companies or societies - seems like a change for doing something really great. I want to help create a high-value viewer that lots of people use. That means we can't just put every random thing into it, given we (collectively) have limited time and people. Right? So we thought stabilizing the new map code and getting that viewer out there was a good starting point. P Glen wrote: > How about "Project Concrete"? > > Rob Lanphier wrote: >> On 3/31/09 3:49 PM, Mike Monkowski wrote: >>> Maybe I'm missing something. The blog post seems to talk about an >>> alternate viewer where all kinds of ideas could be quickly >>> implemented. But then, this post points to the HTTP texture project. >>> There's one disconnect. >> We're in the process of coming up with a name for the project. More >> details soon on that front. In the meantime, we're using the >> "http-texture" name as one that will almost certainly not stick, so that >> we're not stuck with our working title as the name of the project. >> >> We do want to be focused on HTTP texture and general stability for a >> while, since moving to HTTP delivery of textures is a big architectural >> win, and it's going to take determination and focus to get this code to >> production quality. >> >>> And then how do changes in this alternate viewer get into the official >>> viewer? Or is this just a way to humor the ex-CEO. Tell him he can >>> do his project, but don't give haim any people to work with him, so he >>> has to get volunteers to code his project. >>> >>> What, me cynical? ;-) >> No kidding! :) >> >> This isn't an "all hands on deck" thing, but it's more than a token >> project. We don't have all of the details sorted out as to how the >> changes get into the mainline viewer, but there are a lot of us that are >> motivated to get those details sorted out. >> >> Are you thinking about helping? >> >> Rob >> >>> Rob Lanphier wrote: >>>> Hi folks, >>>> >>>> As you probably saw in Philip's blog post (which if you haven't read it, >>>> do so[1]), we're going to be doing a lot more development out in the >>>> fishbowl, in a branch with community members who have direct commit >>>> access. >>>> >>>> There's a few of you that already have commit access, and others that I >>>> imagine will be asking for it. Here's the procedure we'd like to follow >>>> for commits for new committers to the http-texture: >>>> >>>> * File the patch in JIRA if it isn't already there >>>> * Mail sldev with a link to the JIRA issue, and noting you'd like to >>>> commit the patch >>>> * Nag me in a couple of days if we haven't responded >>>> * Assuming you get the nod, commit the change >>>> >>>> This isn't set in stone....there's a number of aspects about this >>>> process I'm going to guess we haven't thought of. We want to be nimble, >>>> but we also want to make sure there's lots of eyeballs on every commit. >>>> >>>> More info can be found here: >>>> https://wiki.secondlife.com/wiki/HTTP_Texture_Development >>>> >>>> Comments welcome. >>>> >>>> Rob >>>> >>>> [1] Philip's blog post: >>>> https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts >>>> >>>> >>>> _______________________________________________ >>>> 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 bogus@does.not.exist.com Tue Mar 10 20:13:32 2009 From: bogus@does.not.exist.com () Date: Wed, 11 Mar 2009 03:13:32 -0000 Subject: No subject Message-ID: Andrew does a lot of server code. Beyond that, I'm not too knowledgeable. Reflections sound like a client thing. Q Linden is the one posting out those Open Source meetings, which are client thingies. So contacting Q may be your best bet at finding the Linden to talk to. Q Linden's office hours at Wednesday, 8am-9am. http://wiki.secondlife.com/wiki/Office_hours That's separate from the 2pm open source meeting so you wouldn't be crashing the party or anything. Let us know what you find out! <3 -Stickman