From blueszodiakos at gmail.com Mon Jan 8 06:19:52 2007 From: blueszodiakos at gmail.com (Blues Zodiakos) Date: Mon Jan 8 06:19:55 2007 Subject: [sldev] Hello everyone! - and a question on Ogre3D Message-ID: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> First of all, I'd really like to say that I appreciate open-sourcing the client. This move took me completely by surprise. I was starting to give up hope for SL, and this changed my mind. Reading the open source page on SecondLife.com, it was quite obvious that this wasn't a spur-of-the-moment decision, and it looks like LL thought it over, understands the risks and rewards, and has a relatively clear view of what they are doing. It's a pity that some of the more negative people that comment on the blog don't read it and become educated, but I digress. One of the things that first came to mind when I thought about what features would be most important to me to add to the viewer was GUTTING THE CURRENT 3D ENGINE AND REPLACING IT WITH OGRE3D (www.ogre3d.org). These are the reasons that I suggest this, in no particular order (note that I have yet to actually view the source code for the client, and thus don't have any clue of the positive/negative impact on framerates or such this would have. I'm basing this entirely on assumption.) * Ogre3D is cross platform. I assume the client 3D code is already cross platform, but there is another reason why I'd like to switch to it: * Ogre3D is api-agnostic. It has rendering paths for both Direct3D and OpenGL. This is a big one for me, because Windows Vista, like it or not, will be on A LOT of people's computers in the future because most new computers will come with it (and is on mine as we speak). I do realize that Nvidia already has an Ogl compliant ICD driver, but ATI has yet to release one and is entirely silent on the issue. Changing to Ogre3D alone would solve this issue by using Direct3D on Vista computers, without requiring a developer to change the underlying code (besides rewriting the 3D sections, initially). * Ogre3D is pretty optimized, and has great performance. Again, I don't really know how optimized the 3D code is in the client, but why rewrite the book? Ogre3D has been around for a long time, is really stable, has all the features one would expect from a modern 3D engine, and has benefited from years of optimizing for various platforms. * Swapping out the code now would mean less maintenance in the future to provide fixes for various 3D cards, as the Ogre3D team usually already does it, and duplicating that effort in a custom 3D engine would be inefficient. What does everyone else think? Has work on this already been thought of, or even started? -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.secondlife.com/cgi-bin/mailman/private/sldev/attachments/20070108/9ab14be4/attachment.htm From robla at lindenlab.com Mon Jan 8 06:46:15 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jan 8 06:46:48 2007 Subject: [sldev] Hello everyone! - and a question on Ogre3D In-Reply-To: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> References: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> Message-ID: <45A25937.5090704@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone! First a quick intro: I'm Rob Lanphier; aka Rob Linden. I'm Linden's new "open source busybody", which means, among other things, I should be posting a lot to this list. I'll probably be posting a longer intro to the blog later today. Blues, I'd like to address your comment. We're very interested in improving our 3D performance, but we're not (yet) interested in scrapping everything and starting over. Please, let people have a chance to look at the code before suggesting starting over! Thanks Rob On 1/8/07 6:19 AM, Blues Zodiakos wrote: > First of all, I'd really like to say that I appreciate > open-sourcing the client. This move took me completely by > surprise. I was starting to give up hope for SL, and this changed > my mind. Reading the open source page on SecondLife.com, it was > quite obvious that this wasn't a spur-of-the-moment decision, and > it looks like LL thought it over, understands the risks and > rewards, and has a relatively clear view of what they are doing. > It's a pity that some of the more negative people that comment on > the blog don't read it and become educated, but I digress. > > One of the things that first came to mind when I thought about what > features would be most important to me to add to the viewer was > GUTTING THE CURRENT 3D ENGINE AND REPLACING IT WITH OGRE3D ( > www.ogre3d.org ). > > These are the reasons that I suggest this, in no particular order > (note that I have yet to actually view the source code for the > client, and thus don't have any clue of the positive/negative > impact on framerates or such this would have. I'm basing this > entirely on assumption.) > > * Ogre3D is cross platform. I assume the client 3D code is already > cross platform, but there is another reason why I'd like to switch > to it: > > * Ogre3D is api-agnostic. It has rendering paths for both Direct3D > and OpenGL. This is a big one for me, because Windows Vista, like > it or not, will be on A LOT of people's computers in the future > because most new computers will come with it (and is on mine as we > speak). I do realize that Nvidia already has an Ogl compliant ICD > driver, but ATI has yet to release one and is entirely silent on > the issue. Changing to Ogre3D alone would solve this issue by > using Direct3D on Vista computers, without requiring a developer to > change the underlying code (besides rewriting the 3D sections, > initially). > > * Ogre3D is pretty optimized, and has great performance. Again, I > don't really know how optimized the 3D code is in the client, but > why rewrite the book? Ogre3D has been around for a long time, is > really stable, has all the features one would expect from a modern > 3D engine, and has benefited from years of optimizing for various > platforms. > > * Swapping out the code now would mean less maintenance in the > future to provide fixes for various 3D cards, as the Ogre3D team > usually already does it, and duplicating that effort in a custom 3D > engine would be inefficient. > > What does everyone else think? Has work on this already been > thought of, or even started? > > ---------------------------------------------------------------------- > > > _______________________________________________ Click here to > unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFolk3Pd430ImZiAMRAgASAJ9ywDwZHyiBxTx6HrEuuhhTRSs+bACeN52H VZ7pDKbZJvBMVtk4CESgzRA= =0iAI -----END PGP SIGNATURE----- From teravus at gmail.com Mon Jan 8 06:58:41 2007 From: teravus at gmail.com (Teravus Ovares) Date: Mon Jan 8 06:58:42 2007 Subject: [sldev] Next Course of action for New Developers Message-ID: <34cc66250701080658q7d20dad3k8c25a497189aef69@mail.gmail.com> Greetings everyone, I figured I'd say Hi after browsing the source and mention that if you have not already taken a look at the project management/bug suite, head on over to https://jira.secondlife.com/ and get familiar with the Jira system. Chances are if you are serious about working on SecondLife that you will be using it a lot :). Best Regards Teravus Ousley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070108/656e006a/attachment.htm From lawu at progarts.com Mon Jan 8 07:00:03 2007 From: lawu at progarts.com (Lynne Whitehorn-Umphres) Date: Mon Jan 8 07:15:36 2007 Subject: [sldev] How often will the Linden source tree be synced? Message-ID: <011601c73335$ae11bdb0$6610080a@leverette> Did I miss it in the docs somewhere or does anyone know whether/when/how LL plans to sync the released archives with their internal source tree? Or are there plans to allow cvs/svn/... checkouts? Thanks and huzzah for the source. -CoyoteAngel Dimsum/Lynne Whitehorn-Umphres -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070108/44373ef5/attachment.htm From robla at lindenlab.com Mon Jan 8 07:17:43 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jan 8 07:18:22 2007 Subject: [sldev] How often will the Linden source tree be synced? In-Reply-To: <011601c73335$ae11bdb0$6610080a@leverette> References: <011601c73335$ae11bdb0$6610080a@leverette> Message-ID: <45A26097.90909@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/8/07 7:00 AM, Lynne Whitehorn-Umphres wrote: > > Did I miss it in the docs somewhere or does anyone know > whether/when/how LL plans to sync the released archives with their > internal source tree? Or are there plans to allow cvs/svn/... > checkouts? > > Thanks and huzzah for the source. I hope we can do it reasonably frequently. I would like to get version control in place, but want to first get a sense of what people want and how they will be using it. See: https://wiki.secondlife.com/wiki/Version_control_repository Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFomCXPd430ImZiAMRAsmuAJ46uxyiqbOrYNvDNa5gDRFJqr5xnACfdSyC b8W+tsW5JAVaKH4yOOuUGzs= =z9qu -----END PGP SIGNATURE----- From phoenix at secondlife.com Mon Jan 8 07:22:23 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Jan 8 07:22:34 2007 Subject: [sldev] Hello everyone! - and a question on Ogre3D In-Reply-To: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> References: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> Message-ID: Thank you. :) We considered ogre many years ago, but it was long enough ago that information about the decision has been purged from my mail archives and does not appear on any of our current issue and knowledge tracking systems. Though I forget the specifics, it was almost certainly rejected for the same reason as every other graphics engine we have tested -- memory management of the scene is much more complex than pushing the triangles through the card. If ogre has a d3d/ogl abstraction layer which gives us a low enough level api to actually specialize where we need to work, then maybe. We have spoken with commercial engine developers, and none of them can match our framerate without heavy modification. On 2007 Jan 8, at 06:19, Blues Zodiakos wrote: > First of all, I'd really like to say that I appreciate open- > sourcing the client. This move took me completely by surprise. I > was starting to give up hope for SL, and this changed my mind. > Reading the open source page on SecondLife.com, it was quite > obvious that this wasn't a spur-of-the-moment decision, and it > looks like LL thought it over, understands the risks and rewards, > and has a relatively clear view of what they are doing. It's a > pity that some of the more negative people that comment on the blog > don't read it and become educated, but I digress. > > One of the things that first came to mind when I thought about what > features would be most important to me to add to the viewer was > GUTTING THE CURRENT 3D ENGINE AND REPLACING IT WITH OGRE3D > ( www.ogre3d.org). > > These are the reasons that I suggest this, in no particular order > (note that I have yet to actually view the source code for the > client, and thus don't have any clue of the positive/negative > impact on framerates or such this would have. I'm basing this > entirely on assumption.) > > * Ogre3D is cross platform. I assume the client 3D code is already > cross platform, but there is another reason why I'd like to switch > to it: > > * Ogre3D is api-agnostic. It has rendering paths for both Direct3D > and OpenGL. This is a big one for me, because Windows Vista, like > it or not, will be on A LOT of people's computers in the future > because most new computers will come with it (and is on mine as we > speak). I do realize that Nvidia already has an Ogl compliant ICD > driver, but ATI has yet to release one and is entirely silent on > the issue. Changing to Ogre3D alone would solve this issue by > using Direct3D on Vista computers, without requiring a developer to > change the underlying code (besides rewriting the 3D sections, > initially). > > * Ogre3D is pretty optimized, and has great performance. Again, I > don't really know how optimized the 3D code is in the client, but > why rewrite the book? Ogre3D has been around for a long time, is > really stable, has all the features one would expect from a modern > 3D engine, and has benefited from years of optimizing for various > platforms. > > * Swapping out the code now would mean less maintenance in the > future to provide fixes for various 3D cards, as the Ogre3D team > usually already does it, and duplicating that effort in a custom 3D > engine would be inefficient. > > What does everyone else think? Has work on this already been > thought of, or even started? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070108/0c39a31b/PGP.pgp From nightkin99 at yahoo.com Mon Jan 8 07:25:33 2007 From: nightkin99 at yahoo.com (Kin Night) Date: Mon Jan 8 07:25:39 2007 Subject: [sldev] Greetings Message-ID: <20070108152533.9759.qmail@web27313.mail.ukl.yahoo.com> Hello all, Open-sourcing can be hazardous, but I trust LL has been thinking about doing it for a long time. In my opinion this move will assure SL longevity and stability (maybe not tomorrow, but in the long run). And maybe give LL resources more time to focus on server-side problems :p As long as sensitive data and commands stay under LL's control it's fine. Keep up the good work LL, and thanks for the wonderful surprise :) Nightkin / Mordred Corleone in SL, having nothing to say but saying it anyway __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicit?s http://mail.yahoo.fr Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070108/cbe42a92/attachment-0001.htm From cnd at knowprose.com Mon Jan 8 07:57:37 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Mon Jan 8 07:57:45 2007 Subject: [sldev] SL Viewer code In-Reply-To: References: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> Message-ID: <45A269F1.4050905@knowprose.com> I noticed that there are two downloads; 1 for Windows and 1 for Mac/Linux. Is this just a matter of the method of compression, or are there differences between the 2 sources? (Asking because downloading on 256K ADSL is slower than asking). -- Taran Rampersad (Nobody Fugazi) Presently in: San Fernando, Trinidad and Tobago cnd@knowprose.com http://www.knowprose.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From robla at lindenlab.com Mon Jan 8 08:09:24 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jan 8 08:09:57 2007 Subject: [sldev] SL Viewer code In-Reply-To: <45A269F1.4050905@knowprose.com> References: <86a028120701080619i6cd2d648w4d873f89123b9359@mail.gmail.com> <45A269F1.4050905@knowprose.com> Message-ID: <45A26CB4.6040204@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/8/07 7:57 AM, Taran Rampersad wrote: > I noticed that there are two downloads; 1 for Windows and 1 for > Mac/Linux. Is this just a matter of the method of compression, or > are there differences between the 2 sources? > > (Asking because downloading on 256K ADSL is slower than asking). The line endings in the Windows version are CRLF, whereas the Mac/Linux uses just LF. Most text editors these days can handle both, but we provide the two as a convenience. Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFomy0Pd430ImZiAMRAjuUAJ9QvzwLTrL+tYxINShRYUbhAEwAYgCfbjtg G/YJbsR5HPgY7UfsRGtWwTg= =8eKp -----END PGP SIGNATURE----- From zefram at kryptonians.net Mon Jan 8 02:01:43 2007 From: zefram at kryptonians.net (Zefram Cochrane) Date: Mon Jan 8 08:10:33 2007 Subject: [sldev] The relationship from here Message-ID: <20070108100143.GA17007@kryptonians.net> Now that the client is open source, are we to understand that Linden Labs still manages the product but may choose to accept proposed enhancements from the open source community? - Kalel Venkman From gigstaggart at gmail.com Mon Jan 8 08:52:16 2007 From: gigstaggart at gmail.com (Gigs Taggart) Date: Mon Jan 8 08:52:24 2007 Subject: [sldev] Hi everyone! Message-ID: <2a5bee190701080852t3f7336a2x212e638f0c3af9d@mail.gmail.com> Hi, I've been loosely following the libSL effort, I hope to get more involved with the open client development. My main interest with all this is interactive agent design (NPCs), something I think could be big for SL in the long run. I have a background in C/C++, though I admit I'm kinda rusty at both of them, it's been a while. I've been mostly developing in PHP and Bash (and LSL lately) for the last several years. I look forward to at a minimum helping you all track down bugs and maybe submit some small patches. -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070108/0b99f366/attachment.htm From robla at lindenlab.com Mon Jan 8 09:39:57 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jan 8 09:40:35 2007 Subject: [sldev] The relationship from here In-Reply-To: <20070108100143.GA17007@kryptonians.net> References: <20070108100143.GA17007@kryptonians.net> Message-ID: <45A281ED.2040207@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/8/07 2:01 AM, Zefram Cochrane wrote: > Now that the client is open source, are we to understand that > Linden Labs still manages the product but may choose to accept > proposed enhancements from the open source community? That's the idea. Guidelines for submitting are here: http://secondlife.com/developers/opensource/submitting Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFooHtPd430ImZiAMRAnKmAJ9mLRb9A4WH5Sz+6TZdU64J42P7lwCeLDH6 rV+iXqpfyZlBC2hbtLU+zm4= =hRXT -----END PGP SIGNATURE----- From annagulaev at gmail.com Mon Jan 8 13:00:02 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Jan 8 13:00:05 2007 Subject: [sldev] third party viewers - release on LL's schedule? Message-ID: Just wondering if third-party viewers will have to be re-released every time LL has a mandatory update? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070108/63ffa2d8/attachment.htm From artm at v2.nl Mon Jan 8 13:28:24 2007 From: artm at v2.nl (Artem Baguinski) Date: Mon Jan 8 13:28:27 2007 Subject: [sldev] third party viewers - release on LL's schedule? In-Reply-To: References: Message-ID: On 08/01/07, Anna Gulaev wrote: > Just wondering if third-party viewers will have to be re-released every time > LL has a mandatory update? if the update is due to change of protocol then third party viewers will have to update to compatible protocol version. From dimentox at dimentox.com Mon Jan 8 13:33:32 2007 From: dimentox at dimentox.com (Brandon) Date: Mon Jan 8 13:33:50 2007 Subject: [sldev] Anyone creating a Direct X viewer? In-Reply-To: References: Message-ID: <23079.134.163.255.14.1168292012.squirrel@mail.thantosga.com> We all know SL is slow and sluggish.. Anyone creating a direct X viewer.. I am looking to form a Community Viewer project.. From Stef.Wade at stots.de Mon Jan 8 13:44:14 2007 From: Stef.Wade at stots.de (Stef Wade) Date: Mon Jan 8 13:44:23 2007 Subject: [sldev] third party viewers - release on LL's schedule? In-Reply-To: References: Message-ID: <45A2BB2E.6030804@stots.de> Anna Gulaev schrieb: > Just wondering if third-party viewers will have to be re-released every > time LL has a mandatory update? We have not seen a mandatory update for quite a while...looks like SL is settling down :) As I understand this http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/#more-632 "The end of this path is a day when we can update the grid, viewers and simulators, in pieces, without ever taking it down." at least the GOAL seems to be to get rid of mandatory updates. And if "free clients" will lead to "free servers", then server-updates will influence the clients just as much as the next apache-release will affect firefox. But hey, this is just the first day of an exciting new era of SL! I quess for these things we might need to wait how things will go. As a sidenote, I just redicovered this quote from Cory Linden: http://blog.secondlife.com/2006/12/20/town-hall-with-cory-introductory-transcript/ "Viewer scaling, which was also asked about in the SL 2.0 context, is an ongoing process. We don?t currently have the development resources to split off a team to start building a new client ? although if anyone has a 10 to 20 person development team with experience in high-performance OpenGL who would like to talk, please email me!" Not that I would be one of the "OpenGL-experienced-developer". I will contribute merely by "checking if things will compile on my setup"... but the statement is interesting, now that the Client has been GPL'd. Yours, Stefan "Stef Wade" Waidele -- http://LinuxBasics.org http://Krone-Neuenburg.com http://Stefan.Waidele.info http://sl.stots.de/blog From artm at v2.nl Mon Jan 8 13:44:24 2007 From: artm at v2.nl (Artem Baguinski) Date: Mon Jan 8 13:44:27 2007 Subject: [sldev] Anyone creating a Direct X viewer? In-Reply-To: <23079.134.163.255.14.1168292012.squirrel@mail.thantosga.com> References: <23079.134.163.255.14.1168292012.squirrel@mail.thantosga.com> Message-ID: Hi Brandon On 08/01/07, Brandon wrote: > We all know SL is slow and sluggish.. Anyone creating a direct X viewer.. not to acknowledge the connection between drawing api and sluggishness, but here are my 2cents: 1. people able to do that are reading the sources / getting them to built at the moment. 2. see discussion about ogre3d earlier today. ogre3d can use either opengl or directx to draw. From peekay at bluewax.com Mon Jan 8 13:51:37 2007 From: peekay at bluewax.com (Peekay Semyorka) Date: Mon Jan 8 13:51:44 2007 Subject: [sldev] Compilation notes... Message-ID: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> First of, thanks Lindens for the huge amount of work y'all did to make this happen! It's a great gift to the community. After a few tries (due to my inability to read & actually follow directions) I've finally built my first client. :-) A couple of notes: 1. When starting newview it complained about not finding a few dlls (smime3.dll, nss3.dll, softokn3.dll, ssl3.dll.) I figured these were part of Mozilla so I just copied them over from my Firefox install. Not sure if these were supposed to be included in the pre-compiled libs or not? 2. The "test" project has reference to a ".\lldatabase_tut.cpp" file but that file doesn't exist. Thanks again & kudos all around, -peekay From phoenix at secondlife.com Mon Jan 8 18:54:17 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Jan 8 18:55:01 2007 Subject: [sldev] Compilation notes... In-Reply-To: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> References: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2007, at 1:51 PM, Peekay Semyorka wrote: > First of, thanks Lindens for the huge amount of work y'all did to make > this happen! It's a great gift to the community. Thank you of course. :) > After a few tries (due to my inability to read & actually follow > directions) I've finally built my first client. :-) A couple of > notes: > > 1. When starting newview it complained about not finding a few dlls > (smime3.dll, nss3.dll, softokn3.dll, ssl3.dll.) I figured these > were part > of Mozilla so I just copied them over from my Firefox install. Not > sure > if these were supposed to be included in the pre-compiled libs or not? These binary files are included in the pre-compiled library bundle. We identified 10 separate distinct packages which could be assembled but felt that was too many. We decided to package the static libraries, dynamic libraries, and various other generated files into the platform specific downloads to bring the total download count to 5 for everything or 2 (from us) if you wanted to make a platform specific build from scratch or the easy way. > 2. The "test" project has reference to a ".\lldatabase_tut.cpp" > file but > that file doesn't exist. My bad. That is a reference to a set of unit tests for the database wrapper libraries. I forgot to instruct the exporter to extract it from the project file. The next release will not have that reference. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFowPawJCr4A9g8scRAq5QAJ9K2mJ7YjId4yspWc2r7jsaSQcV+QCgjaPg JTIi3mUErXgjguaFH4ixn78= =fDZI -----END PGP SIGNATURE----- From phoenix at secondlife.com Mon Jan 8 19:39:58 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Jan 8 19:40:05 2007 Subject: [sldev] Compilation notes... In-Reply-To: References: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> Message-ID: <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2007, at 6:54 PM, Phoenix wrote: >> On Jan 8, 2007, at 1:51 PM, Peekay Semyorka wrote: >> 2. The "test" project has reference to a ".\lldatabase_tut.cpp" >> file but >> that file doesn't exist. > > My bad. That is a reference to a set of unit tests for the database > wrapper libraries. I forgot to instruct the exporter to extract it > from the project file. The next release will not have that reference. Actually, I do not find any references to lldatabase_tut.cpp in the windows project files. We did leave a reference in the linux build manifest files, but that should only be invoked when building the tests using scons. Where did you find this reference? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFow6PwJCr4A9g8scRAmfEAJoCKzZxGl5ZUvIbblEsZFybHM9pCQCfbjFZ /oBLjyHkc1uG5J8+SCC+tMU= =PdeY -----END PGP SIGNATURE----- From sbg at acw.com Mon Jan 8 20:00:36 2007 From: sbg at acw.com (sbg@acw.com) Date: Mon Jan 8 20:00:38 2007 Subject: [sldev] Compilation notes... In-Reply-To: <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> References: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> Message-ID: <1098.24.63.25.238.1168315236.squirrel@www.acw.com> The reference to lldatabse_tut.cpp in the Windows build is in the Source Files list of the test project. Cheers, Scott From sbg at acw.com Mon Jan 8 20:13:13 2007 From: sbg at acw.com (sbg@acw.com) Date: Mon Jan 8 20:13:14 2007 Subject: [sldev] Tip O' the Hat to the Lindens In-Reply-To: <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> References: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> Message-ID: <1109.24.63.25.238.1168315993.squirrel@www.acw.com> I'd like to add my voice to those thanking the Lindens for open sourcing the SL client. First, it's a beautifully balanced body of code and a delight to read and study. I'm already plotting to use it as the text in a software engineering course. Second, it enables one to easily experiment with alternative avatar-based metaphors. We're still in the Gopher era. Let a thousand "Life"s bloom. Cheers, Scott From sbg at acw.com Tue Jan 9 02:56:03 2007 From: sbg at acw.com (sbg@acw.com) Date: Tue Jan 9 02:56:04 2007 Subject: [sldev] Compilation notes... In-Reply-To: <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> References: <1558.70.49.105.201.1168293097.squirrel@webmail.bluewax.com> <3E573354-AD16-46BA-AF20-9E9F33D96C79@secondlife.com> Message-ID: <2100.24.63.25.238.1168340163.squirrel@www.acw.com> With a clean install of Visual Studio .NET and all the SDKs, I found that I had to replace #include with #define INITGUID #include #undef INITGUID in lldxhardware.cpp to force definitions of CLSID_DxDiagProvider and IID_IDxDiagProvider. Otherwise the build of newview et al was a piece of cake. Nice work, folks. Cheers, Scott From kunnis at gmail.com Tue Jan 9 08:57:35 2007 From: kunnis at gmail.com (Zack Geers) Date: Tue Jan 9 08:57:39 2007 Subject: [sldev] Version Control Message-ID: What is the process going to be to select a version control? I hate working without a Version Control. I'm tempted to copy it into my local svn repostory just so I can do diffs to submit patches. I'd suggest SVN, it's popular, so there will be a lot of developers that already know how to use it, and it's well tested. There's clients for windows, mac, *nix. There's passable free plugins for VS and a good one for the windows shell. There is also a handy web-based SVN repo browser (viewcv) that I like, and I find it handy for discussions. Kunnis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070109/ed52c7ab/attachment.htm From Stef.Wade at stots.de Tue Jan 9 10:30:49 2007 From: Stef.Wade at stots.de (Stef Wade) Date: Tue Jan 9 10:31:07 2007 Subject: [sldev] Missing glu.h - Compile failure on Ubuntu 6.10 Message-ID: <45A3DF59.8020202@stots.de> Hi everybody, so, I have grabbed the source last night and started compiling today. I have followed the instructions on https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 After a while, the build exits with an error: GL/glu.h is missing. (see below for details) I tried to install the glu-package but apt-get has version-problems there. ("Broken Packages", see below for details) So, where do I go from here? Ubuntu-Edgy problem? Any hints? Thanks, Stefan ----8<----------------------------------------------------------------------- g++-3.4 -o /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/llrender/llagpmempoolarb.o -c -g -pipe -Wall -Wno-trigraphs -DLL_USE_KDU=0 -falign-loops=16 -fno-math-errno -fexceptions -fsigned-char -fno-strict-aliasing -ffast-math -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -DLL_LINUX=1 -DAPPID=secondlife -DLL_SDL=1 -DLL_X11=1 -DLL_GTK=1 -O2 -DNDEBUG -DLL_RELEASE=1 -Illcommon -Illmath -Illwindow -Illaudio -Illcharacter -Illdatabase -Illhavok -Illimage -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene -Illui -Illvfs -Illwindow -Illxml -Ilscript -I/home/stw/Daten/SL-dev/linden/libraries/include -I/home/stw/Daten/SL-dev/linden/libraries/include/havok -I/home/stw/Daten/SL-dev/linden/libraries/i686-linux/include "-I ../libraries/i686-linux/include/gtk-2.0" "-I ../libraries/i686-linux/include/glib-2.0" "-I ../libraries/i686-linux/include/pango-1.0" "-I ../libraries/i686-linux/include/atk-1.0" "-I ../libraries/i686-linux/include/ELFIO" "-I ../libraries/i686-linux/include/llfreetype2" /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/llrender/llagpmempoolarb.cpp In file included from llwindow/llglstates.h:41, from llwindow/llgl.h:255, from /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/llrender/llagpmempoolarb.cpp:30: llwindow/llglheaders.h:55:20: GL/glu.h: No such file or directory scons: *** [/tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/llrender/llagpmempoolarb.o] Error 1 scons: building terminated because of errors. ----8<----------------------------------------------------------------------- This is how the attempt to install libglu1-mesa-dev fails: ----8<----------------------------------------------------------------------- ...$ LANG=C sudo apt-get install libglu1-mesa-dev libgl1-mesa-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgl1-mesa-dev: Depends: mesa-common-dev (= 6.5.1~20060817-0ubuntu3) but 6.5.1+cvs20060824 is to be installed libglu1-mesa-dev: Depends: libglu1-mesa (= 6.5.1~20060817-0ubuntu3) but 6.5.1+cvs20060824 is to be installed E: Broken packages ----8<----------------------------------------------------------------------- -- http://LinuxBasics.org http://Krone-Neuenburg.com http://Stefan.Waidele.info http://sl.stots.de/blog From blino at mandriva.com Tue Jan 9 10:41:16 2007 From: blino at mandriva.com (Olivier Blin) Date: Tue Jan 9 10:41:17 2007 Subject: [sldev] Missing glu.h - Compile failure on Ubuntu 6.10 In-Reply-To: <45A3DF59.8020202@stots.de> (Stef Wade's message of "Tue\, 09 Jan 2007 19\:30\:49 +0100") References: <45A3DF59.8020202@stots.de> Message-ID: Stef Wade writes: > Hi everybody, > > so, I have grabbed the source last night and started compiling today. > > I have followed the instructions on > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 > > After a while, the build exits with an error: > GL/glu.h is missing. (see below for details) > > I tried to install the glu-package but apt-get has version-problems > there. ("Broken Packages", see below for details) > > So, where do I go from here? Ubuntu-Edgy problem? It seems so, the package that contains GL/glu.h in Ubuntu is libglu1-mesa-dev. > The following packages have unmet dependencies: > libgl1-mesa-dev: Depends: mesa-common-dev (= > 6.5.1~20060817-0ubuntu3) but 6.5.1+cvs20060824 is to be installed > libglu1-mesa-dev: Depends: libglu1-mesa (= 6.5.1~20060817-0ubuntu3) > but 6.5.1+cvs20060824 is to be installed > E: Broken packages It looks like the repository does not contain a consistent set of mesa packages (different releases). Maybe just a mirror issue? -- Olivier Blin - Mandriva From blino at mandriva.com Mon Jan 8 17:56:35 2007 From: blino at mandriva.com (Olivier Blin) Date: Tue Jan 9 10:44:49 2007 Subject: [sldev] [PATCH] build fixes for gcc 4 Message-ID: Hello, Here are some patches I had to do while building the Second Life package for Mandriva. I guess they can be reused and applied as is on the sources. -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-src-20070108c-extra.patch Type: text/x-patch Size: 6806 bytes Desc: remove extra qualifiers Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070109/87d901f6/slviewer-src-20070108c-extra.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-src-20070108c-uictrlfactory.patch Type: text/x-patch Size: 2326 bytes Desc: fix LLUICtrlFactory declarations Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070109/87d901f6/slviewer-src-20070108c-uictrlfactory.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-src-20070108c-llembeddeditems.patch Type: text/x-patch Size: 283 bytes Desc: fix LLEmbeddedItems declarations Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070109/87d901f6/slviewer-src-20070108c-llembeddeditems.bin -------------- next part -------------- The Mandriva package contains some others patches that are not as reusable (yacc issues fixes, ELFIO lib naming, fmod disabling, boost lib naming). The patches and spec file are available on our SVN server: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/secondlife/current/ I hope this helps. Thanks for releasing this huge piece of work! -- Olivier Blin - Mandriva From robla at lindenlab.com Tue Jan 9 11:49:00 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jan 9 11:49:42 2007 Subject: [sldev] [PATCH] build fixes for gcc 4 In-Reply-To: References: Message-ID: <45A3F1AC.5040303@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Olivier, This is really, really cool. And, I think we'd really love to incorporate it. However, before our engineers can even look at this, we need to make sure a contribution agreement is in place. See: http://secondlife.com/developers/opensource/submitting Sorry we've gotta be so particular about this. We have to be pretty thorough about this type of thing to be sure we don't run into ownership problems down the road. Thanks Rob On 1/8/07 5:56 PM, Olivier Blin wrote: > Hello, > > Here are some patches I had to do while building the Second Life > package for Mandriva. I guess they can be reused and applied as is > on the sources. > > > ---------------------------------------------------------------------- > > > --- linden/indra/llmedia/llmediaengine.h.extra 2007-01-07 > 23:50:14.000000000 +0100 +++ linden/indra/llmedia/llmediaengine.h > 2007-01-08 19:39:33.000000000 +0100 @@ -101,10 +101,10 @@ static > void process_parcel_media_update ( LLMessageSystem *msg, void ** ); > > > // proxy configuration - void LLMediaEngine::setNetworkProxy ( BOOL > enabledIn, const LLString& addressIn, + void setNetworkProxy ( BOOL > enabledIn, const LLString& addressIn, S32 portIn, S32 socksIn, > const LLString& excludeIn ); > > - void LLMediaEngine::getNetworkProxy ( BOOL& enabledOut, LLString& > addressOut, + void getNetworkProxy ( BOOL& enabledOut, LLString& > addressOut, S32& portOut, S32& socksOut, LLString& excludeOuy ); > > private: --- linden/indra/llmessage/message.h.extra 2007-01-07 > 23:50:14.000000000 +0100 +++ linden/indra/llmessage/message.h > 2007-01-08 19:29:58.000000000 +0100 @@ -750,7 +750,7 @@ static F32 > mTimeDecodesSpamThreshold; // If mTimeDecodes is on, all this many > seconds for each msg decode before spamming static BOOL > mTimeDecodes; // Measure time for all message decodes if TRUE; > > - void LLMessageSystem::init(); // ctor shared initialisation. + > void init(); // ctor shared initialisation. }; > > > --- linden/indra/llrender/llimagegl.h.extra 2007-01-07 > 23:50:15.000000000 +0100 +++ linden/indra/llrender/llimagegl.h > 2007-01-08 19:29:58.000000000 +0100 @@ -169,7 +169,7 @@ > > // STATICS public: - static std::set > LLImageGL::sImageList; + static std::set sImageList; > static S32 sCount; static F32 sLastFrameTime; --- > linden/indra/llui/llfloater.h.extra 2007-01-07 23:50:16.000000000 > +0100 +++ linden/indra/llui/llfloater.h 2007-01-08 > 20:32:12.000000000 +0100 @@ -307,8 +307,8 @@ void > getMinimizePosition( S32 *left, S32 *bottom); void restoreAll(); > // un-minimize all floaters typedef std::set skip_list_t; > - void LLFloaterView::pushVisibleAll(BOOL visible, const > skip_list_t& skip_list = skip_list_t()); - void > LLFloaterView::popVisibleAll(const skip_list_t& skip_list = > skip_list_t()); + void pushVisibleAll(BOOL visible, const > skip_list_t& skip_list = skip_list_t()); + void popVisibleAll(const > skip_list_t& skip_list = skip_list_t()); > > void setCycleMode(BOOL mode); BOOL getCycleMode(); --- > linden/indra/llui/llmenugl.h.extra 2007-01-07 23:50:16.000000000 > +0100 +++ linden/indra/llui/llmenugl.h 2007-01-08 > 21:22:24.000000000 +0100 @@ -424,7 +424,7 @@ virtual void > drawBackground(LLMenuItemGL* itemp, LLColor4& color); virtual void > setVisible(BOOL visible); > > - virtual BOOL LLMenuGL::handleAcceleratorKey(KEY key, MASK mask); > + virtual BOOL handleAcceleratorKey(KEY key, MASK mask); > > LLMenuGL* getChildMenuByName(const LLString& name, BOOL recurse) > const; --- linden/indra/newview/lljoystickbutton.h.extra > 2007-01-07 23:50:22.000000000 +0100 +++ > linden/indra/newview/lljoystickbutton.h 2007-01-08 > 23:58:29.000000000 +0100 @@ -94,7 +94,7 @@ > > virtual void onHeldDown(); > > - static LLView* LLJoystickAgentTurn::fromXML(LLXMLNodePtr node, > LLView *parent, LLUICtrlFactory *factory); + static LLView* > fromXML(LLXMLNodePtr node, LLView *parent, LLUICtrlFactory > *factory); > > }; > > @@ -115,7 +115,7 @@ virtual void onHeldDown(); virtual void > onMouseUp(); > > - static LLView* LLJoystickAgentSlide::fromXML(LLXMLNodePtr node, > LLView *parent, LLUICtrlFactory *factory); + static LLView* > fromXML(LLXMLNodePtr node, LLView *parent, LLUICtrlFactory > *factory); }; > > > --- linden/indra/newview/llwearable.h.extra 2007-01-07 > 23:50:22.000000000 +0100 +++ linden/indra/newview/llwearable.h > 2007-01-08 23:58:53.000000000 +0100 @@ -131,8 +131,8 @@ > LLPtrSkipMap mVisualParamMap; // maps visual param id to > weight LLPtrSkipMap mTEMap; // maps TE to Image ID > > > - static const char* LLWearable::sTypeName[ WT_COUNT ]; - static > const char* LLWearable::sTypeLabel[ WT_COUNT ]; + static const > char* sTypeName[ WT_COUNT ]; + static const char* sTypeLabel[ > WT_COUNT ]; }; > > #endif // LL_LLWEARABLE_H --- > linden/indra/newview/llnotify.h.extra 2007-01-07 23:50:21.000000000 > +0100 +++ linden/indra/newview/llnotify.h 2007-01-08 > 23:59:56.000000000 +0100 @@ -61,7 +61,7 @@ /*virtual*/ void > setVisible(BOOL visible); > > protected: - LLNotifyBox::LLNotifyBox(const LLString& xml_desc, > const LLString::format_map_t& args, + LLNotifyBox(const LLString& > xml_desc, const LLString::format_map_t& args, notify_callback_t > callback, void* user_data, const option_list_t& extra_options = > option_list_t(), BOOL layout_script_dialog = FALSE); --- > linden/indra/newview/llfloatercustomize.h.extra 2007-01-07 > 23:50:23.000000000 +0100 +++ > linden/indra/newview/llfloatercustomize.h 2007-01-08 > 23:59:30.000000000 +0100 @@ -136,7 +136,7 @@ > > protected: - static void* > LLFloaterCustomize::createWearablePanel(void* userdata); + static > void* createWearablePanel(void* userdata); void > initWearablePanels(); void initScrollingPanelList(); --- > linden/indra/newview/lldynamictexture.h.extra 2007-01-07 > 23:50:21.000000000 +0100 +++ > linden/indra/newview/lldynamictexture.h 2007-01-09 > 00:18:51.000000000 +0100 @@ -79,7 +79,7 @@ LLCoordGL mOrigin; > > LLCamera mCamera; - static LLLinkedList > LLDynamicTexture::sInstances[ LLDynamicTexture::ORDER_COUNT ]; + > static LLLinkedList sInstances[ > LLDynamicTexture::ORDER_COUNT ]; static S32 sNumRenders; }; > > --- linden/indra/newview/llpanelinventory.h.extra 2007-01-07 > 23:50:22.000000000 +0100 +++ > linden/indra/newview/llpanelinventory.h 2007-01-09 > 00:35:21.000000000 +0100 @@ -77,7 +77,7 @@ InventoryObjectList* > inventory, S32 serial_num, void* user_data); - void > LLPanelInventory::updateInventory(); + void updateInventory(); void > createFolderViews(LLInventoryObject* inventory_root, > InventoryObjectList& contents); void > createViewsForCategory(InventoryObjectList* inventory, > LLInventoryObject* parent, --- > linden/indra/newview/llpanelcontents.h.extra 2007-01-07 > 23:50:23.000000000 +0100 +++ linden/indra/newview/llpanelcontents.h > 2007-01-09 00:37:59.000000000 +0100 @@ -40,7 +40,7 @@ class > LLPanelContents : public LLPanel { public: - virtual BOOL > LLPanelContents::postBuild(); + virtual BOOL postBuild(); > LLPanelContents(const std::string& name); virtual > ~LLPanelContents(); > > --- linden/indra/newview/llviewertexteditor.cpp.extra 2007-01-07 > 23:50:24.000000000 +0100 +++ > linden/indra/newview/llviewertexteditor.cpp 2007-01-09 > 00:54:37.000000000 +0100 @@ -405,7 +405,7 @@ class > LLTextCmdInsertEmbeddedItem : public LLTextCmd { public: - > LLTextCmdInsertEmbeddedItem::LLTextCmdInsertEmbeddedItem( S32 pos, > LLInventoryItem* item ) + LLTextCmdInsertEmbeddedItem( S32 pos, > LLInventoryItem* item ) : LLTextCmd(pos, FALSE), mExtCharValue(0) { > > > ---------------------------------------------------------------------- > > > --- linden/indra/llui/llviewborder.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/llviewborder.h > 2007-01-08 21:17:08.000000000 +0100 @@ -36,6 +36,7 @@ #include > "llimagegl.h" #include "llxmlnode.h" > > +class LLUICtrlFactory; class LLUUID; > > > --- linden/indra/llui/llbutton.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/llbutton.h > 2007-01-08 21:21:27.000000000 +0100 @@ -37,6 +37,8 @@ #include > "llimage.h" #include "lluistring.h" > > +class LLUICtrlFactory; + // // Constants // --- > linden/indra/llui/lltextbox.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/lltextbox.h > 2007-01-08 21:41:20.000000000 +0100 @@ -35,6 +35,8 @@ #include > "lluistring.h" > > > +class LLUICtrlFactory; + class LLTextBox : public LLUICtrl { --- > linden/indra/llui/lliconctrl.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/lliconctrl.h > 2007-01-08 21:27:53.000000000 +0100 @@ -34,6 +34,7 @@ #include > "stdenums.h" #include "llimagegl.h" > > +class LLUICtrlFactory; class LLTextBox; > > // --- linden/indra/llui/lltexteditor.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/lltexteditor.h > 2007-01-08 21:29:22.000000000 +0100 @@ -39,6 +39,7 @@ #include > "lleditmenuhandler.h" #include "lldarray.h" > > +class LLUICtrlFactory; class LLFontGL; class LLScrollbar; class > LLViewBorder; --- > linden/indra/llui/llscrollcontainer.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/llscrollcontainer.h > 2007-01-08 21:30:40.000000000 +0100 @@ -46,6 +46,7 @@ // This class > is a decorator class. > //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > +class LLUICtrlFactory; class LLScrollbar; class LLViewBorder; > > --- linden/indra/llui/llslider.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/llslider.h > 2007-01-08 21:31:48.000000000 +0100 @@ -31,6 +31,8 @@ #include > "lluictrl.h" #include "v4color.h" > > +class LLUICtrlFactory; + class LLSlider : public LLUICtrl { > public: --- linden/indra/llui/llspinctrl.h.uictrlfactory 2007-01-07 > 23:50:16.000000000 +0100 +++ linden/indra/llui/llspinctrl.h > 2007-01-08 21:37:36.000000000 +0100 @@ -46,6 +46,7 @@ // // Classes > // +class LLUICtrlFactory; class LLFontGL; class LLButton; class > LLTextBox; > > ---------------------------------------------------------------------- > > > --- linden/indra/newview/llviewertexteditor.h.llembeddeditems > 2007-01-07 23:50:21.000000000 +0100 +++ > linden/indra/newview/llviewertexteditor.h 2007-01-09 > 00:28:11.000000000 +0100 @@ -31,6 +31,7 @@ #include > "lltexteditor.h" > > class LLInventoryItem; +class LLEmbeddedItems; > > > // > > ---------------------------------------------------------------------- > > > > The Mandriva package contains some others patches that are not as > reusable (yacc issues fixes, ELFIO lib naming, fmod disabling, > boost lib naming). The patches and spec file are available on our > SVN server: > http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/secondlife/current/ > > > I hope this helps. > > Thanks for releasing this huge piece of work! > > > ---------------------------------------------------------------------- > > > _______________________________________________ Click here to > unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFo/GsPd430ImZiAMRAnEKAJ9il1VgA8gQV8RYOGdPwYRHAxrtJgCffZDT MdsTOUXSgg07TlH0ySHXddg= =d43Y -----END PGP SIGNATURE----- From blino at mandriva.com Tue Jan 9 12:08:46 2007 From: blino at mandriva.com (Olivier Blin) Date: Tue Jan 9 12:08:47 2007 Subject: [sldev] [PATCH] build fixes for gcc 4 In-Reply-To: <45A3F1AC.5040303@lindenlab.com> (Rob Lanphier's message of "Tue\, 09 Jan 2007 11\:49\:00 -0800") References: <45A3F1AC.5040303@lindenlab.com> Message-ID: Rob Lanphier writes: > Hi Olivier, > > This is really, really cool. And, I think we'd really love to > incorporate it. However, before our engineers can even look at this, > we need to make sure a contribution agreement is in place. See: > http://secondlife.com/developers/opensource/submitting Bah, these patches are licensed under WTFPL anyway :-p > Sorry we've gotta be so particular about this. We have to be pretty > thorough about this type of thing to be sure we don't run into > ownership problems down the road. Ok, I'll take care of the contribution agreement form tomorrow. My Second Life packages are currently being uploaded in the contrib repositories of the Mandriva Cooker development distribution. After some patches, it builds fine on both i586 and x86_64 architectures with gcc 4.1.2 Thanks for your comments! -- Olivier Blin - Mandriva From blino at mandriva.com Tue Jan 9 12:12:55 2007 From: blino at mandriva.com (Olivier Blin) Date: Tue Jan 9 12:12:56 2007 Subject: [sldev] [PATCH] x86_64 build fixes Message-ID: Hi, Here is a patch that fixes some x86_64 build issues (with gcc 4), some pointers are incorrectly cast to integers. -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-src-20070108c-x86_64.patch Type: text/x-patch Size: 2054 bytes Desc: fix casts on x86_64 Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070109/3205a461/slviewer-src-20070108c-x86_64.bin -------------- next part -------------- Regards -- Olivier Blin - Mandriva From damektretiak at gmail.com Tue Jan 9 13:44:22 2007 From: damektretiak at gmail.com (Damek Tretiak) Date: Tue Jan 9 13:44:29 2007 Subject: [sldev] Introduction and Question Message-ID: Hello everyone, Quick introduction: I'm Patrick Ward; aka Damek Tretiak in SL. I run the slquery.com site and am working on a few other projects. I'm excited about the open source initiative. Kudos to LL for having the vision and strength to follow through with this. It's a big undertaking. I realize that the source code repository and syncing issue is still up in the air. But, I'm wondering if the open source release corresponds to the release that is schedule on Wed. of this week. Are there items in the Wed. release that are not in the open source code that was released yesterday? Also, is the new capabilities subsystem in the open source version? Or is that primarily on the server-side? I haven't gone through everything yet, so if that's in the wiki or code i apologize. I did compile everything successfully on both win32 and mac osx though. Great job on the compile instructions and also for bundling up the libraries for us. I'll pop in from time to time and contribute where I can. Thanks for the opportunities. ~Damek Tretiak -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070109/6f651d33/attachment.htm From annagulaev at gmail.com Tue Jan 9 13:55:05 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Tue Jan 9 13:55:07 2007 Subject: [sldev] commercial license Message-ID: I emailed the address given by LL to request info about the commercial-use licensing and did not get a response. Rob, has such info even been prepared? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070109/d47c73fd/attachment.htm From phoenix at secondlife.com Tue Jan 9 14:47:52 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Jan 9 14:48:05 2007 Subject: [sldev] Introduction and Question In-Reply-To: References: Message-ID: On 2007 Jan 9, at 13:44, Damek Tretiak wrote: > I realize that the source code repository and syncing issue is > still up in the air. But, I'm wondering if the open source release > corresponds to the release that is schedule on Wed. of this week. > Are there items in the Wed. release that are not in the open source > code that was released yesterday? Also, is the new capabilities > subsystem in the open source version? Or is that primarily on the > server-side? The wednesday release will include things not in the current open source release. We hope to have a new source bundle late in the day after the release. There is capability support in the open source viewer, but the server is responsible for granting capabilities and none have been enabled yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070109/4f900e0d/PGP.pgp From signore at autistiche.org Tue Jan 9 15:15:07 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Tue Jan 9 15:15:14 2007 Subject: [sldev] Missing glu.h - Compile failure on Ubuntu 6.10 Message-ID: hi stefan and all. stefan, did you try removing mesa-common-dev? i'm on ubuntu edgy (6.10) too - i met the same error during my try-and-retry process (eventually i managed to get in world :)))) i have installed two of the packages you name: libgl1-mesa-dev 6.5.1~20060817-0ubuntu3 libglu1-mesa-dev 6.5.1~20060817-0ubuntu3 ..but i don't have mesa-commons-dev in my system, and it looks it conflicts in yours one. some things i do on debian-based distro when i'm desperate: - re-check my sources.list file and do apt-get update - try using aptitude or synaptic instead of apt-get my sources.list file: deb http://it.archive.ubuntu.com/ubuntu/ edgy main restricted universe multiverse deb http://it.archive.ubuntu.com/ubuntu/ edgy-updates main restricted universe multiverse deb http://security.ubuntu.com/ubuntu edgy-security main restricted universe multiverse and here is what i did to compile the viewer code. unpacked: * tar xzf slviewer-src-20070108c.tar.gz * tar xzf slviewer-linux-libs-20070108c.tar.gz * tar xzf fmodapi375linux.tar.gz copied required FMOD headers and libraries into the Second Life Viewer source tree: * cd into the FMOD directory * cp api/inc/* ../linden/libraries/i686-linux/include/ * cp api/libfmod-3.75.so ./linden/libraries/i686-linux/lib_release_client/ installed via Synaptic: * gcc-3.4 gcc-3.4-base g++-3.4 scons * libglu1-mesa-dev libgl1-mesa-dev mesa-commons-dev * flex bison then I tried to run scons. It couldn?t find gtk/gtk.h, so I edited the indra/SConstruct file, removing the leading spaces from the 6 ? ../libraries/? strings from around line 187 onwards. now, from the indra directory: * cp ../scripts/messages/message_template.msg newview/app_settings/ at this point, I managed to get in world. some blogging i made about it: http://tinyurl.com/yhm822 or http://signore.wordpress.com/2007/01/08/compiling-the-second-life-viewer-source-code-on-ubuntu-edgy http://tinyurl.com/yh7lkz or http://www.secondlifeitalia.com/blog/index.php/2007/01/08/il-client-di-second-life-diventa-software-libero/ http://tinyurl.com/yff9sg or http://www.secondlifeitalia.com/blog/index.php/2007/01/08/second-life-open-source-si-aprono-le-danze/ bye signore iredell From peekay at targetomega.com Tue Jan 9 19:13:18 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Tue Jan 9 19:13:25 2007 Subject: [sldev] Contributions email not working Message-ID: <3869.70.49.105.201.1168398798.squirrel@webmail.bluewax.com> FYI -peekay ----- Transcript of session follows ----- ... while talking to alan.lindenlab.com.: >>> DATA <<< 550 : Recipient address rejected: User unknown in local recipient table 550 5.1.1 ... User unknown <<< 554 Error: no valid recipients From ginsburg at intolerable.org Tue Jan 9 20:58:21 2007 From: ginsburg at intolerable.org (Intolerable Ginsburg) Date: Tue Jan 9 20:58:33 2007 Subject: [sldev] Anyone with compile errors on Windows? In-Reply-To: References: Message-ID: <45A4726D.3030605@intolerable.org> Tonight tried to compile the source, but I'm getting a few fatal errors: 'lscript_compile fatal error C1083: Cannot open source file: '.\lex_yy.cpp': No such file or directory' 'lscript_compile fatal error C1083: Cannot open source file: '.\ytab.cpp': No such file or directory' Looking under the source files for lscript_compile in VS, the files are listed, but they weren't in the source code zip. Missing also appears to be generated_lex_yy.hpp and generated_ytab.hpp. Anyone else see this or am I missing something here? Thanks! From deepak at adroit-inc.com Tue Jan 9 22:04:33 2007 From: deepak at adroit-inc.com (Deepak) Date: Tue Jan 9 22:04:39 2007 Subject: [sldev] Anyone with compile errors on Windows? References: <45A4726D.3030605@intolerable.org> Message-ID: <000901c7347d$34ce4c40$a201a8c0@abs> Ignore these errors. You shld be able to build the viewer besides these errors. Its worked on my machine. - Deepak ----- Original Message ----- From: "Intolerable Ginsburg" To: Sent: Wednesday, January 10, 2007 10:28 AM Subject: [sldev] Anyone with compile errors on Windows? > Tonight tried to compile the source, but I'm getting a few fatal errors: > > 'lscript_compile fatal error C1083: Cannot open source file: > '.\lex_yy.cpp': No such file or directory' > 'lscript_compile fatal error C1083: Cannot open source file: '.\ytab.cpp': > No such file or directory' > > Looking under the source files for lscript_compile in VS, the files are > listed, but they weren't in the source code zip. Missing also appears to > be generated_lex_yy.hpp and generated_ytab.hpp. Anyone else see this or am > I missing something here? > > Thanks! > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robla at lindenlab.com Tue Jan 9 22:58:36 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jan 9 22:59:15 2007 Subject: [sldev] Version control repository Message-ID: <45A48E9C.8040108@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, A hot topic on IRC, in-world, and everywhere else seems to be "is Linden Lab going to provide a version control repository, and if so, when?" The answer is "we need a spec first". What's so hard about that? Well, I want to work with the community on defining the spec, and come up with something that is going to be the most useful for everyone. The options are spelled out here: http://wiki.secondlife.com/wiki/Version_control_repository ...as are some of the discussions (hit the "discussion" tab to view). The safe option these days is Subversion. It's really widely supported, has a ton of tools for all platforms, and really seems to have hit critical mass. We use it internally, and as near as I know, everyone seems reasonably happy with it. There hasn't been any chatter (that I've heard) about replacing it any time soon. The command line is very sensible, and the model is reasonably easy to understand for anyone who has worked with version control systems before. In particular, the command line interface was designed to be similar (but not slavishly identical) to the venerable CVS. There's also lots of nice tools and extensions that work with it, and I think a reasonable number of IDEs support it now (fact check, aisle 7) The trendy thing these days in version control systems is distributed control systems, first popularized by BitKeeper, and more recently made popular by the explosion of options such as git, darcs, svk, bazaar, and Mercurial. What's interesting about these systems is that they make it much easier for ad hoc teams to collaborate, each developer publishing a mini repository, and provide tools for people to deal with lots of little patchsets from a lot of different sources. These tools aren't as mature as Subversion, but they are much more powerful. The command line interface on many of these is quite difficult (that's at least my experience with bazaar), but I've heard good things about Mercurial, and looking at the quick start guide, it seems the most intuitive of the open source options. Svk is also interesting, as it's layered on top of Subversion (more below on why that can be good). While Subversion works great for, say, a team of professional developers all in the same building working under the same management on the same or at least coordinated set of projects, it isn't as well suited to collaboration of a lot of developers each working on their own pet feature that want to pick and choose which other developers they want to collaborate with. Dealing with branches gets really tedious really quickly...get above a dozen, and you've got a bit of a nightmare. Merging tools are o.k....certainly better than CVS, but things are much easier when everyone stays on the same branch. Subversion would be nice choice because that's what Linden Lab uses internally. Reducing drag on LL developers is an important consideration; in addition to my selfish motive to maintain a good relationship with my co-workers, I want to have as few mental or logistical obstacles for LL developers to work on the open source side of the firewall. Mercurial is interesting to me, because it seems like a great blend of distributed system and sensible interface. My knowledge of Mercurial is a little thin, though, so I'd be interested in hearing from people who have spent quality time with it. Mercurial might be intriguing for LL devs, and the open source repository may be seen as a great way to try it out and maybe even get religion on distributed revision systems. However, it may be yet another friggin' half-working tool to learn the quirks for. Hard to say; the devil is probably in the details. Svk might be a great compromise between the two. However, I have no real experience with svk either. The community seems divided on the issue. One in-world discussion at Hooper was leaning pretty heavily toward a distributed tool like Mercurial. Another discussion at Pooley after the town hall wound down seemed to be a much more Subversion-leaning crowd. I'm truly on the fence on this topic, perhaps leaning slightly toward Mercurial, because I think a distributed system would be a better fit. I am interested in having a conversation about this before making a decision. Whatever we decide, I want to stick with it for a couple of years at least, so let's make sure we do enough homework to avoid buyer's remorse. Thoughts? Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpI6cPd430ImZiAMRAnBlAJ0eEWr+4GMojMcNThO3W3JNSOP/5gCfVfJE 2E5tF2trs57wjAmOINvO7fE= =wo0o -----END PGP SIGNATURE----- From sl at phoca.com Tue Jan 9 23:08:11 2007 From: sl at phoca.com (Second Life) Date: Tue Jan 9 23:08:22 2007 Subject: [sldev] Anyone with compile errors on Windows? References: <45A4726D.3030605@intolerable.org> Message-ID: <000b01c73486$17245eb0$641e140a@sanmiguel> You need to have cygwin installed as suggested int he how to compile on windows. "When you run the cygwin setup utility make sure you have selected to install patchutil, flex, and bison (all located under "devel") which are not part of the default install. " I would leave the default install at c:\cygwin as well. You may not be able to script without compiling this maybe? Farallon ----- Original Message ----- From: "Intolerable Ginsburg" To: Sent: Tuesday, January 09, 2007 8:58 PM Subject: [sldev] Anyone with compile errors on Windows? > Tonight tried to compile the source, but I'm getting a few fatal errors: > > 'lscript_compile fatal error C1083: Cannot open source file: > '.\lex_yy.cpp': No such file or directory' > 'lscript_compile fatal error C1083: Cannot open source file: '.\ytab.cpp': > No such file or directory' > > Looking under the source files for lscript_compile in VS, the files are > listed, but they weren't in the source code zip. Missing also appears to > be generated_lex_yy.hpp and generated_ytab.hpp. Anyone else see this or am > I missing something here? > > Thanks! > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From faassen at startifact.com Wed Jan 10 02:12:06 2007 From: faassen at startifact.com (Martijn Faassen) Date: Wed Jan 10 02:12:08 2007 Subject: [sldev] Version control repository In-Reply-To: <45A48E9C.8040108@lindenlab.com> References: <45A48E9C.8040108@lindenlab.com> Message-ID: <8928d4e90701100212x3970986fw44c7c650c5e71bac@mail.gmail.com> Hey, I was going to comment about version control systems but I think I want to stick to my main message: Linden Lab knows subversion. Experimenting with new version control systems at a time of major transition like this may be too much of a change. People can still experiment with other version control systems in the periphery around it. Even though I'm participating in it myself now, I'm worried that a debate about version control systems is coming a bit too early. It's a potentially one of those meta discussions like what is the best editor and you'd typically want to avoid these on a development list, as they never end anyway. Time is needed to let a development community coalesce first so that these discussions don't dominate. The openness is appreciated but I'm worried it might easily turn into paralysis. I would prefer it if Linden Lab just picked a version control system that they already have experience with and said: this is it, and that our discussions focus more on the code itself. Regards, Martijn From sbg at acw.com Wed Jan 10 02:25:44 2007 From: sbg at acw.com (sbg@acw.com) Date: Wed Jan 10 02:25:47 2007 Subject: [sldev] Anyone with compile errors on Windows? In-Reply-To: <45A4726D.3030605@intolerable.org> References: <45A4726D.3030605@intolerable.org> Message-ID: <1918.24.63.25.238.1168424744.squirrel@www.acw.com> Attached are the three missing files. Put them llscript_compile and delete the llscript_compile_fb project from the indra_complete solution. llscript_compile_fb's (fb = flex bison) only task was to build them from indra.l and indra.y and it will delete them and try to rebuild them if you leave this project in the solution. This eliminates the need for cygwin. OTOH, you can't play with the grammar. Cheers, Scott > Tonight tried to compile the source, but I'm getting a few fatal errors: > > 'lscript_compile fatal error C1083: Cannot open source file: > '.\lex_yy.cpp': No such file or directory' > 'lscript_compile fatal error C1083: Cannot open source file: > '.\ytab.cpp': No such file or directory' > > Looking under the source files for lscript_compile in VS, the files are > listed, but they weren't in the source code zip. Missing also appears to > be generated_lex_yy.hpp and generated_ytab.hpp. Anyone else see this or > am I missing something here? > > Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: SLfb.zip Type: application/x-zip-compressed Size: 69491 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070110/cd9b3176/SLfb-0001.bin From peekay at targetomega.com Wed Jan 10 02:48:53 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Wed Jan 10 02:48:55 2007 Subject: [sldev] Version control repository In-Reply-To: <45A48E9C.8040108@lindenlab.com> References: <45A48E9C.8040108@lindenlab.com> Message-ID: <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> Hi Rob, My own view is that LL should first provide us with read-only access to the official branches of the client code (-dev branch, -stable branch, etc.) Let's call this the "official repository" and contains only Linden released code and those slated for inclusion in the next official viewer. Then let the community-at-large decide on its own repositories, for its own projects. Some may group together and decide to use BitKeeper on a large collaborative effort. Individual developers may choose to just track the official repository. Companies may opt to sync official releases into their internal Perforce system, or ClearCase, etc. But the official repository remains distinct, clean, separate and authoritative. So my suggestion would be for LL to move all the client-related code from the internal server into a new subversion-based repository (in a DMZ or mirrored from an internal server) and give the community read privileges to it. All commits are done by Lindens, based on a well-defined submission and review process. In the near or far future, LL may vet external developers for direct commit privileges into the official repository. However, before that can happen, other topics (like the release process) need to be thoroughly hashed out. At that point we would need greater visibility into any planned server-side changes which may impact the client. I would also suggest periodic automated builds of the official repository, to make snapshot executables available for the greater SL community. My $0.02, -peekay From sbg at acw.com Wed Jan 10 02:53:25 2007 From: sbg at acw.com (sbg@acw.com) Date: Wed Jan 10 02:53:28 2007 Subject: [sldev] Sim for newview? Message-ID: <2073.24.63.25.238.1168426405.squirrel@www.acw.com> When I try to connect to SL with newview I get the "SL temporarily closed for maintenance" message for all sims except DMZ for which I get server not found. Is there a particular sim that newview should be pointed at? Cheers, Scott From blino at mandriva.com Wed Jan 10 03:02:20 2007 From: blino at mandriva.com (Olivier Blin) Date: Wed Jan 10 03:02:31 2007 Subject: [sldev] Version control repository In-Reply-To: <45A48E9C.8040108@lindenlab.com> (Rob Lanphier's message of "Tue\, 09 Jan 2007 22\:58\:36 -0800") References: <45A48E9C.8040108@lindenlab.com> Message-ID: Rob Lanphier writes: > Hi everyone, > > A hot topic on IRC, in-world, and everywhere else seems to be "is > Linden Lab going to provide a version control repository, and if so, > when?" The answer is "we need a spec first". What's so hard about > that? Well, I want to work with the community on defining the spec, > and come up with something that is going to be the most useful for > everyone. > > The options are spelled out here: > http://wiki.secondlife.com/wiki/Version_control_repository > > ...as are some of the discussions (hit the "discussion" tab to view). > > The safe option these days is Subversion. It's really widely > supported, has a ton of tools for all platforms, and really seems to > have hit critical mass. We use it internally, and as near as I know, > everyone seems reasonably happy with it. There hasn't been any > chatter (that I've heard) about replacing it any time soon. Hello, If you already use Subversion internally, it's probably the safest option. People that love distributed repositories will still be able to use layers on top of svn, such as svk or git-svn. By the way, the Gnome project switched to SVN recently, and they had to consider the same kind of "distributed or not" matter: http://live.gnome.org/SubversionFAQ#head-a32b552ef3fa398d571bcb25ab95a7647d7143f5 Just my thoughts -- Olivier Blin - Mandriva From tleiades at hotmail.com Wed Jan 10 03:15:54 2007 From: tleiades at hotmail.com (Anton Lauridsen) Date: Wed Jan 10 03:16:02 2007 Subject: [sldev] Goto bug report in jira Message-ID: Hi I thought that a good place to start getting to know my way around the source code would be fixing a few of the simpler bugs. To my dismay, I noticed that a bug has been reported about the use of goto's. Now!! why is this to my dismay? According to the coding standards at https://wiki.secondlife.com/wiki/Coding_standard the use of goto's are not prohibited, consequently I have a hard time seeing how this can be a bug. I agree that the opinions on the use of goto's vary, I don't believe anything good will come of entering into such a discussion, but I would like to suggest that the bugs reported in jira should be focussed around functional breaches. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070110/2a34851d/attachment.htm From kitten at ngi.it Wed Jan 10 03:37:40 2007 From: kitten at ngi.it (Kitten Lulu) Date: Wed Jan 10 03:37:52 2007 Subject: [sldev] Version control repository In-Reply-To: <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> References: <45A48E9C.8040108@lindenlab.com> <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> Message-ID: <45A4D004.7060004@ngi.it> Peekay Semyorka ha scritto: > Hi Rob, > > My own view is that LL should first provide us with read-only access to > the official branches of the client code (-dev branch, -stable branch, > etc.) Let's call this the "official repository" and contains only Linden > released code and those slated for inclusion in the next official viewer. > > I think choosing what LL already knows is a good idea and I agree that read-only access to an official/authoritative source code repository is a priority. I wonder if there is a migration path that would allow to move from (or augment) a Subversion repository to a SVK repository. Is there anyone with significant experience with svk who can comment? From tleiades at hotmail.com Wed Jan 10 03:58:17 2007 From: tleiades at hotmail.com (Duffy Langdon) Date: Wed Jan 10 03:58:22 2007 Subject: [sldev] Version control repository References: <45A48E9C.8040108@lindenlab.com><2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> <45A4D004.7060004@ngi.it> Message-ID: I agree that getting access to a VCS system, where the stable and head branches can be retrieved is a priority, otherwise the code made public will quickly grow stale. Almost all on this list should be able to set up their own sandbox, if they want/need it. So if Linden Lab is already using SVN, by all means, continue to do so, it will cause less overall confusion. ----- Original Message ----- From: "Kitten Lulu" To: Sent: Wednesday, January 10, 2007 12:37 PM Subject: Re: [sldev] Version control repository > Peekay Semyorka ha scritto: >> Hi Rob, >> >> My own view is that LL should first provide us with read-only access to >> the official branches of the client code (-dev branch, -stable branch, >> etc.) Let's call this the "official repository" and contains only Linden >> released code and those slated for inclusion in the next official viewer. >> >> > I think choosing what LL already knows is a good idea and I agree that > read-only access to an official/authoritative source code repository is a > priority. > > I wonder if there is a migration path that would allow to move from (or > augment) a Subversion repository to a SVK repository. Is there anyone with > significant experience with svk who can comment? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From peekay at targetomega.com Wed Jan 10 05:17:41 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Wed Jan 10 05:17:52 2007 Subject: [sldev] Way to enable JIRA emails? Message-ID: <1999.70.49.105.201.1168435061.squirrel@webmail.bluewax.com> Can JIRA emails be enabled so we can get notification when an issue we're working on is updated? Thanks, -peekay From gismo at igor.franken.de Wed Jan 10 06:32:39 2007 From: gismo at igor.franken.de (Gismo C.) Date: Wed Jan 10 05:32:21 2007 Subject: [sldev] source release and security questions Message-ID: <20070110143239.GE2081@andromeda.hyte.de> Hello there, first thanks a lot for the Code release. This is mutch more interessting than a blackbox on my System. There were some questions about the open source Client concerning security of the Grid. I think like in every newly release Open Source Project, there will be a first wave with much fixes and enhancments. One already startet to post about some interessting bits: http://blog.fefe.de/?ts=bb5cad1f It is in German, but you can have a look at the Code parts and you will probably know what he is meaning. Thanks for this Project, Gismo From Stef.Wade at stots.de Wed Jan 10 05:58:43 2007 From: Stef.Wade at stots.de (Stef Wade) Date: Wed Jan 10 05:59:10 2007 Subject: [sldev] Version control repository In-Reply-To: <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> References: <45A48E9C.8040108@lindenlab.com> <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> Message-ID: <45A4F113.3000300@stots.de> Peekay Semyorka schrieb: > Hi Rob, > > My own view is that LL should first provide us with read-only access to > the official branches of the client code (-dev branch, -stable branch, > etc.) Let's call this the "official repository" and contains only Linden > released code and those slated for inclusion in the next official viewer. I second that opinion. Since all contributions to the official LL-viewer will need the "Contribution Agreement" to be signed, that would be just logical. It would match the current workflow (contributers post changes to LL, LL incorporates) As said before: I am not one of those who will contribute much code, so weight my opinion accordingly, Stefan -- http://LinuxBasics.org http://Krone-Neuenburg.com http://Stefan.Waidele.info http://sl.stots.de/blog From tleiades at hotmail.com Wed Jan 10 06:05:07 2007 From: tleiades at hotmail.com (Duffy Langdon) Date: Wed Jan 10 06:05:15 2007 Subject: [sldev] source release and security questions References: <20070110143239.GE2081@andromeda.hyte.de> Message-ID: I have just done a quick check of the code, and have found the following: /indra/newview/llinventorymodel.cpp: system(buffer);is actually outcommented, i.e. the code is never compiled nor executed../indra/newview/llstartup.cpp: system(update_exe_path.c_str());is executed under Darwin, but the code on first inspection seems to be safe, it probably should be checked by someone more experienced in the code, but first impression is that it is harmless./indra/newview/viewer.cpp: system(command_str.c_str());is executed under Darwin, the code - on first inspection - looks even more innocent than the first one.My impression from reading the blog and the examples he found, is that he has notmade any effort to understand the code, but is making some unfounded or - atleast - ill founded judgements about the source code, without inspecting it.Open source is a two edged sword, it means everybody can look for vulerabilities,both the whitehatters and the blackhatters :-)The source code I have examined, appears to be well written, especially consideringthe age and the number of people who has been involved. But this is really based onlyon a cursory examination, and not an indepth analysis.----- Original Message ----- From: "Gismo C." To: Sent: Wednesday, January 10, 2007 3:32 PM Subject: [sldev] source release and security questions > Hello there, > > first thanks a lot for the Code release. This is mutch more interessting > than a blackbox on my System. > > There were some questions about the open source Client concerning security > of the Grid. > > I think like in every newly release Open Source Project, there will be a > first wave with much fixes and enhancments. > > One already startet to post about some interessting bits: > http://blog.fefe.de/?ts=bb5cad1f > > It is in German, but you can have a look at the Code parts and you will > probably > know what he is meaning. > > Thanks for this Project, > Gismo > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From peekay at targetomega.com Wed Jan 10 06:09:04 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Wed Jan 10 06:09:11 2007 Subject: [sldev] source release and security questions In-Reply-To: <20070110143239.GE2081@andromeda.hyte.de> References: <20070110143239.GE2081@andromeda.hyte.de> Message-ID: <4689.70.49.105.201.1168438144.squirrel@webmail.bluewax.com> Please read the JIRA entry: http://wiki.secondlife.com/wiki/Security_issues If there are actual security problems, I would constructively email security@lindenlab.com as requested. I think everyone understands that discussions here, in open blogs, etc., should be kept at a more general level until issues are patched. -peekay From gismo at igor.franken.de Wed Jan 10 08:27:02 2007 From: gismo at igor.franken.de (Gismo C.) Date: Wed Jan 10 07:26:34 2007 Subject: [sldev] source release and security questions In-Reply-To: <4689.70.49.105.201.1168438144.squirrel@webmail.bluewax.com> References: <20070110143239.GE2081@andromeda.hyte.de> <4689.70.49.105.201.1168438144.squirrel@webmail.bluewax.com> Message-ID: <20070110162702.GG2081@andromeda.hyte.de> On Wed, Jan 10, 2007 at 02:09:04PM -0000, Peekay Semyorka wrote: > > I think everyone understands that discussions here, in open blogs, etc., > should be kept at a more general level until issues are patched. > I agree with you, the usual 10 days should be left to any programmer to response. The mentiond code in the Blog posting i linked is for sure rudimentary, this are just a few hints, regarding functions that are critical in common, but not necessarily trigger a security thread. There will be more, but that is to my point of view, and to my experince a good thing for the ongoing development and the security of the whole project. > -peekay > > gismo From phoenix at secondlife.com Wed Jan 10 09:44:12 2007 From: phoenix at secondlife.com (Phoenix) Date: Wed Jan 10 09:44:25 2007 Subject: [sldev] Sim for newview? In-Reply-To: <2073.24.63.25.238.1168426405.squirrel@www.acw.com> References: <2073.24.63.25.238.1168426405.squirrel@www.acw.com> Message-ID: <8EFC4E2B-C321-409C-B338-AF9EE7960562@secondlife.com> Currently, agni is the only grid open for connections. We will probably be opening siva for test use with the open source client. On 2007 Jan 10, at 02:53, sbg@acw.com wrote: > When I try to connect to SL with newview I get the "SL temporarily > closed > for maintenance" message for all sims except DMZ for which I get > server > not found. > > Is there a particular sim that newview should be pointed at? > > Cheers, Scott > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070110/48139701/PGP.pgp From robla at lindenlab.com Wed Jan 10 10:59:44 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jan 10 11:00:22 2007 Subject: [sldev] Contributions email not working In-Reply-To: <3869.70.49.105.201.1168398798.squirrel@webmail.bluewax.com> References: <3869.70.49.105.201.1168398798.squirrel@webmail.bluewax.com> Message-ID: <45A537A0.8040508@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argh...sorry about that, I'll get that fixed. Just send them to me personally for now. Thanks Rob On 1/9/07 7:13 PM, Peekay Semyorka wrote: > FYI > > -peekay > > ----- Transcript of session follows ----- > ... while talking to alan.lindenlab.com.: >>>> DATA > <<< 550 : Recipient address rejected: User > unknown in > local recipient table > 550 5.1.1 ... User unknown > <<< 554 Error: no valid recipients > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpTegPd430ImZiAMRAq/FAJ0T5entAsefxjEEmZFxlEk+4MiKFgCeMk4B pZd74zsRcM7SJgarc4kKxiM= =CW06 -----END PGP SIGNATURE----- From Stef.Wade at stots.de Wed Jan 10 11:28:49 2007 From: Stef.Wade at stots.de (Stef Wade) Date: Wed Jan 10 11:29:04 2007 Subject: [sldev] Missing glu.h - Compile failure on Ubuntu 6.10 In-Reply-To: References: Message-ID: <45A53E71.8080007@stots.de> signore@autistiche.org schrieb: > hi stefan and all. Thanks Signore, I had to downgrade libglu1-mesa [6.5.1+cvs20060824 to 6.5.1~20060817-0ubuntu3 Don't ask me how the cvs-version came onto my system. Might have been a leftover from Glx-experimentation :) Aptitude did it for me. Next was the "missing" gtk.h problem, which I solved according to https://wiki.secondlife.com/wiki/Common_compilation_problems Next came "sh: yacc not found" So I installed yacc, (package "bison") Next came "sh: lex not found" - what a surprise :) So I installed lex, (package "flex") There were multiple warnings, I pasted one of each "type" I found: /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/llaudio/llaudiodecodemgr.cpp:551: warning: comparison between signed and unsigned integer expressions /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/newview/lldebugmessagebox.cpp:192: warning: enumeration value `VAR_TYPE_VEC2' not handled in switch /home/stw/Daten/SL-dev/linden/libraries/include/llmozlib.h:145:21: warning: no newline at end of file /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/newview/llpanelgroup.h: In constructor `LLPanelGroup::LLPanelGroup(const std::string&, const std::string&, const LLUUID&, const std::string&)': /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/newview/llpanelgroup.h:117: warning: `LLPanelGroup::mForceClose' will be initialized after /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/newview/llpanelgroup.h:111: warning: `BOOL LLPanelGroup::mIgnoreTransition' /tmp/stw/home/stw/Daten/SL-dev/linden/indra/i686-linux-client-release/newview/llpanelgroup.cpp:159: warning: when initialized here The whole compile was pretty much clean of warnings, so I thought I'd mention the few that appear. There may have been more which I did not see. (Yes, i have other things to do than watch the compiler... :) And then, FINALLY: "scons: done building targets." That took longer than compiling the kernel on my old 486DX33! Thanks a lot, Stefan -- http://LinuxBasics.org http://Krone-Neuenburg.com http://Stefan.Waidele.info http://sl.stots.de/blog From tinacloud at gmx.de Wed Jan 10 14:06:06 2007 From: tinacloud at gmx.de (Zi Ree) Date: Wed Jan 10 13:05:36 2007 Subject: [sldev] x86_64 compile successful, but crash on startup Message-ID: <200701102306.06985.tinacloud@gmx.de> Hi SL-Developers! I got the viewer to compile on AMD64 today, but on startup I get a crash shortly after opening the main window. The backtrace shows the following: (gdb) bt #0 0x00002b4be8956645 in FT_Done_Face () from /usr/lib64/libfreetype.so.6 #1 0x00000000012a3bd8 in LLFont::~LLFont () #2 0x00000000012a8658 in LLFontGL::loadFaceFallback () #3 0x00000000012a9905 in LLFontGL::initDefaultFonts () #4 0x000000000104a8f5 in LLViewerWindow::initFonts () #5 0x00000000010637b1 in LLViewerWindow::LLViewerWindow () #6 0x0000000001218048 in main () Anyone have an idea what could cause this? Thanks! Zi! From tinacloud at gmx.de Wed Jan 10 14:30:10 2007 From: tinacloud at gmx.de (Zi Ree) Date: Wed Jan 10 13:29:32 2007 Subject: Success on x86_64 Linux (was: Re: [sldev] x86_64 compile successful, but crash on startup) In-Reply-To: <200701102306.06985.tinacloud@gmx.de> References: <200701102306.06985.tinacloud@gmx.de> Message-ID: <200701102330.11244.tinacloud@gmx.de> Am Mittwoch, 10. Januar 2007 23:06 schrieb Zi Ree: > Anyone have an idea what could cause this? Thanks! Okay, answering myself here, I commented out some code in LLFont::loadFaceFallback() and that got it running :) So I have a working x86_64 client under Linux now, without sound and KDU, but it's a start ;) More when it happens. Zi! From gigstaggart at gmail.com Wed Jan 10 13:54:32 2007 From: gigstaggart at gmail.com (Gigs Taggart) Date: Wed Jan 10 13:54:38 2007 Subject: [sldev] Version control repository In-Reply-To: <45A4F113.3000300@stots.de> References: <45A48E9C.8040108@lindenlab.com> <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> <45A4F113.3000300@stots.de> Message-ID: <2a5bee190701101354j4c7f486ep66fd1ae8c611cb8b@mail.gmail.com> I also lean toward a read-only SVN being the official repository, and letting people manage their own mini branches. That's well known by now though. :) I've read some on Mercurial and it actually looks very nice. I get the feeling "well that's how I would have done it if I were presented with that problem to solve", and that's usually a good thing. So I can live in whatever world is settled on. I admit I have not used a distributed version control system before (though I have used centralized ones in a distributed way many times), so I may be biased. -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070110/1a919fb8/attachment.htm From Stef.Wade at stots.de Wed Jan 10 15:32:17 2007 From: Stef.Wade at stots.de (Stef Wade) Date: Wed Jan 10 15:32:25 2007 Subject: [sldev] [: 89: ==: unexpected operator Message-ID: <45A57781.4020200@stots.de> Hi, this is what I got when packaging the viewer on Ubuntu 6.10 using scons DISTCC=no BTARGET=client BUILD=releasefordownload The viewer did not run. But it is too late tonight to investigate... I sure hope this helps, Stefan [...] strip -S -o newview/secondlife-i686-bin-stripped newview/secondlife-i686-bin strip -S -o linux_crash_logger/linux-crash-logger-i686-bin-stripped linux_crash_logger/linux-crash-logger-i686-bin rm -rf newview/SecondLife_i686_1_13_1_6* && newview/linux_tools/package-client.sh linux_tools/client-manifest-i686 SecondLife_i686_1_13_1_6 default Checking manifest... Done. [: 47: SecondLife_i686_1_13_1_6: unexpected operator Building newview/SecondLife_i686_1_13_1_6 directory... [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator cp: target `SecondLife_i686_1_13_1_6/app_settings/*' is not a directory [: 89: ==: unexpected operator cp: target `SecondLife_i686_1_13_1_6/character/*' is not a directory [: 89: ==: unexpected operator cp: target `SecondLife_i686_1_13_1_6/fonts/*' is not a directory [: 89: ==: unexpected operator cp: target `SecondLife_i686_1_13_1_6/help/*' is not a directory [: 89: ==: unexpected operator cp: target `SecondLife_i686_1_13_1_6/skins/*' is not a directory [: 89: ==: unexpected operator cp: target `SecondLife_i686_1_13_1_6/res-sdl/*' is not a directory [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator [: 89: ==: unexpected operator Done. Pruning CVS directories from newview/SecondLife_i686_1_13_1_6 directory... Done removing CVS directories. Pruning .svn directories from newview/SecondLife_i686_1_13_1_6 directory... Done removing .svn directories. [: 111: ==: unexpected operator Creating gridargs.dat for package, grid default [: 120: SecondLife_i686_1_13_1_6.tar.bz2: unexpected operator Creating tarball newview/SecondLife_i686_1_13_1_6.tar.bz2... Done. scons: done building targets. -- http://LinuxBasics.org http://Krone-Neuenburg.com http://Stefan.Waidele.info http://sl.stots.de/blog From sbg at acw.com Wed Jan 10 15:56:06 2007 From: sbg at acw.com (sbg@acw.com) Date: Wed Jan 10 15:56:10 2007 Subject: [sldev] Sim for newview? In-Reply-To: <8EFC4E2B-C321-409C-B338-AF9EE7960562@secondlife.com> References: <2073.24.63.25.238.1168426405.squirrel@www.acw.com> <8EFC4E2B-C321-409C-B338-AF9EE7960562@secondlife.com> Message-ID: <2786.24.63.25.238.1168473366.squirrel@www.acw.com> Works like a charm. Thanks, Phoenix. Cheers, Scott > Currently, agni is the only grid open for connections. We will > probably be opening siva for test use with the open source client. > From tleiades at hotmail.com Wed Jan 10 16:32:44 2007 From: tleiades at hotmail.com (Duffy Langdon) Date: Wed Jan 10 16:32:54 2007 Subject: [sldev] problem compiling on VS 2005 Message-ID: I get some complaints about missing defines for various FSOUND_STREAM, FSAMPLE, F_CALLBACKAPI, etc. The error occours in llaudio and in the projects which include headers from this project. I suspect it has something to do with the FMOD module, but cannot see what is wrong. There is one difference, which I think is related to this issue, when following the wiki guide I discovered that besides fmod.h and fmod_errors.h, "fmod_codec.h" amd "fmod_codec.h" had to be included as well. Any suggestions on how to move forward? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070111/7a7db6f8/attachment.htm From jamesbisted at gmail.com Wed Jan 10 16:56:13 2007 From: jamesbisted at gmail.com (James Bisted) Date: Wed Jan 10 16:56:16 2007 Subject: [sldev] problem compiling on VS 2005 In-Reply-To: <18939fc0701101643v24efba09m5852d9a332dd3fb5@mail.gmail.com> References: <18939fc0701101643v24efba09m5852d9a332dd3fb5@mail.gmail.com> Message-ID: <18939fc0701101656y522cb91ds646701ca6cc56e8e@mail.gmail.com> You're using the 4.x version of FMOD, you need the 3.75 version. > > On 1/10/07, Duffy Langdon wrote: > > > I get some complaints about missing defines for various FSOUND_STREAM, > > FSAMPLE, F_CALLBACKAPI, etc. > > > > The error occours in llaudio and in the projects which include headers > > from this project. > > > > I suspect it has something to do with the FMOD module, but cannot see > > what is wrong. There is one difference, which I think is related to this > > issue, when following the wiki guide I discovered that besides fmod.hand fmod_errors.h, "fmod_codec.h" amd "fmod_codec.h" had to be included as > > well. > > > > Any suggestions on how to move forward? > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070110/df6c808f/attachment.htm From ham at marinersseasidemall.com Wed Jan 10 18:33:02 2007 From: ham at marinersseasidemall.com (hamncheese) Date: Wed Jan 10 18:34:00 2007 Subject: [sldev] Question about enabling capabilties you don't have normal access to Message-ID: <004801c73528$d2139090$7200a8c0@ad.reyrey.com> I have a question and one that is more for Rob or other Lindens paying attention I *always* have wanted to know what scripts are lagging on my parcel so I could either remove the offending object or tweak the script but am not an estate owner so I normally don't have access to this information. I can enable the ui elements that control access to this function...but what will happen if I click that button? I ask for several reasons but mostly when it does a call to self->sendEstateOwnerMessage(gMessageSystem, "scripts", invoice, strings); will it actually do anything? and if it does am I in violation of any TOS if I click that button on any of "my" parcels? And yes, I have a conscience otherwise I would try it and then plead ignorance. :) I value my account more than this information but it would be nice to have as a normal resident. Thanks, Ham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070110/62175ecb/attachment.htm From tleiades at hotmail.com Wed Jan 10 21:22:37 2007 From: tleiades at hotmail.com (Duffy Langdon) Date: Wed Jan 10 21:22:45 2007 Subject: [sldev] problem compiling on VS 2005 References: <18939fc0701101643v24efba09m5852d9a332dd3fb5@mail.gmail.com> <18939fc0701101656y522cb91ds646701ca6cc56e8e@mail.gmail.com> Message-ID: Thank you, that suggestion did help, I am getting there :-) Now I am having trouble with bison, it report 44 reduce/reduce conflicts. My computer science years are way gone in the past, but I seem to remember that reduce/reduce conflicts are not a good thing. ----- Original Message ----- From: James Bisted To: sldev@lists.secondlife.com Sent: Thursday, January 11, 2007 1:56 AM Subject: Re: [sldev] problem compiling on VS 2005 You're using the 4.x version of FMOD, you need the 3.75 version. On 1/10/07, Duffy Langdon < tleiades@hotmail.com > wrote: I get some complaints about missing defines for various FSOUND_STREAM, FSAMPLE, F_CALLBACKAPI, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070111/b4a659c0/attachment-0001.htm From ginko.sl at fushizen.net Wed Jan 10 22:18:35 2007 From: ginko.sl at fushizen.net (Ginko Bayliss) Date: Wed Jan 10 22:18:13 2007 Subject: [sldev] Re: Success on x86_64 Linux In-Reply-To: <200701102330.11244.tinacloud@gmx.de> References: <200701102306.06985.tinacloud@gmx.de> <200701102330.11244.tinacloud@gmx.de> Message-ID: <45A5D6BB.2000902@fushizen.net> Zi Ree wrote: > Am Mittwoch, 10. Januar 2007 23:06 schrieb Zi Ree: > >> Anyone have an idea what could cause this? Thanks! > > Okay, answering myself here, I commented out some code in > LLFont::loadFaceFallback() and that got it running :) So I have a working > x86_64 client under Linux now, without sound and KDU, but it's a start ;) > > More when it happens. This bug (and a patch) is in the bugtracker: https://jira.secondlife.com/browse/VWR-4 From ginko.sl at fushizen.net Wed Jan 10 22:22:48 2007 From: ginko.sl at fushizen.net (Ginko Bayliss) Date: Wed Jan 10 22:22:23 2007 Subject: [sldev] JIRA public read-only access? Message-ID: <45A5D7B8.4080003@fushizen.net> Hi, Why is it that JIRA does not allow read-only access to unregistered users? While I can understand a login on write actions is useful for accountability reasons, I don't think it's necessary to block read-only access as well. From ginko.sl at fushizen.net Wed Jan 10 22:24:41 2007 From: ginko.sl at fushizen.net (Ginko Bayliss) Date: Wed Jan 10 22:24:18 2007 Subject: [sldev] Version control repository In-Reply-To: <45A4D004.7060004@ngi.it> References: <45A48E9C.8040108@lindenlab.com> <2601.70.49.105.201.1168426133.squirrel@webmail.bluewax.com> <45A4D004.7060004@ngi.it> Message-ID: <45A5D829.8040801@fushizen.net> Kitten Lulu wrote: > Peekay Semyorka ha scritto: >> Hi Rob, >> >> My own view is that LL should first provide us with read-only access to >> the official branches of the client code (-dev branch, -stable branch, >> etc.) Let's call this the "official repository" and contains only Linden >> released code and those slated for inclusion in the next official viewer. >> >> > I think choosing what LL already knows is a good idea and I agree that > read-only access to an official/authoritative source code repository is > a priority. > > I wonder if there is a migration path that would allow to move from (or > augment) a Subversion repository to a SVK repository. Is there anyone > with significant experience with svk who can comment? You don't need to do anything to use svk with an upstream subversion repository; it'll keep track of everything that needs to be tracked at the client's end. Regular subversion clients can interoperate with svk clients on a subversion repository as well. From elio at magetech.com Thu Jan 11 00:22:10 2007 From: elio at magetech.com (MageTech) Date: Thu Jan 11 00:28:02 2007 Subject: [sldev] regAPI account creation issue. Message-ID: <003501c73559$97c26750$6401a8c0@jacqueline> Hello, I have used regAPI successfully with my own website in the past and have the SL accounts to prove it. However even though my CAPs are valid and I can populate last name fields, when I attempted to create an account with all require fields validly populated, I am greeted with the error 200, invalid capability idea. Can anyone tell me please if there is an issue with regAPI atm?? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070111/7888f6e3/attachment.htm From sbg at acw.com Thu Jan 11 04:54:28 2007 From: sbg at acw.com (sbg@acw.com) Date: Thu Jan 11 04:54:29 2007 Subject: [sldev] problem compiling on VS 2005 In-Reply-To: References: <18939fc0701101643v24efba09m5852d9a332dd3fb5@mail.gmail.com> <18939fc0701101656y522cb91ds646701ca6cc56e8e@mail.gmail.com> Message-ID: <4105.24.63.25.238.1168520068.squirrel@www.acw.com> If the conflict is resolved in the way that was intended then no harm is done. The message only means that there was alternative. I.e. they are only "not a good thing" on computer science exams. Cheers, Scott > Now I am having trouble with bison, it report 44 reduce/reduce conflicts. > My computer science years are way gone in the past, but I seem to remember > that reduce/reduce conflicts are not a good thing. From abgrund at silberdrache.net Thu Jan 11 05:29:53 2007 From: abgrund at silberdrache.net (=?ISO-8859-15?Q?Bj=F6rn_Keil?=) Date: Thu Jan 11 05:29:49 2007 Subject: [sldev] [Compiling/Linux] gtk header files not found Message-ID: <45A63BD1.9040207@silberdrache.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I am having a little problem with including my GTK header files. The problem occurs on a Debian Linux (Etch) system. Since I do use the precompiled libraries from the slviewer-Linux-libs I was actually believing I wouldn't even need those. However, I copied the lines from the block for the gtk header files and everything around it in the wiki over: cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/ cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/ cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/ cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/ cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/ cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/ No errors, no warnings, he "SLSRC" environment variable was correctly set. Trying to compile from the indra directory still causes the same problem: /home/bjoern/tmp/home/bjoern/src/linden/indra/i686-linux-client-release/llwindow/llwindowsdl.cpp:44:22: gtk/gtk.h: No such file or directory (etc.) Until then it compiles several files without any warning. Is there maybe a variable I can set to help it find the headers... like "export GTK_HEADERS=/usr/include/gtk2.0/" or anything like that? I believe otherwise I've made everything as described in the wiki, except a few environment changes: export SLSRC='/home/bjoern/src/linden' export FMOD='/home/bjoern/src/fmodapi375linux' alias gcc=gcc-3.4 alias g++=g++-3.4 export CFLAGS='-march=athlon-xp -O3' export CXXFLAGS='-march=athlon-xp -O3' (Could anyone tell me wether these flags are actually being regarded? Even in "ps a | grep g++" during the compile the command does not seem to include the flags I'd like to use. It doesn't use an -march flag and uses -O2 ... but making it be faster (and learning to use it) is the purpose of this compile...) Greets, Bj?rn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpjvRotXYf/q/g6URAt0wAJ9B9HOfN1L2TTFf7IzgwtE4445NGQCcCLba 4DBG+Fb2GAIK1eLGZHZtNak= =Z4BV -----END PGP SIGNATURE----- From abgrund at silberdrache.net Thu Jan 11 10:44:45 2007 From: abgrund at silberdrache.net (=?UTF-8?B?QmrDtnJuIEtlaWw=?=) Date: Thu Jan 11 10:44:41 2007 Subject: [sldev] [Compiling/Linux] gtk header files not found In-Reply-To: <4TJ2OEA6.1168531946.9147410.signore@autistiche.org> References: <4TJ2OEA6.1168531946.9147410.signore@autistiche.org> Message-ID: <45A6859D.7070500@silberdrache.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gah! I just found it myself and wanted to post that, but thanks you anyway. :) I'll have a look at this compilation problems page should more problems occur. signore@autistiche.org schrieb: > In data 11/1/2007, "Bj?rn Keil" ha scritto: > >> Trying to compile from the indra directory still causes the same problem: >> /home/bjoern/tmp/home/bjoern/src/linden/indra/i686-linux-client-release/llwindow/llwindowsdl.cpp:44:22: >> gtk/gtk.h: No such file or directory (etc.) > > I think I got rid of that error editing the indra/SConstruct file , > removing the leading spaces from the six ? ../libraries/? strings > from around line 187 onwards - as explained at the page > https://wiki.secondlife.com/wiki/Common_compilation_problems#Linux > > bye, > Signore Iredell > http://signore.wordpress.com > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFpoWdotXYf/q/g6URAg14AJ91JJvb4EmyycBLxypx42flR8/0CACfQSsL oBM6ARmtx2cX9wnMQtyCe8w= =p+Ml -----END PGP SIGNATURE----- From tipton at tipton.com Thu Jan 11 21:27:14 2007 From: tipton at tipton.com (Tipton Cole) Date: Thu Jan 11 21:27:25 2007 Subject: [sldev] Protocol documentation Message-ID: <5c59b7d30701112127n4f85de0ckb3a1739841efebf4@mail.gmail.com> I cannot find any content for most of "Communication with simulator" Message types from the Protocol page of the wiki. Same problem with "Viewer Object System" "Asset System" "Movie System" and others from the Viewer architecture page of the wiki. Any help? -- Tipton Cole | tipton@tipton.com | 512.329.0060.ofc | 512.328.4742.fax | Austin, Texas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070111/c7b98f43/attachment.htm From tleiades at hotmail.com Thu Jan 11 22:16:18 2007 From: tleiades at hotmail.com (Duffy Langdon) Date: Thu Jan 11 22:16:37 2007 Subject: [sldev] Protocol documentation References: <5c59b7d30701112127n4f85de0ckb3a1739841efebf4@mail.gmail.com> Message-ID: The llmessage project you'd want to examine first, especially the message_template.msg file ----- Original Message ----- From: Tipton Cole To: sldev@lists.secondlife.com Sent: Friday, January 12, 2007 6:27 AM Subject: [sldev] Protocol documentation I cannot find any content for most of "Communication with simulator" Message types from the Protocol page of the wiki. Same problem with "Viewer Object System" "Asset System" "Movie System" and others from the Viewer architecture page of the wiki. Any help? -- Tipton Cole | tipton@tipton.com | 512.329.0060.ofc | 512.328.4742.fax | Austin, Texas ------------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070112/445155a9/attachment.htm From mb at hackdiary.com Fri Jan 12 04:48:45 2007 From: mb at hackdiary.com (Matt Biddulph) Date: Fri Jan 12 04:49:00 2007 Subject: [sldev] connecting new hardware via a modifed client Message-ID: <20070112124845.GB5609@hackdiary.com> I've been playing with adding extra input sources to the client using an external hardware prototype board. Not solid code, just a concept demo: http://www.hackdiary.com/archives/000101.html Cheers, Matt. From gismo at igor.franken.de Fri Jan 12 06:06:54 2007 From: gismo at igor.franken.de (Gismo C.) Date: Fri Jan 12 05:06:43 2007 Subject: [sldev] connecting new hardware via a modifed client In-Reply-To: <20070112124845.GB5609@hackdiary.com> References: <20070112124845.GB5609@hackdiary.com> Message-ID: <20070112140654.GM2081@andromeda.hyte.de> On Fri, Jan 12, 2007 at 12:48:45PM +0000, Matt Biddulph wrote: > I've been playing with adding extra input sources to the client using an > external hardware prototype board. Not solid code, just a concept demo: > Very cool stuff, the integration to the client looks easier than expacted. I have different types of triggers and sensors I want to feed into second life. > http://www.hackdiary.com/archives/000101.html Can you open up all your whole Viewer Code enhancments? > > Cheers, > Matt. Thanks, Gismo From abgrund at silberdrache.net Fri Jan 12 06:10:50 2007 From: abgrund at silberdrache.net (=?ISO-8859-15?Q?Bj=F6rn_Keil?=) Date: Fri Jan 12 06:10:47 2007 Subject: [sldev] Blurry avatar on own build Message-ID: <45A796EA.1040602@silberdrache.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am still having slight problems with using viewers I compiled locally: My own avatar becomes blurry. It looks as though the textures work baked from half downloaded clothes. Other characters are not affected,prims and the environment look normal. Going into "edit appearance" mode forces the client to show all textures clear. Leaving it again lets all textures become blurry at once again. Doing "rebake texture" while in "Edit Appearance" mode makes the avatar have good looking sharp textured, but the sharp textures are then replaced by blurry ones, one by one after a minute or so. The only adjustment I've made is modifying SLConstruct in a way to use "-march=athlon-xp " as a compiler flag. That should be a safe option if one actually uses on AthlonXP processor, even though some mathematical and graphical stuff might be compiled into completely different code, using 3DNOW! or anything it wouldn't have used before. I guess the problem is rather that the libraries provided in slviewer-linux-libs file are not 100% identical to the ones provided with the precompiled viewer... If anyone knows, where in this code assembling of clothing and skin textures into an avatar appearance is made, and how it behaves using incomplete images for that purpose let me know or if anyone has similiar problems... I still don't quite find my way in this code... Thanks Bj?rn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFp5bqotXYf/q/g6URAiXnAKCTmMGTP74fKjpR6k2tI30kEI4WWgCeIoVx rpWDqqugEZU1dmGjTF/ERxY= =RX9t -----END PGP SIGNATURE----- From dillon at morenz.co.uk Fri Jan 12 06:59:02 2007 From: dillon at morenz.co.uk (Dillon Morenz) Date: Fri Jan 12 06:59:07 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <45A796EA.1040602@silberdrache.net> References: <45A796EA.1040602@silberdrache.net> Message-ID: <45A7A236.3050800@morenz.co.uk> Hi Bj?rn, I have this issue too. The debug text presents a continual stream of warnings like this: WARNING: Failed to decode 9ba24da8-d4d7-ceba-c764-06c0fe0f5b00: WARNING: Removing bad texture: 9ba24da8-d4d7-ceba-c764-06c0fe0f5b00 ...while it tries to bake the textures. No processor optimizations here, but I was forced to put the following in lldxhardware.cpp to get it compile: #define INITGUID #include #undef INITGUID I would also be interested if any light could be shed on this. Regards, Dillon Bj?rn Keil wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I am still having slight problems with using viewers I compiled locally: > My own avatar becomes blurry. It looks as though the textures work baked > from half downloaded clothes. Other characters are not affected,prims > and the environment look normal. > > Going into "edit appearance" mode forces the client to show all textures > clear. Leaving it again lets all textures become blurry at once again. > Doing "rebake texture" while in "Edit Appearance" mode makes the avatar > have good looking sharp textured, but the sharp textures are then > replaced by blurry ones, one by one after a minute or so. > > The only adjustment I've made is modifying SLConstruct in a way to use > "-march=athlon-xp " as a compiler flag. That should be a safe option if > one actually uses on AthlonXP processor, even though some mathematical > and graphical stuff might be compiled into completely different code, > using 3DNOW! or anything it wouldn't have used before. I guess the > problem is rather that the libraries provided in slviewer-linux-libs > file are not 100% identical to the ones provided with the precompiled > viewer... > > If anyone knows, where in this code assembling of clothing and skin > textures into an avatar appearance is made, and how it behaves using > incomplete images for that purpose let me know or if anyone has similiar > problems... I still don't quite find my way in this code... > > Thanks > Bj?rn > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFp5bqotXYf/q/g6URAiXnAKCTmMGTP74fKjpR6k2tI30kEI4WWgCeIoVx > rpWDqqugEZU1dmGjTF/ERxY= > =RX9t > -----END PGP SIGNATURE----- > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From dillon at morenz.co.uk Fri Jan 12 07:05:21 2007 From: dillon at morenz.co.uk (Dillon Morenz) Date: Fri Jan 12 07:05:43 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <45A7A236.3050800@morenz.co.uk> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> Message-ID: <45A7A3B1.4070801@morenz.co.uk> Oh, I just remembered that you're compiling on Debian. Even though the build in question here was done on Windows with MSVC2003, the symptoms are identical. Regards Dillon From abgrund at silberdrache.net Fri Jan 12 08:39:16 2007 From: abgrund at silberdrache.net (=?ISO-8859-15?Q?Bj=F6rn_Keil?=) Date: Fri Jan 12 08:39:14 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <45A7A236.3050800@morenz.co.uk> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> Message-ID: <45A7B9B4.4060507@silberdrache.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, since you were using Windows, it was a different reason leading to the same problem. Good you fixed it though. hmmm... I've had a look into the output, too... and yes there was something similiar: 2007-01-12T15:34:19Z INFO: KDU Error: Kakadu Error: 2007-01-12T15:34:19Z 2007-01-12T15:34:19Z INFO: KDU Error: Illegal inclusion tag tree encountered while decoding a packet header. This problem can arise if empty packets are used (i.e., packets whose first header bit is 0) and the value coded by the inclusion tag tree in a subsequent packet is not exactly equal to the index of the quality layer in which each code-block makes its first contribution. Such an error may arise from a mis-interpretation of the standard. The problem may also occur as a result of a corrupted code-stream. Try re-opening the image with the resilient mode enabled. 2007-01-12T15:34:19Z WARNING: KDU throwing an exception 2007-01-12T15:34:19Z WARNING: Failed to decode 5b395bdd-ff48-80f8-e725-eb17af60304c: 2007-01-12T15:34:19Z WARNING: Removing bad texture: 5b395bdd-ff48-80f8-e725-eb17af60304c Since the KDU libraries are are provided as is I cannot modify them, but I wish I knew from where that call came... The solution seems simple, one have to use the library in resilient mode. Basically the KDU library is complaining that something that I don't understand about an image stream is not quite according to the standard and therefore refuses to process the image, even though it could. It shouldn't be too difficult to fix that... I can only guess that a little playing around with llimagj2c.cpp, especially the openDSO() method may help... Dillon Morenz schrieb: > Hi Bj?rn, > > I have this issue too. The debug text presents a continual stream of > warnings like this: > > WARNING: Failed to decode 9ba24da8-d4d7-ceba-c764-06c0fe0f5b00: > WARNING: Removing bad texture: 9ba24da8-d4d7-ceba-c764-06c0fe0f5b00 > > ...while it tries to bake the textures. No processor optimizations > here, but I was forced to put the following in lldxhardware.cpp to get > it compile: > > #define INITGUID > #include > #undef INITGUID > > I would also be interested if any light could be shed on this. > > Regards, > > Dillon > > Bj?rn Keil wrote: > Hello, > > I am still having slight problems with using viewers I compiled locally: > My own avatar becomes blurry. It looks as though the textures work baked > from half downloaded clothes. Other characters are not affected,prims > and the environment look normal. > > Going into "edit appearance" mode forces the client to show all textures > clear. Leaving it again lets all textures become blurry at once again. > Doing "rebake texture" while in "Edit Appearance" mode makes the avatar > have good looking sharp textured, but the sharp textures are then > replaced by blurry ones, one by one after a minute or so. > > The only adjustment I've made is modifying SLConstruct in a way to use > "-march=athlon-xp " as a compiler flag. That should be a safe option if > one actually uses on AthlonXP processor, even though some mathematical > and graphical stuff might be compiled into completely different code, > using 3DNOW! or anything it wouldn't have used before. I guess the > problem is rather that the libraries provided in slviewer-linux-libs > file are not 100% identical to the ones provided with the precompiled > viewer... > > If anyone knows, where in this code assembling of clothing and skin > textures into an avatar appearance is made, and how it behaves using > incomplete images for that purpose let me know or if anyone has similiar > problems... I still don't quite find my way in this code... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFp7m0otXYf/q/g6URAhGiAJ9SoZHf0t/7jkdcz+9eEr+wK8VFMACgn7ov Dgbsh6I6ftzpgF/BQw5q3h4= =IiqQ -----END PGP SIGNATURE----- From carnildo at gmail.com Fri Jan 12 10:21:32 2007 From: carnildo at gmail.com (Mark Wagner) Date: Fri Jan 12 10:21:35 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <45A7B9B4.4060507@silberdrache.net> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> <45A7B9B4.4060507@silberdrache.net> Message-ID: <31073ef90701121021w13bc045es377e12010dea887a@mail.gmail.com> On 1/12/07, Bj?rn Keil wrote: > Since the KDU libraries are are provided as is I cannot modify them, but > I wish I knew from where that call came... The solution seems simple, > one have to use the library in resilient mode. Basically the KDU library > is complaining that something that I don't understand about an image > stream is not quite according to the standard and therefore refuses to > process the image, even though it could. It shouldn't be too difficult > to fix that... > > I can only guess that a little playing around with llimagj2c.cpp, > especially the openDSO() method may help... There are two libraries involved: libkdu_v42R.so is the closed-source Kadaku library that does JPEG-2000 decoding. libllkdu.so is the Linden Labs wrapper that interfaces between that and llimagej2c.cpp. libllkdu.so is the one you'd need to change to put the library in resilient mode, and I suspect the reason it's closed-source is that it contains the license key for using Kadaku. You're probably better off modifying the OpenJPEG library to be fast enough for practical use. I haven't managed more than about a 5% speedup, but I haven't been trying too hard, either. -- Mark Carnildo Greenacre From Stef.Wade at stots.de Fri Jan 12 11:08:01 2007 From: Stef.Wade at stots.de (Stef Wade) Date: Fri Jan 12 11:08:17 2007 Subject: [sldev] No change but compiling all over again Message-ID: <45A7DC91.9090209@stots.de> Hi, it's me again. So, I had some troubles compiling the viewer, which I have solved. The compile went through ("BUILD=release"). On my dated laptop, this took several hours, but hey, it's old. I don't complain :) So, I wanted to get my .tar.bz2, and I started scons another time, using BUILD=releasefordownload I expected this command to be quick, since all the compilation has been done already. We just need to grab some files, move them into the correct location and compress them, right? (Just like a "make install" is done quickly after a successfull "make") But to my surprise, apperently the whole code was compiled again! A whole bunch of lines starting with "g++-3.4 ..." leads me to the assumption. So I wait some more hours, just to see that the actuall making of the download-package threw up some errors. Ok, now I want to try the build from within the source-tree. Again, the gcc-3.4 lines crawl up my terminal-window, as I will have to wait even more hours, for a compile to finish that I have done twice before. I did not change a single line of code. I "touched" no file. I did not even dare to take a look at them using less. Nothing. Is there a way to make scons to behave like make, reducing the turnaround time for little or no changes? Stefan -- http://LinuxBasics.org http://Krone-Neuenburg.com http://Stefan.Waidele.info http://sl.stots.de/blog From abgrund at silberdrache.net Fri Jan 12 11:18:41 2007 From: abgrund at silberdrache.net (=?ISO-8859-15?Q?Bj=F6rn_Keil?=) Date: Fri Jan 12 11:18:38 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <31073ef90701121021w13bc045es377e12010dea887a@mail.gmail.com> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> <45A7B9B4.4060507@silberdrache.net> <31073ef90701121021w13bc045es377e12010dea887a@mail.gmail.com> Message-ID: <45A7DF11.9000508@silberdrache.net> Mark Wagner schrieb: > > You're probably better off modifying the OpenJPEG library to be fast > enough for practical use. I haven't managed more than about a 5% > speedup, but I haven't been trying too hard, either. On the long run definately. :) But at the moment I don't want it to be beautiful I want it to work. If I was only sure, that it is indeed a bug in the KDU wrapper, then I could put it onto the bug list. Well, the openjpeg project is something I will look into. I got no clue how jpeg en- and decoding works, let alone streaming. But that'll come in time. From abgrund at silberdrache.net Fri Jan 12 11:24:36 2007 From: abgrund at silberdrache.net (=?ISO-8859-15?Q?Bj=F6rn_Keil?=) Date: Fri Jan 12 11:24:33 2007 Subject: [sldev] No change but compiling all over again In-Reply-To: <45A7DC91.9090209@stots.de> References: <45A7DC91.9090209@stots.de> Message-ID: <45A7E074.1060603@silberdrache.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stef Wade schrieb: > I expected this command to be quick, since all the compilation has been > done already. We just need to grab some files, move them into the > correct location and compress them, right? (Just like a "make install" > is done quickly after a successfull "make") Well, unfortunately it ain't written in this way... "release" and "releaseforcedownload" use different compiler flags - you can see it in the SConstruct file and therefore create different code. I am not too happy about this either... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFp+B0otXYf/q/g6URAvA8AJ9tfHgZo3l8gsb5nGMNQDbVcerimwCgg/WP az4pNJT2+A08LDrUfLKGksE= =VChP -----END PGP SIGNATURE----- From phoenix at secondlife.com Fri Jan 12 11:57:57 2007 From: phoenix at secondlife.com (Phoenix) Date: Fri Jan 12 11:58:10 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <31073ef90701121021w13bc045es377e12010dea887a@mail.gmail.com> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> <45A7B9B4.4060507@silberdrache.net> <31073ef90701121021w13bc045es377e12010dea887a@mail.gmail.com> Message-ID: On 2007 Jan 12, at 10:21, Mark Wagner wrote: > On 1/12/07, Bj?rn Keil wrote: >> Since the KDU libraries are are provided as is I cannot modify >> them, but >> I wish I knew from where that call came... The solution seems simple, >> one have to use the library in resilient mode. Basically the KDU >> library >> is complaining that something that I don't understand about an image >> stream is not quite according to the standard and therefore >> refuses to >> process the image, even though it could. It shouldn't be too >> difficult >> to fix that... >> >> I can only guess that a little playing around with llimagj2c.cpp, >> especially the openDSO() method may help... > > There are two libraries involved: libkdu_v42R.so is the closed-source > Kadaku library that does JPEG-2000 decoding. libllkdu.so is the > Linden Labs wrapper that interfaces between that and llimagej2c.cpp. > libllkdu.so is the one you'd need to change to put the library in > resilient mode, and I suspect the reason it's closed-source is that it > contains the license key for using Kadaku. > > You're probably better off modifying the OpenJPEG library to be fast > enough for practical use. I haven't managed more than about a 5% > speedup, but I haven't been trying too hard, either. We've heard rumors that jasper was pretty good these days, but our tests several years ago showed it was very slow so we thought we would try openjpeg as the alternate. It would not be too hard to make an llimagej2cjasper project which exported an llimagej2c implementation to see if it was better. We plan on revving the c++ api at least once in the future to make it more detached from the rest of the project like llmozlib. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070112/1465358b/PGP.pgp From carnildo at gmail.com Fri Jan 12 12:31:30 2007 From: carnildo at gmail.com (Mark Wagner) Date: Fri Jan 12 12:31:32 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> <45A7B9B4.4060507@silberdrache.net> <31073ef90701121021w13bc045es377e12010dea887a@mail.gmail.com> Message-ID: <31073ef90701121231x764dbaf0n9be39d16665013c9@mail.gmail.com> On 1/12/07, Phoenix wrote: > We've heard rumors that jasper was pretty good these days, but our > tests several years ago showed it was very slow so we thought we > would try openjpeg as the alternate. It would not be too hard to make > an llimagej2cjasper project which exported an llimagej2c > implementation to see if it was better. I did some command-line testing, and JasPer is about 25% faster than OpenJPEG at converting a JP2 or J2K file to PNM format. I figured it wasn't worth the effort to convert over, since I couldn't find any API documentation for either library. -- Mark Carnildo Greenacre From jwolk at lindenlab.com Fri Jan 12 13:11:52 2007 From: jwolk at lindenlab.com (Jonathan Wolk) Date: Fri Jan 12 13:12:09 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <45A7B9B4.4060507@silberdrache.net> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> <45A7B9B4.4060507@silberdrache.net> Message-ID: <45A7F998.7080800@lindenlab.com> Hi All, Jonathan Wolk here (Jonathan Linden) just saying that yes you may be seeing these errors but the errors message is misleading. The resilient mode thing is...not the right solution. These errors I believe are also in our officially distributed viewers as well and not just an open source thing (although you might want to verify that). -Jonathan Bj?rn Keil wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Well, since you were using Windows, it was a different reason leading to >the same problem. Good you fixed it though. > >hmmm... I've had a look into the output, too... and yes there was >something similiar: > >2007-01-12T15:34:19Z INFO: KDU Error: Kakadu Error: >2007-01-12T15:34:19Z >2007-01-12T15:34:19Z INFO: KDU Error: Illegal inclusion tag tree >encountered while decoding a packet header. This problem can arise if >empty packets are used (i.e., packets whose first header bit is 0) and >the value coded by the inclusion tag tree in a subsequent packet is not >exactly equal to the index of the quality layer in which each code-block >makes its first contribution. Such an error may arise from a >mis-interpretation of the standard. The problem may also occur as a >result of a corrupted code-stream. Try re-opening the image with the >resilient mode enabled. >2007-01-12T15:34:19Z WARNING: KDU throwing an exception >2007-01-12T15:34:19Z WARNING: Failed to decode >5b395bdd-ff48-80f8-e725-eb17af60304c: >2007-01-12T15:34:19Z WARNING: Removing bad texture: >5b395bdd-ff48-80f8-e725-eb17af60304c > >Since the KDU libraries are are provided as is I cannot modify them, but >I wish I knew from where that call came... The solution seems simple, >one have to use the library in resilient mode. Basically the KDU library >is complaining that something that I don't understand about an image >stream is not quite according to the standard and therefore refuses to >process the image, even though it could. It shouldn't be too difficult >to fix that... > >I can only guess that a little playing around with llimagj2c.cpp, >especially the openDSO() method may help... > From pphillips at lindenlab.com Fri Jan 12 14:36:03 2007 From: pphillips at lindenlab.com (Peter Phillips) Date: Fri Jan 12 14:34:07 2007 Subject: [sldev] Process affinity problem on dual core Windows boxen Message-ID: <45A80D53.8030309@lindenlab.com> I've just entered a bug about our process affinity related frame rate woes. I'd been tinkering with a hacky work-around, but I can't devote any more time to it right now since I'm swamped with other tasks. Rather than just throw my progress on this issue away, I've entered https://jira.secondlife.com/browse/VWR-25 and included my patch so that it can be used as a starting point for finding the right work-around to the problem or help in finding the root cause of the problem so that it can be corrected. Using this patch I've seen a 3x to 5x increase in frame rate. Cheers, Peter "Lawrence Linden" Phillips From carnildo at gmail.com Fri Jan 12 14:34:51 2007 From: carnildo at gmail.com (Mark Wagner) Date: Fri Jan 12 14:34:54 2007 Subject: [sldev] Blurry avatar on own build In-Reply-To: <45A7F998.7080800@lindenlab.com> References: <45A796EA.1040602@silberdrache.net> <45A7A236.3050800@morenz.co.uk> <45A7B9B4.4060507@silberdrache.net> <45A7F998.7080800@lindenlab.com> Message-ID: <31073ef90701121434v5a5cf1c7k704c587bd60591d7@mail.gmail.com> On 1/12/07, Jonathan Wolk wrote: > Hi All, > > Jonathan Wolk here (Jonathan Linden) just saying that yes you may be > seeing these errors but the errors message is misleading. The resilient > mode thing is...not the right solution. These errors I believe are also > in our officially distributed viewers as well and not just an open > source thing (although you might want to verify that). Any way to silence them? They're flooding the output, making it hard to find other messages. -- Mark Carnildo Greenacre From tinacloud at gmx.de Fri Jan 12 17:06:24 2007 From: tinacloud at gmx.de (Zi Ree) Date: Fri Jan 12 16:05:28 2007 Subject: [sldev] Chat and IM Line History - Patch Message-ID: <200701130206.24812.tinacloud@gmx.de> Hi SL-Developers! Today I started digging deeper into the code of the Second Life Viewer, and to make myself familiar with how it works, I decided to implement a small pet feature of mine: chat line history. Coming from the Linux and IRC background I desperately need a way to recall my previously written lines, without having to copy & paste them from some scrollback buffer. So I loaded the Viewer source into my favourite project tool and started to work on the code. It took me about half a day to get it done, and I hope it doe swork on other people?s machines, too. I decided to go for CTRL UP / CTRL DOWN as history recall keys, because the normal cursor keys are used for walking when the chat line is empty, and thus are out of the question. Please try my patch and tell me if it worked for you or if I messed up somewhere :) Download >> http://zi.furhome.net/downloads/patches/chat_line_history.patch Have fun! Zi! From robla at lindenlab.com Fri Jan 12 17:27:54 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jan 12 17:28:38 2007 Subject: [sldev] Version control repository In-Reply-To: <45A48E9C.8040108@lindenlab.com> References: <45A48E9C.8040108@lindenlab.com> Message-ID: <45A8359A.60303@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm running out of time to get done with everything I wanted to this week, but I want to give a quick summary of where we're at with respect to version control: * Timeframe: I don't want anyone to get /too/ excited about getting this right away. I'm guessing (not promising) that this is at least two months out, and that could be optimistic. We've been taken aback by how quickly the community has come up to speed on the codebase and is already starting to submit patches...we expected to have more time to sort this out. * My reading of this mailing list is that consensus is leaning pretty heavily toward Subversion. A lot of the chatter on IRC and in-world has been pro-Mercurial, with a bit of both on the wiki: https://wiki.secondlife.com/wiki/Talk:Version_control_repository Linden Lab's internal discussion on the topic leans heavily toward Subversion, though it's also clear that "happy" may not be the best word to describe the general feeling toward it; "learned to live with" may be more accurate. The suggestion was also made to let the community continue to run unofficial repositories for a while (see below) until a clear winner shakes out. My personal leaning on this is now toward Subversion if I had to pick between the two (assuming I don't take the suggestion to punt). Mercurial looks harder to support, and in general still seems a little too rough around the edges. * I didn't do a very good job of stating the requirements for the system, and the options we have there. Here are the two modes of operation: MODE #1: read-only, "official" repository with occasional source drops from internal SVN repository pushed externally MODE #2: read-only, "official" repository which mirrors/pushes internal SVN outbound The assumption at Linden Lab has been something along the lines of mode #1. I realize mode #2 is far more useful, but the LL dev staff isn't ready for that. One option we have is to wait until LL dev's staff /is/ ready for operating in mode #2 before putting out a repository, since mode #1 is really just a glorified tarball push anyway. * It's clear people are hoping for Linden Lab to provide write-access to at least sandbox branches. There is some appeal to that (being that we can grant commit access to developers who sign contribution agreements, and make it clear that all commits are contributions). This is a tougher nut to crack, however; this ups the ante on operational complexity and any number of other issues. This is not something we were planning to do, but could still be convinced to do. Current plan of record: no sandboxes. * For those who can't wait for an official repository, there's an unofficial repository at http://opensecondlife.org , not run by Linden Lab or affiliated with us in any way. We're excited to see the enthusiasm embodied by this effort, and it looks like there's already some great work cooking there. Based on in-world meeting yesterday, there's a desire to get that stuff checked in to the official Linden Lab distribution, which can work /if/ we all handle things correctly. There needs to be very careful accounting of who contributed what, and we want to be sure it's very clear that the person who wrote the code is truly contributing their work to us under the contribution agreement, and that they are receiving proper credit for their work. Plan of record in summary: Timetable: uncertain...still need solid requirements, probably at least a couple months away Technology: Subversion Mode of operation: Read-only access with occasional pushes (Mode #1 above) Write access sandboxes: no So, I'd like to make a decision by Wednesday of next week, getting a better spec in place on the wiki, getting these two questions answered by then: 1. Is that plan of record useful enough to satisfy the vague appetite for version control, or is that not enough to be worth it? 2. If you believe that an official Linden Lab source repository needs to be more ambitious, are you willing to wait longer to get that result? Please make your opinions known here or on the wiki talk page. I'll be holding office hours in world at Grasmere(112, 81, 26) (the cubicle on the hill) on Monday at 3pm and Wednesday at 9am if you have questions (and will post those on my wiki user page). Thanks Rob On 1/9/07 10:58 PM, Rob Lanphier wrote: > Hi everyone, > > A hot topic on IRC, in-world, and everywhere else seems to be "is > Linden Lab going to provide a version control repository, and if > so, when?" The answer is "we need a spec first". What's so hard > about that? Well, I want to work with the community on defining > the spec, and come up with something that is going to be the most > useful for everyone. > > The options are spelled out here: > http://wiki.secondlife.com/wiki/Version_control_repository > > ...as are some of the discussions (hit the "discussion" tab to > view). > > The safe option these days is Subversion. It's really widely > supported, has a ton of tools for all platforms, and really seems > to have hit critical mass. We use it internally, and as near as I > know, everyone seems reasonably happy with it. There hasn't been > any chatter (that I've heard) about replacing it any time soon. The > command line is very sensible, and the model is reasonably easy to > understand for anyone who has worked with version control systems > before. In particular, the command line interface was designed to > be similar (but not slavishly identical) to the venerable CVS. > There's also lots of nice tools and extensions that work with it, > and I think a reasonable number of IDEs support it now (fact check, > aisle 7) > > The trendy thing these days in version control systems is > distributed control systems, first popularized by BitKeeper, and > more recently made popular by the explosion of options such as git, > darcs, svk, bazaar, and Mercurial. What's interesting about these > systems is that they make it much easier for ad hoc teams to > collaborate, each developer publishing a mini repository, and > provide tools for people to deal with lots of little patchsets from > a lot of different sources. These tools aren't as mature as > Subversion, but they are much more powerful. The command line > interface on many of these is quite difficult (that's at least my > experience with bazaar), but I've heard good things about > Mercurial, and looking at the quick start guide, it seems the most > intuitive of the open source options. Svk is also interesting, as > it's layered on top of Subversion (more below on why that can be > good). > > While Subversion works great for, say, a team of professional > developers all in the same building working under the same > management on the same or at least coordinated set of projects, it > isn't as well suited to collaboration of a lot of developers each > working on their own pet feature that want to pick and choose which > other developers they want to collaborate with. Dealing with > branches gets really tedious really quickly...get above a dozen, > and you've got a bit of a nightmare. Merging tools are > o.k....certainly better than CVS, but things are much easier when > everyone stays on the same branch. > > Subversion would be nice choice because that's what Linden Lab uses > internally. Reducing drag on LL developers is an important > consideration; in addition to my selfish motive to maintain a good > relationship with my co-workers, I want to have as few mental or > logistical obstacles for LL developers to work on the open source > side of the firewall. > > Mercurial is interesting to me, because it seems like a great blend > of distributed system and sensible interface. My knowledge of > Mercurial is a little thin, though, so I'd be interested in hearing > from people who have spent quality time with it. Mercurial might > be intriguing for LL devs, and the open source repository may be > seen as a great way to try it out and maybe even get religion on > distributed revision systems. However, it may be yet another > friggin' half-working tool to learn the quirks for. Hard to say; > the devil is probably in the details. > > Svk might be a great compromise between the two. However, I have > no real experience with svk either. > > The community seems divided on the issue. One in-world discussion > at Hooper was leaning pretty heavily toward a distributed tool like > Mercurial. Another discussion at Pooley after the town hall wound > down seemed to be a much more Subversion-leaning crowd. > > I'm truly on the fence on this topic, perhaps leaning slightly > toward Mercurial, because I think a distributed system would be a > better fit. I am interested in having a conversation about this > before making a decision. Whatever we decide, I want to stick with > it for a couple of years at least, so let's make sure we do enough > homework to avoid buyer's remorse. > > Thoughts? > > Rob > _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqDWaPd430ImZiAMRAt/eAJ9AvhyX4bgbOJb1eHLhZqvGpzLoPACeIMSl 7HB1WeReSi1Qfk3yLIcHBYA= =MIOG -----END PGP SIGNATURE----- From robla at lindenlab.com Fri Jan 12 18:13:30 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jan 12 18:14:12 2007 Subject: [sldev] New source for the weekend: 20070112a Message-ID: <45A8404A.2070503@lindenlab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Updated source is available for download. This release brings us into closer alignment with the standard Second Life viewer download. Changes from 20070108c: * Fixes a number of minor problems, configuration issues, and annoyances * Includes a patch for VWR-11 (yay, first applied patch, thank you Kage Pixel) * Updated llmozlib source code Patch for VWR-17 hasn't made it in yet, but it's on its way. I've got some issue tracker gardening I need to do to get other patches into the development pipeline...there's some good stuff there; just haven't yet had the time to get everything sorted out. Links are here: Viewer Source: http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.tar.gz http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.zip llmozlib source: http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz Linux libs: http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-linux-libs-20070112a.tar.gz Mac libs: http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-darwin-libs-20070112a.tar.gz Windows libs: http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-win32-libs-20070112a.zip http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-lib-win32-20070111a.zip I think it'll be Monday before these links are reflected on the main website. Have a great weekend everyone! Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqEBJPd430ImZiAMRAhThAJ9s9eQXGL9uL5/uTWKbUqZ0NWAWuwCfaw22 9TMTyZ6cKR//Rs9fNwrZvuA= =PIvA -----END PGP SIGNATURE----- From jhurliman at wsu.edu Fri Jan 12 18:19:50 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Jan 12 18:19:43 2007 Subject: [sldev] Version control repository In-Reply-To: <45A8359A.60303@lindenlab.com> References: <45A48E9C.8040108@lindenlab.com> <45A8359A.60303@lindenlab.com> Message-ID: <45A841C6.3020404@wsu.edu> Rob Lanphier wrote: > > So, I'd like to make a decision by Wednesday of next week, getting a > better spec in place on the wiki, getting these two questions answered > by then: > 1. Is that plan of record useful enough to satisfy the vague appetite > for version control, or is that not enough to be worth it? > 2. If you believe that an official Linden Lab source repository needs > to be more ambitious, are you willing to wait longer to get that result? > > I don't understand what the difference between putting tarballs on the website and putting source dumps in svn is, other than having a better view of code history. If the public repository was more closely synced with the internal Linden repo that would be interesting, but probably not feasible for a while until a better system of handling community patches is in place. So I'm voting for method #2 tentatively... but with the stated timeframe I'm also leaving the possibility open that opensecondlife.org will have a really solid Mercurial or other distributed version control workflow going on by then, in which case I would like to see LL adopt whatever works best for everyone. John Hurliman From tleiades at hotmail.com Sat Jan 13 01:54:28 2007 From: tleiades at hotmail.com (Tleiades) Date: Sat Jan 13 01:54:31 2007 Subject: [sldev] Progress report on VS 2005 Compile Message-ID: Hi Yesterday I had some significant progress on getting the viewer to compile on VS 2005. Unfortunately I had to leave early, because of the weekend. I report here, so others may continue from where I left it. You will need to have both VS 2003 and VS 2005 installed I recompiled mozilla using VS 2003, i.e. make sure that the VCVARS.BAT executed is the 2003 version. I got the llmozlib project from the uBrowser website, and compiled it using VS 2005. I copied the resulting llmozlib.lib in to the libraries part of indira. Compiled the viewer using VS2005, warning: There is a mismatch between the setbackgroundColor method in llMozLib.h, between the version comming of the uBrowser and the version in Indira (bool vs. void return, const int vs. int parameters) Having fixed this, I got a clean compile and link. and managed to run the new SecondLife.exe. There were no crashes, but I never got a login prompt either :-( I will continue my work on a VS 2005 compile when I get back from the weekend, but in the mean time, others might want to fiddle around as well. /Tleiades -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070113/4c7a723e/attachment.htm From jhurliman at wsu.edu Sat Jan 13 01:56:11 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Jan 13 01:56:11 2007 Subject: [sldev] PATCH: Copy UUID pie menu item Message-ID: <45A8ACBB.3010304@wsu.edu> I got a request in IRC to add a "Copy UUID" option to the pie menu for objects and avatars, much like the right-click menu item in your inventory. Countless times I've been working on something in libsecondlife where I'm trying to debug an object or avatar and need to get the UUID for it, and we've devised all sorts of strange contraptions including rolling a ball in to it that emits the UUID of things it hits, to sensors and whatever else. Hopefully someone will find a use for this while working on opensl code too. John Hurliman Index: llviewermenu.cpp =================================================================== --- llviewermenu.cpp (revision 23) +++ llviewermenu.cpp (working copy) @@ -2050,6 +2050,36 @@ } }; +class LLObjectEnableCopyUUID : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLViewerObject* object = gViewerWindow->lastObjectHit(); + bool new_value = (object != NULL); + gMenuHolder->findControl(userdata["control"].asString())->setValue(new_value); + return true; + } +}; + +class LLObjectCopyUUID : public view_listener_t +{ + bool handleEvent(LLPointer event, const LLSD& userdata) + { + LLViewerObject* object = gViewerWindow->lastObjectHit(); + if (!object) return true; + + LLUUID id = object->getID(); + + char buffer[UUID_STR_LENGTH]; + id.toString(buffer); + + gViewerWindow->mWindow->copyTextToClipboard(utf8str_to_wstring(buffer)); + + gSelectMgr->deselectAll(); + return true; + } +}; + bool handle_go_to() { // JAMESDEBUG try simulator autopilot @@ -8774,6 +8804,7 @@ (new LLObjectMute())->registerListener(gMenuHolder, "Object.Mute"); (new LLObjectBuy())->registerListener(gMenuHolder, "Object.Buy"); (new LLObjectEdit())->registerListener(gMenuHolder, "Object.Edit"); + (new LLObjectCopyUUID())->registerListener(gMenuHolder, "Object.CopyUUID"); (new LLObjectEnableOpen())->registerListener(gMenuHolder, "Object.EnableOpen"); (new LLObjectEnableTouch())->registerListener(gMenuHolder, "Object.EnableTouch"); @@ -8786,6 +8817,7 @@ (new LLObjectEnableRateCreator())->registerListener(gMenuHolder, "Object.EnableRateCreator"); (new LLObjectEnableMute())->registerListener(gMenuHolder, "Object.EnableMute"); (new LLObjectEnableBuy())->registerListener(gMenuHolder, "Object.EnableBuy"); + (new LLObjectEnableCopyUUID())->registerListener(gMenuHolder, "Object.EnableCopyUUID"); /*(new LLObjectVisibleTouch())->registerListener(gMenuHolder, "Object.VisibleTouch"); (new LLObjectVisibleCustomTouch())->registerListener(gMenuHolder, "Object.VisibleCustomTouch"); Index: skins/xui/en-us/menu_pie_avatar.xml =================================================================== --- skins/xui/en-us/menu_pie_avatar.xml (revision 23) +++ skins/xui/en-us/menu_pie_avatar.xml (working copy) @@ -47,6 +47,11 @@ + - +