From blakar at gmail.com Sun Jul 1 11:07:12 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jul 1 11:07:15 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> Message-ID: <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> For starters: I'm no C++ guru so I might be missing something. Feel free to enlighten me if so ;-) My question is the following: Is there a purpose to declare a function virtual if you've no intention to overload it? As an example I'd like to take LLTreeNode. In LLTreeNode we've "virtual LLTreeListener* getListener(U32 index) const { return mListeners[index]; }" This translates into a very small piece of code but it'll not inline due to the virtual. It's declared immediately as part of the class which is known to help in convincing the compiler to inline but in VS2005 it won't by default. If I dig thru the code I can not find any derived class that overloads getListener. Even better in LLOCTreeNode we get: virtual oct_listener* getOctListener(U32 index) { return (oct_listener*) BaseType::getListener(index); } which makes it look even more strange to me. I can imagine it has something to do with the fact that we're using template classes but reading what I can find on template classes I still don't understand the reasoning. In the end, removing the virtual does achieve what I want, it inlines the function and SL seems to run just fine. Anybody care to explain? Dirk aka Blakar Ogre From chance at kalacia.com Sun Jul 1 12:41:49 2007 From: chance at kalacia.com (Chance Unknown) Date: Sun Jul 1 12:41:52 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> Message-ID: <2925011a0707011241q4a40ef6cw10d545b485848c1e@mail.gmail.com> one use of virtual functions is when you are only provided a library to link to and you need to override some function that is provided in the library. the library designer can declare the function as virtual to allow this to happen. its a design call on the part of the library designer really. the complaint against virtual functions is that they carry the requirement of runtime type information that the compiler has to insert stubs for the C++ runtime to account for, for some projects, that overhead is a tad more than you want to carry. when you have the sources to modify, virtual functions become more of a design decision than something that has extremely profound usefulness. arguments can be made on both sides of the camp on why they are useful, and why they are evil and must be destroyed. On 7/1/07, Dirk Moerenhout wrote: > > For starters: I'm no C++ guru so I might be missing something. Feel > free to enlighten me if so ;-) > > My question is the following: > Is there a purpose to declare a function virtual if you've no > intention to overload it? As an example I'd like to take LLTreeNode. > > In LLTreeNode we've "virtual LLTreeListener* getListener(U32 index) > const { return mListeners[index]; }" > > This translates into a very small piece of code but it'll not inline > due to the virtual. It's declared immediately as part of the class > which is known to help in convincing the compiler to inline but in > VS2005 it won't by default. If I dig thru the code I can not find any > derived class that overloads getListener. Even better in LLOCTreeNode > we get: > > virtual oct_listener* getOctListener(U32 index) > { > return (oct_listener*) BaseType::getListener(index); > } > > which makes it look even more strange to me. > > I can imagine it has something to do with the fact that we're using > template classes but reading what I can find on template classes I > still don't understand the reasoning. > > In the end, removing the virtual does achieve what I want, it inlines > the function and SL seems to run just fine. > > Anybody care to explain? > > Dirk aka Blakar Ogre > _______________________________________________ > 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/20070701/102dd608/attachment.htm From nicholaz at blueflash.cc Sun Jul 1 13:22:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 1 13:22:31 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> Message-ID: <46880CFB.2030907@blueflash.cc> Dirk Moerenhout wrote: > For starters: I'm no C++ guru so I might be missing something. Feel > free to enlighten me if so ;-) > > My question is the following: > Is there a purpose to declare a function virtual if you've no > intention to overload it? As an example I'd like to take LLTreeNode. I'd say no. The only purpose in using virtual is if you plan to overoad it *and* plan to reference the resulting objects through a pointer which does not know what the object is exactly. On the design side however, unless you are dealing with extremely performance sensitive code, if in doubt, it's usually a good idea to make functions virtual and not need it than the other way round. > I can imagine it has something to do with the fact that we're using > template classes but reading what I can find on template classes I > still don't understand the reasoning. There's so much leftover stuff (unused members, etc.) in the viewer that I'd bet that it has no deeper meaning in this case. Nick From blakar at gmail.com Sun Jul 1 15:32:15 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jul 1 15:32:18 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <46880CFB.2030907@blueflash.cc> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> <46880CFB.2030907@blueflash.cc> Message-ID: <7992d0d60707011532y4afb15bcv8cbd9296060920bb@mail.gmail.com> > On the design side however, unless you are dealing with > extremely performance sensitive code, if in doubt, it's > usually a good idea to make functions virtual and not need > it than the other way round. Well we're dealing with performance sensitive code as it's one of the top functions (when using an optimised viewer) even though it has only 4 instructions (including RET ...). I get upto 2% of the cycle samples in those 4 instructions and that doesn't take into account all the wasted cycles on additional instructions that are needed to do the call. Dirk aka Blakar Ogre From nicholaz at blueflash.cc Sun Jul 1 16:44:58 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 1 16:45:15 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <7992d0d60707011532y4afb15bcv8cbd9296060920bb@mail.gmail.com> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> <46880CFB.2030907@blueflash.cc> <7992d0d60707011532y4afb15bcv8cbd9296060920bb@mail.gmail.com> Message-ID: <46883C7A.8060100@blueflash.cc> Dirk Moerenhout wrote: >> On the design side however, unless you are dealing with >> extremely performance sensitive code, if in doubt, it's >> usually a good idea to make functions virtual and not need >> it than the other way round. > > Well we're dealing with performance sensitive code as it's one of the > top functions (when using an optimised viewer) even though it has only > 4 instructions (including RET ...). I get upto 2% of the cycle samples > in those 4 instructions and that doesn't take into account all the > wasted cycles on additional instructions that are needed to do the > call. There's definitely overhead in the call itself too. I think the pointer to the virtual function map is the first or second member in the objects, so the call is something like this->vfptrs[](); which I think I've seen translated into two or three machine instructions, including the call. If it is speed sensitive and if you can't find an overload there (which should be easy to spot by the same name), try it non-virtual. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From kamilion at gmail.com Sun Jul 1 22:29:56 2007 From: kamilion at gmail.com (Kamilion) Date: Sun Jul 1 22:29:58 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4686E45B.7040400@knowprose.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> <46860262.6050801@gmail.com> <4686E45B.7040400@knowprose.com> Message-ID: Personally, what I'd like to see out of the server source code would be the LSL VM -- I've recently discovered LSLEditor ( http://www.lsleditor.org/ ) which has a relatively decent LSL VM in it's debugger, but it could probably do with a window into how the real VM works. Also, the LSL to C#/Mono bits might be helpful in the same fashions. From able.whitman at gmail.com Mon Jul 2 01:07:26 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 01:07:29 2007 Subject: [sldev] Rolling a custom viewer installer? Message-ID: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> I'd like to be able to distribute a test version of the viewer with my changes to implement Mute Visibility applied. Because the patch involves some UI-related XML changes as well as code changes, it's much easier to distribute it as an installer, rather than a zip file with a bunch of files that need to be copied / overwritten. It also makes it very easy for people to go back to the official viewer if they run into problems. To this end, I've modified the NSIS installer files and the related Python scripts, and I've gotten the "secondlife setup build.bat" script to successfully create an installable self-extracting setup. I've rebranded the setup similarly to how a First Look client is branded, so that it is installable side-by-side with the official viewer and doesn't overwrite any existing settings. I've also clearly indicated in the release notes that appear the start of installation that this is not an official viewer release, and they should contact me, not Linden Lab, if they run into problems with it. Am I allowed to distribute this installer for other people to use? Thanks, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070702/e52c10f4/attachment.htm From secret.argent at gmail.com Mon Jul 2 08:22:01 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 08:22:03 2007 Subject: [sldev] CPU detection code In-Reply-To: <20070629211515.7D90141AFFD@stupor.lindenlab.com> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> Message-ID: <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> If there's a problem with the CPU detection code in SL, why not use the code from BSD? Unlike the Linux code, it's unencumbered. From secret.argent at gmail.com Mon Jul 2 08:30:27 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 08:30:28 2007 Subject: [sldev] Opening the server source? In-Reply-To: <20070630152148.B4C7A41B023@stupor.lindenlab.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> Message-ID: <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> The only way I see to open up any kind of grid without collapsing the SL economy would be to have separate public grids, and let them develop their own content under their own rights rights system. It would be like the inverse of the Beta grid - you would be able to transfer content from the public grid to Agni, but only full-right objects could be transferred the other way. Linden Labs strategic advantage, then, would be the content only available on Agni. From chance at kalacia.com Mon Jul 2 08:35:43 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jul 2 08:35:48 2007 Subject: [sldev] Opening the server source? In-Reply-To: <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> Message-ID: <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> remove the economy when traveling to foreign grids. there is nothing that says lindens need to provide L$ outside the confines of their servers. make us figure out alternative payment mechanisms. or allow us to decide what our poker chips are based on. $L is not a negotiable form legal tender, so we should not expect foreign grids to trade in it. On 7/2/07, Argent Stonecutter wrote: > > The only way I see to open up any kind of grid without collapsing the > SL economy would be to have separate public grids, and let them > develop their own content under their own rights rights system. It > would be like the inverse of the Beta grid - you would be able to > transfer content from the public grid to Agni, but only full-right > objects could be transferred the other way. Linden Labs strategic > advantage, then, would be the content only available on Agni. > _______________________________________________ > 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/20070702/bf50b220/attachment.htm From secret.argent at gmail.com Mon Jul 2 08:51:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 08:51:11 2007 Subject: [sldev] Opening the server source? In-Reply-To: <20070702153029.4CFBB41AF38@stupor.lindenlab.com> References: <20070702153029.4CFBB41AF38@stupor.lindenlab.com> Message-ID: > Personally, what I'd like to see out of the server source code would > be the LSL VM -- I've recently discovered LSLEditor ( > http://www.lsleditor.org/ ) which has a relatively decent LSL VM in > it's debugger, but it could probably do with a window into how the > real VM works. Me too! Though I really need to poke through the execute portion of the lscript tree some time. > Also, the LSL to C#/Mono bits might be helpful in the same fashions. That part is in the compiler. One of the first things I noticed in the compiler is that the mono code generator had slightly different ordering of execution than the LSL generator, which would have broken most of Strife Onizuka's performance hacks for list management (and which was why I recommended he avoid hacks that depend on order of execution). They changed the code generator to keep them working. From matthew.dowd at hotmail.co.uk Mon Jul 2 08:54:35 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jul 2 08:54:37 2007 Subject: Musings on LL as IANA or W3C in a 3D Web (was RE: [sldev] Opening the server source?) Message-ID: > Which means - LL has a lot of work to do and the code is only a part of > it. Stage whisper that wherever you can, because it is true even without > the server source being opened. I did some thinking over the weekend and if we take the metaphor of SL being the 3D Web, I think that LL would be better off becoming the W3C equivalent than the IANA equivalent. As discussed, an open Grid future for SL will require some centralised servers. The fundamental problem preventing SL becoming a completely distributed system ala the Web is the permission system for objects and the monetary system (although the latter presumedly could ultimately be replaced with real money?). The issues in protecting SL objects aren't too disimilar to protecting software (with the added complication that objects can move sims which is the equivalent of software moving between different computers). If we can solve that, someone still needs to run some backend systems for the world map (either via a registration model ala DNS or a discovery model ala Google); if (which is probably more likely in the short term) we can't someone needs to run the asset servers etc. Someone/somewhere will attempt to run their own Grids so there will be competition, and as mentioned there will be a few major accepted Grids and then lots of small "enthuasist" Grids. In order to run one (or as LL may hope *the*) major Grids, you need service level agreements (not TOS denying all responsibility), 24/7 reliability, 24/7 support, clear policies etc. things LL has got a particularly good track record of late. However, adoption of a major mainstream Grid in this scenario is not driven by innovation but by stability, as whilst early adopters may be driven by innovations, the mass market is driven by familiarity (just look at those who run Microsoft software - is innovation was the main driver everyone would be on Vista and Office 2007!) Not only would LL need to do a lot of work in order to play this "IANA" type role but LL would have to change to something very different - its whole philosophy (from the Taoi of Linden to the strategy of "out innovating our competition") would need to dramatically change. Not only that but its entire skillset needs to dramtically change - to place this "IANA" role it needs systems/network engineers and managers, database engineers and managers - not graphic/game engine specialists and UI specialists. If LL doesn't change, then someone else (possible multiple providers) will step in and play this Grid backbone role - leaving the LL grid as one of the small fringe Grids where the innovation can happen before being rolled out onto the main Grids. However, is this latter scenario bad for LL? If anything it plays to their strengths, they could play the role of W3C in this 3D grid - defining the standards and the technologies, testing them out on a fringe "beta grid" whilst allowing others to run the main Grids. This seems to play far more to their strengths and removes the service "distractions" which they have had so much trouble with of late. My main concern, however, is that whilst I believe that both the IANA or the W3C endgame are economically viable in that a company playing that role could remain financially solvent - neither seem to offer the sort of high level returns that LL's investors may be expecting. Matthew _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From secret.argent at gmail.com Mon Jul 2 09:10:39 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 09:10:41 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> Message-ID: On 02-Jul-2007, at 10:35, Chance Unknown wrote: > remove the economy when traveling to foreign grids. That's basically what I said: each grid would have its own assets. > there is nothing that says lindens need to provide L$ outside the > confines of their servers. I'm not talking about L$ at all, this is all about assets in the sense of "the stuff on the asset servers". I suspect making *Lindens* transportable would actually be a MUCH easier (and profitable for Linden Labs) nut to crack. Let's say you were to travel from the Agni grid to the Disney grid, and back again. You wouldn't have access to your Silent Sparrow "Erstwhile" Brocade Overcoat on the Disney grid unless Silent Sparrow allowed that. Similarly, your Disney "Beauty and the Beast (Prince)" avatar would need to be bought again when you got back to Agni unless Disney chose to export it. But your Free Leather Jacket and Black Ripped Jeans would transfer fine. You could even have a menu entry for "check export" that would determine if the object was full perm (along with any assets required for it) or that the creator had marked it (and any required assets) exportable... and to where. "Your 'Meowe 1.1.5 (fantasy glider)' is exportable to: Aditi Grid, Agni Grid (current), Disney I, Disney II, Kali Grid, Sony Home Public, and There Again." From dzonatas at dzonux.net Mon Jul 2 09:18:01 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 2 09:17:42 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> Message-ID: <46892539.1090705@dzonux.net> Argent Stonecutter wrote: > Let's say you were to travel from the Agni grid to the Disney grid, > and back again. You wouldn't have access to your Silent Sparrow > "Erstwhile" Brocade Overcoat on the Disney grid unless Silent Sparrow > allowed that. Similarly, your Disney "Beauty and the Beast (Prince)" > avatar would need to be bought again when you got back to Agni unless > Disney chose to export it. But your Free Leather Jacket and Black > Ripped Jeans would transfer fine. > There already are evolved businesses for new currency. That is already in place. The export issues is different. If you really can't export your items in the practical sense, you really don't own them. That leads to Intellectual Property issues. -- Power to Change the Void From blakar at gmail.com Mon Jul 2 09:37:33 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 2 09:37:36 2007 Subject: [sldev] CPU detection code In-Reply-To: <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> Message-ID: <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> The issue is mostly that it doesn't identify any recent CPU. It just gives very generic info resulting in: Intel Pentium Pro (Unknown model) 146003 AMD (Unknown model) 110162 Intel Pentium 4 (Unknown model) 103905 That's about 70% of the registered CPU's. It's not too hard to improve upon that but in the end what we really need is statistics on the features the CPU supports. Just a list with total cpu's and how many of them support SSE, SSE2 and 3D!Now would do wonders. Dirk aka Blakar Ogre On 7/2/07, Argent Stonecutter wrote: > If there's a problem with the CPU detection code in SL, why not use > the code from BSD? Unlike the Linux code, it's unencumbered. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Mon Jul 2 09:49:31 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 2 09:49:11 2007 Subject: [sldev] CPU detection code In-Reply-To: <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> Message-ID: <46892C9B.4040507@dzonux.net> It's not just CPU features, as we also need BIOS features. Each OS controls the BIOS in different ways. The CPU features is the easy part. Dirk Moerenhout wrote: > It's not too hard to improve upon that but in the end what we really > need is statistics on the features the CPU supports. Just a list with > total cpu's and how many of them support SSE, SSE2 and 3D!Now would do > wonders. > > Dirk aka Blakar Ogre > > > > On 7/2/07, Argent Stonecutter wrote: >> If there's a problem with the CPU detection code in SL, why not use >> the code from BSD? Unlike the Linux code, it's unencumbered. >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From able.whitman at gmail.com Mon Jul 2 09:58:59 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 09:59:02 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> Message-ID: <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> I'm sorry, but the idea of encouraging the Balkanization of the grid economy is just plain silly. Certainly, independent grids could have their own isolated economies. But restricting access to the main grid's L$ economy is not to Linden Lab's advantage -- just the opposite, it is to their advantage to encourage the L$ economy to grow. Just because it's a virtual economy with virtual goods doesn't mean that basic market forces don't apply. The attractiveness of LL's economy will not be due to the fact that it is /their/ economy; there's nothing in the way LL runs the SL economy that makes it inherently better, it will be the fact that it is the /largest/ economy that makes it most attractive to enter. A larger economy means a more liquid market, and it means that there is a larger population of consumers available to buy and trade goods and services. Every roadblock that is imposed on the transfer virtual assets from one grid to another amounts to a tariff, and such roadblocks will only serve to discourage consumers from investing money in an economy where the feel locked in, and will in turn encourage them to purchase alternate goods which are unencumbered by such roadblocks. It might be an interesting technical challenge to figure out a permissions mechanism to control which goods can move between which grids. But such a mechanism would likely have to be centrally managed, and would require that the export/import permissions for existing goods and services be modified as new grids come online. Even if there were a usable import/export mechanism, producers who sell their goods without import/export restrictions will have a significant advantage over those who impose such restrictions on their products. Cheers, --Able On 7/2/07, Argent Stonecutter wrote: > > On 02-Jul-2007, at 10:35, Chance Unknown wrote: > > remove the economy when traveling to foreign grids. > > That's basically what I said: each grid would have its own assets. > > > there is nothing that says lindens need to provide L$ outside the > > confines of their servers. > > I'm not talking about L$ at all, this is all about assets in the > sense of "the stuff on the asset servers". I suspect making *Lindens* > transportable would actually be a MUCH easier (and profitable for > Linden Labs) nut to crack. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070702/955a0bae/attachment-0001.htm From secret.argent at gmail.com Mon Jul 2 10:45:17 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 10:45:24 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> Message-ID: <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> On 02-Jul-2007, at 11:58, Able Whitman wrote: > I'm sorry, but the idea of encouraging the Balkanization of the > grid economy is just plain silly. Certainly, independent grids > could have their own isolated economies. But restricting access to > the main grid's L$ economy is not to Linden Lab's advantage -- just > the opposite, it is to their advantage to encourage the L$ economy > to grow. I agree. Again, I'm NOT talking about closing off the "L$ economy" at all. I think you and Chance and Dzonatas are completely misinterpreting some part of my comments here, because currency is completely irrelevant to what I'm talking about: there's no reason you shouldn't be able to buy your "Beauty and the Beast (Prince)" avatar in L$. That's the *easy* part. > Every roadblock that is imposed on the transfer virtual assets from > one grid to another amounts to a tariff, and such roadblocks will > only serve to discourage consumers from investing money in an > economy where the feel locked in, and will in turn encourage them > to purchase alternate goods which are unencumbered by such roadblocks. That is why I *explicitly* said that the creators of the items should be able to decide how portable their products are. As you say... if people see transportable products as more valuable, they will buy more products from people who make their products transportable. If they see someone's Agni-exclusive content as being worth the restrictions, then they will buy it even if they can only use it on the Agni grid. The alternative, to make all content automatically freely distributable to any grid, will require solving the *much* harder (and in my opinion inherently unsolvable) general DRM problem. LL avoids that by keeping most of the restrictions in the server, and this server-enforced trust domain works surprisingly well. But it really depends on the servers all being in the same trust domain. Allowing people to bring open-source servers onto the Agni grid would eliminate that. I think it would be MUCH better to create an environment where the market can determine the balance rather than pulling the supports out from under the whole economy in one fell swoop. On 02-Jul-2007, at 11:18, Dzonatas wrote: > If you really can't export your items in the practical sense, you > really don't own them. Indeed. And yet people are still paying money for virtual property that they can't save, back up, or transport from one virtual world to another. On the other hand, if someone can bypass the rights system by simply traveling to the Ferengi Grid then what would happen to the economy that pays for Linden Labs to keep running the Agni grid? The rights system is often frustrating, far too coarse, restrictive, and really needs all kinds of changes. There are undoubtedly better balances that can be found, and letting alternative systems compete would allow all kinds of interesting things to bubble up. But it won't happen if the weakest system overrides all the rest. From able.whitman at gmail.com Mon Jul 2 11:01:24 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 11:01:27 2007 Subject: [sldev] Opening the server source? In-Reply-To: <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> Message-ID: <7b3a84fb0707021101g50a37f07i69c3d99d11a36c05@mail.gmail.com> > > I agree. Again, I'm NOT talking about closing off the "L$ economy" at > all. I think you and Chance and Dzonatas are completely > misinterpreting some part of my comments here, because currency is > completely irrelevant to what I'm talking about: there's no reason > you shouldn't be able to buy your "Beauty and the Beast (Prince)" > avatar in L$. That's the *easy* part. Right, I completely agree. I'm sorry if I replied to the wrong message in this thread; my disagreement wasn't with your point about having a common L$ currency (which is a good thing), but rather with the assertion that LL stands to benefit from walling off their economy, which is definitely not the case. The alternative, to make all content automatically freely > distributable to any grid, will require solving the *much* harder > (and in my opinion inherently unsolvable) general DRM problem. Yes, I'm not trying to argue that this is a trivial matter. I don't think it's quite so hairy as having to deal with general-purpose DRM, since every sim should be able to interpret object permissions (mod/copy/trans) the same, so at least there's not a heterogeneous environment where you have to map different kinds of rights between grids. Allowing people to bring open-source servers onto the Agni grid would > eliminate that. And I think this is eventually what LL wants to do -- allow 3rd party sims to join the Agni grid, in return for some recurring fee in order to hook those sims into LL's backend services. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070702/a7f7f007/attachment.htm From dale at daleglass.net Mon Jul 2 11:08:00 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 2 11:08:25 2007 Subject: [sldev] CPU detection code In-Reply-To: <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> Message-ID: <46893F00.1030303@daleglass.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dirk Moerenhout wrote: > The issue is mostly that it doesn't identify any recent CPU. It just > gives very generic info resulting in: Intel Pentium Pro (Unknown > model) 146003 AMD (Unknown model) 110162 Intel Pentium 4 > (Unknown model) 103905 > > That's about 70% of the registered CPU's. > > It's not too hard to improve upon that but in the end what we really > need is statistics on the features the CPU supports. Just a list with > total cpu's and how many of them support SSE, SSE2 and 3D!Now would > do wonders. Why not just read the data from /proc/cpuinfo? It includes about everything you might want to know as far as I can tell. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGiT76qzdyv8vqDKgRCiRiAKCSkZ97ZpuKwmolt7sclrVUYMxeLQCdHvuB BR4kcoWOMd3bYb9I3n8uotE= =tsnn -----END PGP SIGNATURE----- From blakar at gmail.com Mon Jul 2 11:10:24 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 2 11:10:27 2007 Subject: [sldev] CPU detection code In-Reply-To: <46893F00.1030303@daleglass.net> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> <46893F00.1030303@daleglass.net> Message-ID: <7992d0d60707021110m1a6f250fr1657b47295ec474@mail.gmail.com> > Why not just read the data from /proc/cpuinfo? It includes about > everything you might want to know as far as I can tell. Because the majority of the clients runs on Windows? Dirk aka Blakar Ogre From secret.argent at gmail.com Mon Jul 2 11:47:42 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 11:47:44 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7b3a84fb0707021101g50a37f07i69c3d99d11a36c05@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <7b3a84fb0707021101g50a37f07i69c3d99d11a36c05@mail.gmail.com> Message-ID: On 02-Jul-2007, at 13:01, Able Whitman wrote: > Yes, I'm not trying to argue that this is a trivial matter. I don't > think it's quite so hairy as having to deal with general-purpose > DRM, since every sim should be able to interpret object permissions > (mod/copy/trans) the same, so at least there's not a heterogeneous > environment where you have to map different kinds of rights between > grids. The point is that you have to *trust* every server owner to honor object permissions. Even if they're all running the same source code, that's not a given. If LL make the requirements for servers to hook into Agni strong enough to make this a negligible risk, then I'm pretty sure most of the interesting things people will want to do with an open source server will be eliminated. So the demand will still be there for grids that don't have to adhere to the rights system. How could Linden Labs fill that demand without *completely* fragmenting the SL universe? If they don't, someone else will. THAT is what I'm talking about. From dzonatas at dzonux.net Mon Jul 2 11:48:24 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 2 11:48:10 2007 Subject: [sldev] Opening the server source? In-Reply-To: <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> Message-ID: <46894878.9040307@dzonux.net> Argent Stonecutter wrote: > I think you and Chance and Dzonatas are completely misinterpreting > some part of my comments here, because currency is completely > irrelevant to what I'm talking about: there's no reason you shouldn't > be able to buy your "Beauty and the Beast (Prince)" avatar in L$. > That's the *easy* part. ... Hmm. Let me see if I can restate it in a way where it doesn't come across like a misinterpretation. > > On 02-Jul-2007, at 11:18, Dzonatas wrote: >> If you really can't export your items in the practical sense, you >> really don't own them. > > Indeed. And yet people are still paying money for virtual property > that they can't save, back up, or transport from one virtual world to > another. On the other hand, if someone can bypass the rights system by > simply traveling to the Ferengi Grid then what would happen to the > economy that pays for Linden Labs to keep running the Agni grid? > > The rights system is often frustrating, far too coarse, restrictive, > and really needs all kinds of changes. There are undoubtedly better > balances that can be found, and letting alternative systems compete > would allow all kinds of interesting things to bubble up. But it won't > happen if the weakest system overrides all the rest. > In a new way to say this, what I describe next is how currency is involved even in situations where L$ is not involved (as you touched on). Right now your L$ really don't give you complete ownership of the land because LL still hosts the site and such land can't be exported (at this time). Now, we could make it so the land is exportable by allowing a external sims (like this open server source thread). The next step up would be to move onto commercial licensing of the sims. Such license offers you to completely own the land, but I'm sure there will be restrictions to follow in order for your virtual land to connect to LL's assest servers to share (or serve, or host) what everyone else owns. Does that help? -- Power to Change the Void From dzonatas at dzonux.net Mon Jul 2 11:55:33 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 2 11:55:13 2007 Subject: [sldev] CPU detection code In-Reply-To: <46893F00.1030303@daleglass.net> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> <46893F00.1030303@daleglass.net> Message-ID: <46894A25.50609@dzonux.net> Dale Glass wrote: > Why not just read the data from /proc/cpuinfo? It includes about > everything you might want to know as far as I can tell. > > I have a patch here for the viewer that does exactly that. If there is a reason to get this done priority wise, I'll update it to the current version level and post it. -- Power to Change the Void From dale at daleglass.net Mon Jul 2 11:58:16 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Mon Jul 2 11:58:24 2007 Subject: [sldev] CPU detection code In-Reply-To: <7992d0d60707021110m1a6f250fr1657b47295ec474@mail.gmail.com> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> <46893F00.1030303@daleglass.net> <7992d0d60707021110m1a6f250fr1657b47295ec474@mail.gmail.com> Message-ID: <20070702185816.GA27731@bruno.sbruno> On Mon, Jul 02, 2007 at 08:10:24PM +0200, Dirk Moerenhout wrote: > >Why not just read the data from /proc/cpuinfo? It includes about > >everything you might want to know as far as I can tell. > > Because the majority of the clients runs on Windows? Ah, thought this was about the "CPU: Can't get terse CPU information" in the Linux about dialog. Haven't used the Windows client in nearly a year, so no clue what things are like there. Point still stands though, on Linux /proc/cpuinfo should be the easiest and most accurate way to do it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070702/7b376557/attachment-0001.pgp From phoenix at secondlife.com Mon Jul 2 12:09:36 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Jul 2 12:09:40 2007 Subject: [sldev] Building LLMozLib? In-Reply-To: <7b3a84fb0706300749s273bc27eh361c54730311ce9@mail.gmail.com> References: <7b3a84fb0706300749s273bc27eh361c54730311ce9@mail.gmail.com> Message-ID: Building llmozlib is somewhat difficult, so we package that pre-built and provide instructions for building it from mozilla/ubrowser sources if you are so inclined. http://ubrowser.com/llmozlib.php If you happen to be on windows with msvs 2003 or on a mac, the instructions are fairly complete for acquiring and building the library: http://wiki.secondlife.com/wiki/Compiling_the_viewer_libraries_% 28MSVS_2003%29#LLMozLib http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X% 29#Mozilla On 2007 Jun 30, at 07:49, Able Whitman wrote: > I'm curious why the source for LLMozLib isn't included with the > viewer source. Is there a licensing issue involved? > > My motives are selfish -- I'd like to be able to generate a debug > build in VC8 without disabling the embedded browser. But just for > the sake of completeness, it would be nice to have in order to > inspect and improve. > > The latest source on ubrowser.com is > "llmozlib_win_src_2006_11_06.zip", which is clearly not the latest > version, as it's rather old and lacks cookie support. > > --Able > _______________________________________________ > 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/20070702/894bd65b/PGP.pgp From able.whitman at gmail.com Mon Jul 2 12:18:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 12:18:34 2007 Subject: [sldev] Building LLMozLib? In-Reply-To: References: <7b3a84fb0706300749s273bc27eh361c54730311ce9@mail.gmail.com> Message-ID: <7b3a84fb0707021218t3fdc8de8v286515aeb1cda097@mail.gmail.com> Thanks, Phoenix! I'd be more than happy to jump through all the hoops to get llmozlib compiled so I can run a debug build under VC2005, but it would sure be easier if you folks could just update the debug builds of "llmozlib.lib" and "llmozlib-vc8.lib" that are included in the source distribution :) On 7/2/07, Phoenix wrote: > > Building llmozlib is somewhat difficult, so we package that pre-built > and provide instructions for building it from mozilla/ubrowser > sources if you are so inclined. > > http://ubrowser.com/llmozlib.php > > If you happen to be on windows with msvs 2003 or on a mac, the > instructions are fairly complete for acquiring and building the library: > > http://wiki.secondlife.com/wiki/Compiling_the_viewer_libraries_% > 28MSVS_2003%29#LLMozLib > http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X% > 29#Mozilla > > > > On 2007 Jun 30, at 07:49, Able Whitman wrote: > > I'm curious why the source for LLMozLib isn't included with the > > viewer source. Is there a licensing issue involved? > > > > My motives are selfish -- I'd like to be able to generate a debug > > build in VC8 without disabling the embedded browser. But just for > > the sake of completeness, it would be nice to have in order to > > inspect and improve. > > > > The latest source on ubrowser.com is > > "llmozlib_win_src_2006_11_06.zip", which is clearly not the latest > > version, as it's rather old and lacks cookie support. > > > > --Able > > _______________________________________________ > > 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/20070702/78bbbb61/attachment.htm From nicholaz at blueflash.cc Mon Jul 2 12:58:38 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 2 12:58:48 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46892539.1090705@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <46892539.1090705@dzonux.net> Message-ID: <468958EE.6020209@blueflash.cc> > The export issues is different. If you really can't export your items in > the practical sense, you really don't own them. That leads to > Intellectual Property issues. Well, broad acceptance doesn't happen through a company doing something they like, but through users getting what they want. And if the music and software industry is an example, it will be client side assets. Music is on my computer, software is on my computer and I doubt that any large scale standardization will happen with any single commercial entity being in control of of a central part of the system. Or can anyone imagine that a team like the one doing Apache (and in my view the sim isn't any different from that in technical terms) working as effectively and furiously to make a company like Linden Labs happy? I'm pretty sure that as soon as a viable sim side is available through open source, it will draw a lot of developers and quite naturally, because these developers being open sourcers, one of the first things they will do is to make the inventory something that is open assets. It just makes sense, because it will be the easiest and natural thing to do to solve a problem, because these people think "open", because that way they will speed up development by doing away with something that causes LL endless trouble and for which they see no good use for anyway. It may not draw as many builders as LL has now, because a lot there is driven by commerce, but there are many excellent builders doing freebies and if the environment and everything is attractive, you'll see a lot of stuff getting there soon. To be honest, I'd be there pretty quickly myself. One of the things that really gets on my nerves are the commercial builders and vendors in SL, because they are the ones who complain loudest about problems and provide nothing to the community. In that mindset, I might as well sell my patches. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Mon Jul 2 13:11:39 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 2 13:11:50 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> Message-ID: <46895BFB.3060604@blueflash.cc> > Just because it's a virtual economy with virtual goods doesn't mean that > basic market forces don't apply. The attractiveness of LL's economy will > not be due to the fact that it is /their/ economy; there's nothing in > the way LL runs the SL economy that makes it inherently better, it will > be the fact that it is the /largest/ economy that makes it most > attractive to enter. A larger economy means a more liquid market, and it > means that there is a larger population of consumers available to buy > and trade goods and services. That's what the music industry is finding out. People pay 50% for un-DRM'd music and they sell two times more of that, despite the fact that it can be copied among buddies or even P2P. If assets go the same way (basic protection scheme as with software maybe ... which is client side and which is sufficient for software worth hundreths of dollars) then you'll have it. And if pricing is similar to what assets cost today on the grid, most people will just not bother copying them, because it's not worth the effort and many people do play fair (and the others will never pay anyway ... I found that out through the software which I develop and sell for a living). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From scott at scottnorman.com Mon Jul 2 13:38:39 2007 From: scott at scottnorman.com (Scott T. Norman) Date: Mon Jul 2 13:38:44 2007 Subject: [sldev] Building LLMozLib? In-Reply-To: References: <7b3a84fb0706300749s273bc27eh361c54730311ce9@mail.gmail.com> Message-ID: I tried building llmozlib on Mac PowerBook (PPC) a long time ago (1.15.x?) and could never get it to build. Don't remember what the errors were, though once I understood the binaries were available just used those. Blessings, Scott www.scottnorman.com God's covenant of revival fire has fallen upon Orange County, California, so that the Church of Orange County will become one and bring healing, salvation, and redemption to the county, and to take part in the harvest of one billion plus souls into the Kingdom of God. - Scott Norman On Jul 2, 2007, at 12:09 PM, Phoenix wrote: > Building llmozlib is somewhat difficult, so we package that pre- > built and provide instructions for building it from mozilla/ > ubrowser sources if you are so inclined. > > http://ubrowser.com/llmozlib.php > > If you happen to be on windows with msvs 2003 or on a mac, the > instructions are fairly complete for acquiring and building the > library: > > http://wiki.secondlife.com/wiki/Compiling_the_viewer_libraries_% > 28MSVS_2003%29#LLMozLib > http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Mac_OS_X% > 29#Mozilla > > > > On 2007 Jun 30, at 07:49, Able Whitman wrote: >> I'm curious why the source for LLMozLib isn't included with the >> viewer source. Is there a licensing issue involved? >> >> My motives are selfish -- I'd like to be able to generate a debug >> build in VC8 without disabling the embedded browser. But just for >> the sake of completeness, it would be nice to have in order to >> inspect and improve. >> >> The latest source on ubrowser.com is >> "llmozlib_win_src_2006_11_06.zip", which is clearly not the latest >> version, as it's rather old and lacks cookie support. >> >> --Able >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > 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/20070702/c9ff4101/attachment-0001.htm From dzonatas at dzonux.net Mon Jul 2 13:48:19 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 2 13:47:58 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46895BFB.3060604@blueflash.cc> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <46895BFB.3060604@blueflash.cc> Message-ID: <46896493.10907@dzonux.net> Nicholaz Beresford wrote: > And if pricing is similar to what assets cost today on the grid, most > people will just not bother copying them, because it's not worth the > effort and many people do play fair (and the others will never pay > anyway ... I found that out through the software which I develop and > sell for a living). > > That is very true in a micro-economy. In America's economy, the micro-economy is not easily accessible. That accessibility is more of the reason why someone would just go straight-up copy something and not pay a dime. The micro-economy gives that much greater of a chance for a monetary transaction to occur. The micro-economy can easily break the stale idleness of an economy such as the US dollar. In that since, it appears the the RIAA has fought on the wrong ground. Maybe, they should change their name to RIAI and post *free* patch to Winamp to support WICS: https://www.wicexchange.com/ Surely, the RIAA has spent enough in legal fees by now to likewise pay a couple of programmers to finish a job to write the patch and retire as a bonus. -- Power to Change the Void From tom at cornish-pasty.com Mon Jul 2 15:27:58 2007 From: tom at cornish-pasty.com (Thomas Rowland) Date: Mon Jul 2 15:28:08 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) In-Reply-To: <468661DC.60903@blueflash.cc> Message-ID: <000901c7bcf8$4001a770$64001f52@tomhome> Sorry to keep you waiting on an answer - had other things to do. Works fine. > -----Original Message----- > From: Nicholaz Beresford > > Thomas, > > did you try the leak patch under 2005? Would like to > know if it works. > > https://wiki.secondlife.com/wiki/Finding_leaks > > > Nick > > From secret.argent at gmail.com Mon Jul 2 15:47:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 15:47:25 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46894878.9040307@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> Message-ID: > Does that help? It helps me understand what your position is. It doesn't help me understand your position. Right now I get the closest thing to "complete ownership of land" on the sims that Linden Labs most closely controls. Where Linden Labs control is weaker, my ability to own land is weaker... that is, on a private island even if I buy land it's only rented. Why would you expect a private server owner to provide me more "ownership" of land than a private sim owner? Or are you equating "owning land" to "owning a sim"? Even there you're beholden to Linden Labs for the access to the grid, to an ISP for access to the Internet, and to a hosting site for power and maintenance. "Land" in SL is the thing that seems hardest to treat as something you "own" rather than "rent". Land is processor time that you rent, that's all. The *configuration* of that land and the *contents* of that land, maybe, but there you run into the property rights problem that I started with: when you buy some asset in SL you're rarely buying unlimited rights to that asset. If you can take that out of SL you're taking more rights than you're entitled to. > Such license offers you to completely own the land, but I'm sure > there will be restrictions to follow in order for your virtual land > to connect to LL's assest servers to share (or serve, or host) what > everyone else owns. Right. That's the point. If you want to connect your virtual land to Agni, to use the property right you're interested in, you will have to give up so many rights in that land (including the right to retain the contents of the server if you remove it from the grid) that you might as well simply buy a private island. And if you're going to retain the kinds of rights that make it worthwhile to talk of "exporting" the land in any meaningful sense, should you be allowed to connect to Agni? That's what I'm going on about, here. What kinds of things could be done to accommodate people who want to control their "real estate" in Second Life without wrecking the economy of Second Life. From monkowsk at watson.ibm.com Mon Jul 2 15:53:47 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jul 2 15:53:12 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46858EC0.7070309@gwala.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> <46858B1D.10907@watson.ibm.com> <46858EC0.7070309@gwala.net> Message-ID: <468981FB.1040903@watson.ibm.com> Adam, I guess "message server" was a poor choice of terminology. Perhaps "transaction server" would be more descriptive. The transaction server would do the processing that the current sim server does to generate messages to the other servers. Some may be simple pass-through, but the current "trusted" processing that the current sim server does could still be done on LL transaction servers. Having specialized per-service proxies leaves you with concurrency and rollback problems, leaving more computation in the viewer, which of course, is not trusted. Yes, the scripts may be visible to the physics server, but scripts are code, and, well, this is an open source project. If you choose, you can disallow your main grid scripts from being exported to private sims and vice versa. Open sourcing just the physics and scripting could generate a lot of creativity. I'd hate to have to wait for a complete open source server before being able to do anything. That could be a very long time. Soft Linden said, > 2) If you can point to specific modules of the sim that you'd like to > see and can help me with an argument for getting them open sooner, I'm > all ears. I'm asking for physics and scripting. Mike Adam Frisby wrote: > ...having a server manage connections for the client strikes me as somewhat > unneeded complexity since all it is doing is proxying the connections; > which could be served better by having specialised per-service proxies. > > Adam > > Mike Monkowski wrote: > >> Actually, I was suggesting something between these two. By breaking >> the sim into a message server and a physics server, you don't have to >> change the rest of the architecture. The viewer sees no change. The >> specialty servers see no change. One box is just split into two with >> the rest of the connections remaining intact. It should be a lot >> easier to implement. >> >> Mike From adam at gwala.net Mon Jul 2 16:10:09 2007 From: adam at gwala.net (Adam Frisby) Date: Mon Jul 2 16:10:32 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468981FB.1040903@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> <46858B1D.10907@watson.ibm.com> <46858EC0.7070309@gwala.net> <468981FB.1040903@watson.ibm.com> Message-ID: <468985D1.4010105@gwala.net> I think the best focus there is to try keep everything as standard as possible, for these central services your not gaining much by putting another server in the middle other than read-only not-regularly-updated data, so keeping the interfaces along HTTP and using a configured proxy like squid would seem ideal. In terms of scripting / physics engines - you still need to be able to upload and compile, and once you are allowing that, you open a big can of worms with security, doing it without opening that would be a very interesting challenge. I do agree it might be a while before we see the official simulator open though. I'm betting 12-18+ months myself. Adam Mike Monkowski wrote: > Adam, > > I guess "message server" was a poor choice of terminology. Perhaps > "transaction server" would be more descriptive. The transaction server > would do the processing that the current sim server does to generate > messages to the other servers. Some may be simple pass-through, but the > current "trusted" processing that the current sim server does could > still be done on LL transaction servers. > > Having specialized per-service proxies leaves you with concurrency and > rollback problems, leaving more computation in the viewer, which of > course, is not trusted. > > Yes, the scripts may be visible to the physics server, but scripts are > code, and, well, this is an open source project. If you choose, you can > disallow your main grid scripts from being exported to private sims and > vice versa. > > Open sourcing just the physics and scripting could generate a lot of > creativity. I'd hate to have to wait for a complete open source server > before being able to do anything. That could be a very long time. > > Soft Linden said, > >> 2) If you can point to specific modules of the sim that you'd like to >> see and can help me with an argument for getting them open sooner, I'm >> all ears. > > I'm asking for physics and scripting. > > Mike > > > Adam Frisby wrote: > >> ...having a server manage connections for the client strikes me as >> somewhat unneeded complexity since all it is doing is proxying the >> connections; which could be served better by having specialised >> per-service proxies. >> >> Adam >> >> Mike Monkowski wrote: >> >>> Actually, I was suggesting something between these two. By breaking >>> the sim into a message server and a physics server, you don't have to >>> change the rest of the architecture. The viewer sees no change. The >>> specialty servers see no change. One box is just split into two with >>> the rest of the connections remaining intact. It should be a lot >>> easier to implement. >>> >>> Mike > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From monkowsk at watson.ibm.com Mon Jul 2 16:11:13 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jul 2 16:11:17 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685A426.7070809@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> Message-ID: <46898611.1090206@watson.ibm.com> Jason Giglio wrote: > For $6700 per server + $1180 per month per server, I think they are > quite happy hosting server farms. Although some companies like to brag about increased revenue, it's really the profit that keeps them going. Reduce those charges by the cost of the server, its maintenance, overhead, and support, and you can charge less but keep the same profit. Remember LL would still sell the ability to connect to the main grid, so their income source would not disappear. > Any sort of open grid is going to decimate the market for linden land. I don't agree. I see no reason why this should be the case. > To put it in perspective, if you were LL you'd need about 150-200 new > premium accounts for each server you don't host, to make up the difference. I never suggested that the connection of private sims should be free. > And those accounts would use the bits of the service they are having the > most trouble scaling well. Huge databases and transaction servers are everywhere. If LL is having trouble scaling these, it's just because of bad architecture. There is nothing inherently difficult about them. Mike From matsuu at gmail.com Mon Jul 2 17:03:54 2007 From: matsuu at gmail.com (MATSUU Takuto) Date: Mon Jul 2 17:03:57 2007 Subject: [sldev] -Werror? In-Reply-To: <1182973288.27151.2.camel@localhost> References: <1182896080.14627.3.camel@localhost> <468199D2.4030606@lindenlab.com> <1182904406.14627.22.camel@localhost> <4682B1F0.7070707@lindenlab.com> <1182973288.27151.2.camel@localhost> Message-ID: same here. I created a patch. http://overlays.gentoo.org/dev/matsuu/browser/secondlife/games-simulation/secondlife/files/secondlife-1.17.2.0-size_t.patch 2007/6/28, Callum Lerwick : > On Wed, 2007-06-27 at 11:52 -0700, Bryan O'Sullivan wrote: > > Callum Lerwick wrote: > > > On Tue, 2007-06-26 at 15:57 -0700, Bryan O'Sullivan wrote: > > >> Callum Lerwick wrote: > > >>> Argh. Who added -Werror to the build flags? > > >> What version of gcc are you using? I haven't seen those errors with gcc > > >> 3.4 through 4.1. > > > > > > Those ones in particular are probably more a result of Fedora's glibc. > > > > I'm building on Fedora 7, and I don't see these problems. > > Are you using the standard Fedora build flags? In particular, I think > its -Wp,-D_FORTIFY_SOURCE=2 doing it. > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From monkowsk at watson.ibm.com Mon Jul 2 17:09:54 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Jul 2 17:09:57 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468985D1.4010105@gwala.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> <46858B1D.10907@watson.ibm.com> <46858EC0.7070309@gwala.net> <468981FB.1040903@watson.ibm.com> <468985D1.4010105@gwala.net> Message-ID: <468993D2.2070601@watson.ibm.com> Adam Frisby wrote: > In terms of scripting / physics engines - you still need to be able to > upload and compile, and once you are allowing that, you open a big can > of worms with security, doing it without opening that would be a very > interesting challenge. I understand that scripts could be visible to the private sims, but they're just assets served up by another server. If you don't want your scripts sent to private sims, it would be just as easy as making them non-editable now. Just another flag in a database. The upload part I don't understand, though. You would upload through the LL transaction server, not the physics/scripting server. The physics/scripting server would also get the objects through the LL transaction server. The viewer would in turn receive objects from the physics/scripting server. Presumably, the server would have a local cache, so the viewer wouldn't see the fetch lag for objects that are resident to the sim. Mike From adam at gwala.net Mon Jul 2 17:20:04 2007 From: adam at gwala.net (Adam Frisby) Date: Mon Jul 2 17:20:12 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468993D2.2070601@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> <46858B1D.10907@watson.ibm.com> <46858EC0.7070309@gwala.net> <468981FB.1040903@watson.ibm.com> <468985D1.4010105@gwala.net> <468993D2.2070601@watson.ibm.com> Message-ID: <46899634.5080407@gwala.net> Right, but are we talking scripting here or hard compiled engines themselves? (Little confused what's being reffered to) Adam Mike Monkowski wrote: > Adam Frisby wrote: > >> In terms of scripting / physics engines - you still need to be able to >> upload and compile, and once you are allowing that, you open a big can >> of worms with security, doing it without opening that would be a very >> interesting challenge. > > > I understand that scripts could be visible to the private sims, but > they're just assets served up by another server. If you don't want your > scripts sent to private sims, it would be just as easy as making them > non-editable now. Just another flag in a database. > > The upload part I don't understand, though. You would upload through > the LL transaction server, not the physics/scripting server. The > physics/scripting server would also get the objects through the LL > transaction server. The viewer would in turn receive objects from the > physics/scripting server. Presumably, the server would have a local > cache, so the viewer wouldn't see the fetch lag for objects that are > resident to the sim. > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Mon Jul 2 17:46:58 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 2 17:46:38 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> Message-ID: <46899C82.1000404@dzonux.net> Argent Stonecutter wrote: >> Does that help? > > It helps me understand what your position is. It doesn't help me > understand your position. As long as we are on the same page, that is good enough. Let me answer your questions. > > Right now I get the closest thing to "complete ownership of land" on > the sims that Linden Labs most closely controls. Where Linden Labs > control is weaker, my ability to own land is weaker... that is, on a > private island even if I buy land it's only rented. > > Why would you expect a private server owner to provide me more > "ownership" of land than a private sim owner? Limitations can be overcome easily. For example, why should businesses wait for LL to provide the best scripting language when one can build the best sim for their business with the tools and scripting interface for their needs. A private sim owner would have to provide all the tools. A private server owner only has to provide the basic platform. If the private sim was the real answer, nobody would want to, likewise, host their own Apache server. > > Or are you equating "owning land" to "owning a sim"? ... That wasn't the intention of my position. Land is land... and virtual land can be made of sims... but both virtal land and real land is made of sand... real sand. The group I started is not "Dreamland".. it is "Dreamsand". If one would ask the difference, one could put on the old Metallica tune on... Enter Sandman. =) Dreamland and everybody that has followed foot has the line drawn on their business model. If you are worried about the economy, you would be aware of that line. I'm not after just the land. =) > > Even there you're beholden to Linden Labs for the access to the grid, > to an ISP for access to the Internet, and to a hosting site for power > and maintenance. ... Hmm. ISPs don't make the Internet. Telephone companies have been a great instrument to speed up the Internet connections. Consider such businesses power play industry like http://www.ballard.com and you'll probably understand how power and maintenance can be... well, like... A Happy July 4th! > > "Land" in SL is the thing that seems hardest to treat as something you > "own" rather than "rent". Land is processor time that you rent, that's > all. ... That would be more of a false sense of security started by the telephone companies and their terms of service agreements where you aren't suppose to have any other Internet connection at your home besides their own. That was the only way for them to make money. They had to stop the growth of the Internet by mandate of a star topology. The Internet was never intended to be a star topology. It was and still is intended to be quite an arbitrary mesh. The star topologies is the limiting factor in "Land" in SL. Nonetheless, we don't need to worry about these things right now. How the aspects of Land changes in SL won't destroy the economy unless LL limits itself, also. > > The *configuration* of that land and the *contents* of that land, > maybe, but there you run into the property rights problem that I > started with: when you buy some asset in SL you're rarely buying > unlimited rights to that asset. If you can take that out of SL you're > taking more rights than you're entitled to. Hmm. I understand your fear here. We see the same thing, but our fears are different about it. Where one sees a beast the other sees beauty. > If you want to connect your virtual land to Agni, to use the property > right you're interested in, you will have to give up so many rights in > that land (including the right to retain the contents of the server if > you remove it from the grid) that you might as well simply buy a > private island. And if you're going to retain the kinds of rights that > make it worthwhile to talk of "exporting" the land in any meaningful > sense, should you be allowed to connect to Agni? > > That's what I'm going on about, here. What kinds of things could be > done to accommodate people who want to control their "real estate" in > Second Life without wrecking the economy of Second Life. ... Yes, exactly. If the server contains special scripts, lets say written in Mono instead of LSL, to access special C# libraries only available on that server's land, then those scripts are completely worthless to anywhere else on Agni. C# is not the best most powerful language, but under Mono it can be controlled pretty well to allow residents to develop on a special sim. A demo, I know people want to see a demo. Let me see what I can do this week (or two) to let my Apache server that runs my old (pre-java!) object-oriented scripting language open a port to the public for trial. It has a wiki like interface where you can program it over the web. If you are used to interfaces of web-wikis and the old LambaMoos, think of the mother-of-all-mutant-hyrbids and you'll understand how this works. A simple name for it could be "co-generation". Hmm. It's on my coLinux server, so I'll have to upload it to my public server. Oh see SVC-98, I wanted to integrate it with LL's sim, but... How do we do it without wrecking the economy of Second Life? Simple, Second Life shouldn't wreck the economy of the residents. Does SL/LL push people to the streets? I know the answer to that! =) Interesting, it appears that Anshe Chung has started to pave the way for her own street to walk on. http://wselive.com/news/show/10 DSE, hehe D.S. coincadink 'nuff said.... thank you for reading. -- Power to Change the Void From secret.argent at gmail.com Mon Jul 2 19:37:07 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 19:37:09 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46899C82.1000404@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> Message-ID: > lets say written in Mono instead of LSL Side comment: Mono is a VM. LSL is a programming language. You don't write in mono, you compile to mono... the source may still be in LSL. IN fact you've got an LSL to Mono compiler on your disk right now. From adam at gwala.net Mon Jul 2 19:52:45 2007 From: adam at gwala.net (Adam Frisby) Date: Mon Jul 2 19:52:54 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> Message-ID: <4689B9FD.2020307@gwala.net> Argent Stonecutter wrote: > IN fact you've got an LSL to Mono compiler on your disk right now. We do? I thought LL were keeping that internal since it's simulator-only stuff? Adam From soft at lindenlab.com Mon Jul 2 20:08:36 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 2 20:08:38 2007 Subject: [sldev] Accessing SL viewer crash reports? In-Reply-To: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> References: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> Message-ID: <9e6e5c9e0707022008o516ae7fdgb6b789383afea7c9@mail.gmail.com> On 6/26/07, Able Whitman wrote: > I have a couple of friends who have been experiencing regular crashes with > the 1.17.1.0 viewer release. This led me to wonder: Are there any plans to > make information from viewer crash reports accessible to open source > contributors? > > The crash call stacks in the wiki > (https://wiki.secondlife.com/wiki/Crash_Reports) are > somewhat helpful, but are these top 10 lists still up-to-date? Some > additional statistics about the frequency of the different crashes would > also be useful, as well as more details about which environments (OS, video > card, driver version, etc.) encounter which crashes most often. And, at > least in the case of investigating crashes on a Windows system, minidump > files would be tremendously useful. I'm pinging internally on this. From soft at lindenlab.com Mon Jul 2 20:14:41 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 2 20:14:42 2007 Subject: [sldev] Blog, 1.17.2, 1.18 postponed In-Reply-To: <4681BE75.6020701@blueflash.cc> References: <4681BE75.6020701@blueflash.cc> Message-ID: <9e6e5c9e0707022014g37aa9b83ob2df3c035be079fb@mail.gmail.com> This was forwarded around internally, but I realized nobody ever said thanks for the comment on the list... which means we still have some work to do on that wall... but we knew that! Thank you on behalf of the Lindens. :) On 6/26/07, Nicholaz Beresford wrote: > > Hi Everybody and Lindens in particular. > > Dunno how to put it so that it comes across the way I intend > it, but what I've seen in the last 24 hours (on the blog, > with the releases, etc.) is so unlike what I've seen in the > past weeks, that I seriously consider to believe in an incident > of alien abduction at Linden Lab sites :-) > > This was an excellent example of how to do things right > (as far as "right" is defined in my book). > > And I would really recommend to read the blog comments there, > I think you haven't received that much public affection from > the community in quite some time. > > Double thumbs up from me ... yay! > > > Nick > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Mon Jul 2 20:19:50 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 2 20:19:53 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706270654m28fd3cf2w349549e0084924bd@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> <468225C0.4070105@blueflash.cc> <7b3a84fb0706270539qb99faccvafcc85ccfa147e18@mail.gmail.com> <46825C84.8000707@blueflash.cc> <7b3a84fb0706270654m28fd3cf2w349549e0084924bd@mail.gmail.com> Message-ID: <9e6e5c9e0707022019y46470586p43b25f00c2a335b4@mail.gmail.com> I don't believe there's any way to store arbitrary data on the server. If you get this working with a local file and there's good demand for and acceptance of the feature, we'd gladly work with you on a server change. On 6/27/07, Able Whitman wrote: > Ah, right, I understand. Yeah, I think I'm going to have to do something > like that, because the alternatives are pretty hackish. > > > On 6/27/07, Nicholaz Beresford wrote: > > > > Understood. This was mainly meant as an easy workaround > > for development until you get some Linden assistance > > from the server side. > > > > > > Nick > > > > > > > > Able Whitman wrote: > > > I want the mute list to remain independent of the viewer, so that > > > regardless of where you're accessing the grid from, you still get the > > > same mute list as you would on your own machine. Plus, I'm sure there > > > are plenty of people who regularly access the grid from more than one > > > machine ( e.g., at work and at home), and it would be annoying to have > > > to maintain separate lists, I think. > > > > > > On 6/27/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > > > wrote: > > > > > > > > > Able Whitman wrote: > > > > I just want to say to the nice folks at LL that the fact that the > > > > service both discards the MuteFlags field, and limits the length > > > of the > > > > MuteName field to 63 chars is really cramping my style. :) > > > > > > > > Is there a way for the viewer to persist, in the dataserver, some > > > > user-specific data across sessions? > > > > > > Why don't you just use a local file? > > > > > > > > > > > > Nick > > > > > > > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From secret.argent at gmail.com Mon Jul 2 20:23:10 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 2 20:23:11 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4689B9FD.2020307@gwala.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> Message-ID: On 02-Jul-2007, at 21:52, Adam Frisby wrote: > Argent Stonecutter wrote: >> IN fact you've got an LSL to Mono compiler on your disk right now. > We do? I thought LL were keeping that internal since it's simulator- > only stuff? linden/indra/lscript/lscript_compile/lscript_tree.cpp Depending on how recurse is called it will compile LSL bytecode, emit CIL assembly for Mono, pretty print, ... The basic runtime is in lscript_execute. From soft at lindenlab.com Mon Jul 2 20:33:24 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 2 20:33:25 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <46883C7A.8060100@blueflash.cc> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> <46880CFB.2030907@blueflash.cc> <7992d0d60707011532y4afb15bcv8cbd9296060920bb@mail.gmail.com> <46883C7A.8060100@blueflash.cc> Message-ID: <9e6e5c9e0707022033v4790ff50r816adaf4c3d9b5ef@mail.gmail.com> With Pentiums, virtual function calls can put the brakes on speculative execution and branch prediction. I'm not up to date on the effect on newer processors, but I'd bet costs remain. If you see unnecessary virtual functions in code that gets called a *lot*, it's probably worth cleaning up. On 7/1/07, Nicholaz Beresford wrote: > > > Dirk Moerenhout wrote: > >> On the design side however, unless you are dealing with > >> extremely performance sensitive code, if in doubt, it's > >> usually a good idea to make functions virtual and not need > >> it than the other way round. > > > > Well we're dealing with performance sensitive code as it's one of the > > top functions (when using an optimised viewer) even though it has only > > 4 instructions (including RET ...). I get upto 2% of the cycle samples > > in those 4 instructions and that doesn't take into account all the > > wasted cycles on additional instructions that are needed to do the > > call. > > There's definitely overhead in the call itself too. I think the > pointer to the virtual function map is the first or second member > in the objects, so the call is something like > > this->vfptrs[](); > > which I think I've seen translated into two or three machine > instructions, including the call. > > > If it is speed sensitive and if you can't find an overload there > (which should be easy to spot by the same name), try it non-virtual. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Mon Jul 2 20:38:40 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 2 20:38:42 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> Message-ID: <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> On 7/2/07, Able Whitman wrote: > I'd like to be able to distribute a test version of the viewer with my > changes to implement Mute Visibility applied. Because the patch involves > some UI-related XML changes as well as code changes, it's much easier to > distribute it as an installer, rather than a zip file with a bunch of files > that need to be copied / overwritten. It also makes it very easy for people > to go back to the official viewer if they run into problems. > [...] > > Am I allowed to distribute this installer for other people to use? This is a good one to ping Rob or the licensing SL alias on directly. I'm betting if you want to get Linden Lab's blessings on an official, sanctioned release though, you'd find you had to relicense some libraries yourself. :( From soft at lindenlab.com Mon Jul 2 20:41:26 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 2 20:41:28 2007 Subject: [sldev] SLDev-Traffic #18 - Now with 100% less Seventeen(tm) Message-ID: <9e6e5c9e0707022041v689cd852v43e2232345e64680@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_18 SLDev-Traffic number 18 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From able.whitman at gmail.com Mon Jul 2 21:26:32 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 21:26:34 2007 Subject: [sldev] Accessing SL viewer crash reports? In-Reply-To: <9e6e5c9e0707022008o516ae7fdgb6b789383afea7c9@mail.gmail.com> References: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> <9e6e5c9e0707022008o516ae7fdgb6b789383afea7c9@mail.gmail.com> Message-ID: <7b3a84fb0707022126pa759a44rbe57909d7638f976@mail.gmail.com> Thanks, Soft. You rock steady. :) Even if we can't see the raw crash reports, a regularly-updated list of top-10 crashes (with callstacks and whatever other details you can release) for each platform would still be useful. As an aside, on the Windows platform, have you looked into the possibility of hooking into the Microsoft Online Crash Analysis tools (aka Watson)? I don't know what capabilities the SL crash logger has on your end, nor do I know the current requirements for getting access to 3rd party crash reports collected by MS. (I think it used to be that a 3rd party app had to be logo-certified, but I don't know if that's still the case.) On 7/2/07, Soft Linden wrote: > > > I'm pinging internally on this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070703/910634c4/attachment.htm From able.whitman at gmail.com Mon Jul 2 21:32:35 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 21:32:37 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <9e6e5c9e0707022019y46470586p43b25f00c2a335b4@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> <468225C0.4070105@blueflash.cc> <7b3a84fb0706270539qb99faccvafcc85ccfa147e18@mail.gmail.com> <46825C84.8000707@blueflash.cc> <7b3a84fb0706270654m28fd3cf2w349549e0084924bd@mail.gmail.com> <9e6e5c9e0707022019y46470586p43b25f00c2a335b4@mail.gmail.com> Message-ID: <7b3a84fb0707022132l25e81f00he96b9c65a55f7bc6@mail.gmail.com> Well, I'm nothing if not persistent, and I was able to use the mute list functionality as it currently exists to sort of do what I want. It's not a particularly pretty solution, and it has limitations, but it works at least for testing purposes. I think that it would be useful to have a standard mechanism to store per-user viewer state, similarly to Qarl's suggestion of being able to store per-object state. Even something as simple as a pair of a UUID and a string (of up to 255 chars) would be fantastic. I'll submit a feature request in JIRA and everyone can argue with me about it there. :) On 7/2/07, Soft Linden wrote: > > I don't believe there's any way to store arbitrary data on the server. > If you get this working with a local file and there's good demand for > and acceptance of the feature, we'd gladly work with you on a server > change. > > On 6/27/07, Able Whitman wrote: > > Ah, right, I understand. Yeah, I think I'm going to have to do something > > like that, because the alternatives are pretty hackish. > > > > > > On 6/27/07, Nicholaz Beresford wrote: > > > > > > Understood. This was mainly meant as an easy workaround > > > for development until you get some Linden assistance > > > from the server side. > > > > > > > > > Nick > > > > > > > > > > > > Able Whitman wrote: > > > > I want the mute list to remain independent of the viewer, so that > > > > regardless of where you're accessing the grid from, you still get > the > > > > same mute list as you would on your own machine. Plus, I'm sure > there > > > > are plenty of people who regularly access the grid from more than > one > > > > machine ( e.g., at work and at home), and it would be annoying to > have > > > > to maintain separate lists, I think. > > > > > > > > On 6/27/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > > > > wrote: > > > > > > > > > > > > Able Whitman wrote: > > > > > I just want to say to the nice folks at LL that the fact that > the > > > > > service both discards the MuteFlags field, and limits the > length > > > > of the > > > > > MuteName field to 63 chars is really cramping my style. :) > > > > > > > > > > Is there a way for the viewer to persist, in the dataserver, > some > > > > > user-specific data across sessions? > > > > > > > > Why don't you just use a local file? > > > > > > > > > > > > > > > > Nick > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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/20070703/a926b42e/attachment.htm From able.whitman at gmail.com Mon Jul 2 21:38:36 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 21:38:38 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> Message-ID: <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> Wow, I feel like tonight is the Soft and Able hour... :) On 7/2/07, Soft Linden wrote: > > > This is a good one to ping Rob or the licensing SL alias on directly. > I'm betting if you want to get Linden Lab's blessings on an official, > sanctioned release though, you'd find you had to relicense some > libraries yourself. :( > Just to clarify, I'm definitely not looking for an official blessing. My only goal is to make it easier to package up a test build of the viewer that involves more than just the viewer executable. If I have to distribute a Zip file of loose files and provide instructions for hacking up an existing client install, that's okay. But being able to roll my own installer means that people who want to test my private build (or anyone's private build for that matter) can have a convenient way of installing a side-by-side viewer so that they can easily fallback to the official viewer if they so choose. Perhaps a compromise solution would be to distribute an installer which includes all the files except for the libraries that aren't redistributable? Then users could simply copy those missing files from their existing install into the folder for the private build. I don't know exactly what files can and can't be redistributed, nor do I pretend to know the particulars of the licensing issues, so I'll CC: Rob on this as well. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070703/84bbf153/attachment.htm From nicholaz at blueflash.cc Mon Jul 2 23:29:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 2 23:29:33 2007 Subject: [sldev] Accessing SL viewer crash reports? In-Reply-To: <7b3a84fb0707022126pa759a44rbe57909d7638f976@mail.gmail.com> References: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> <9e6e5c9e0707022008o516ae7fdgb6b789383afea7c9@mail.gmail.com> <7b3a84fb0707022126pa759a44rbe57909d7638f976@mail.gmail.com> Message-ID: <4689ECC3.1040201@blueflash.cc> > Even if we can't see the raw crash reports, a regularly-updated list of > top-10 crashes (with callstacks and whatever other details you can > release) for each platform would still be useful. I vote for that list as well, but as long as the viewer is leaking the way it does now, the work is pretty useless because the list will most likely be dominated by out of memory crashes. > As an aside, on the Windows platform, have you looked into the > possibility of hooking into the Microsoft Online Crash Analysis tools > (aka Watson)? I don't know what capabilities the SL crash logger has on > your end, nor do I know the current requirements for getting access to > 3rd party crash reports collected by MS. (I think it used to be that a > 3rd party app had to be logo-certified, but I don't know if that's still > the case.) Dunno what Watson does (exactly), but these crash dumps are Microsoft style. You can load them into the debugger and will see call stack, threads and registers. There are bigger dumps (which Linden doesn't produce) which even let you look at memory in a limited way. Nick From able.whitman at gmail.com Mon Jul 2 23:39:56 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 2 23:39:58 2007 Subject: [sldev] Accessing SL viewer crash reports? In-Reply-To: <4689ECC3.1040201@blueflash.cc> References: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> <9e6e5c9e0707022008o516ae7fdgb6b789383afea7c9@mail.gmail.com> <7b3a84fb0707022126pa759a44rbe57909d7638f976@mail.gmail.com> <4689ECC3.1040201@blueflash.cc> Message-ID: <7b3a84fb0707022339s36099ff4p1fe911fd599f750e@mail.gmail.com> > > > Dunno what Watson does (exactly), but these crash dumps are Microsoft > style. You can load them into the debugger and will see call stack, > threads and registers. There are bigger dumps (which Linden doesn't > produce) which even let you look at memory in a limited way. > > > Nick > In terms of actual crash dumps, Watson does basically does the same basic thing as the SL crash reporter. It has a some features on the back end that are useful though. One thing is that each Watson record is assigned a unique bucket id which is recorded in the event log. That way if your developers and testers are submitting Watson reports, they can just include the bucket id with a bug report or repro, and whoever is investigating the bug knows specifically which crash dump to look at. It also has the ability to automatically generate callstacks from the submitted dumps in conjunction with debug symbols, and it can cluster similar crashes together so you can see which types of crashes are most common, how many times a crash is hit, and how many unique users hit the crash. It also allows you to have OCA collect additional specific information for certain types of crashes (for example, if you want more than just the minidump for a particular hard-to-debug crash, OCA can gather the larger memory dump instead). And it can also instruct the user where to go to get a fix for a particular bug based on the callstack and other fingerprint information for that crash. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070703/f1a43cce/attachment.htm From nicholaz at blueflash.cc Tue Jul 3 00:01:49 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 3 00:01:57 2007 Subject: [sldev] Jira Sicknes Message-ID: <4689F45D.8040105@blueflash.cc> Just tried to do a Link: Errors * An error occurred: java.lang.ArrayIndexOutOfBoundsException: 5 Also, indexing seems to have stopped. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Tue Jul 3 06:08:24 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 06:08:01 2007 Subject: [sldev] Kudos to Jesse Linden!!!!!!!! Message-ID: <468A4A48.2050605@dzonux.net> Woot! Jesse, you are the first Linden (and resident) that I have publicly seen to recognize fellow Residents in a non-alienated fashion! I noticed on the blog you wrote: "Edited the post to say ?Resident-created? rather than ?third-party? tools. Hopefully, that will help clarify." #12 comment on: http://blog.secondlife.com/2007/07/02/got-a-great-second-life-tool-to-promote/ This is about Resident Resources: http://secondlife.com/community/resident_resource.php Thank you! For Lindens that have access to the "the machine," give Jesse lots-o-love! =) -- Power to Change the Void From chance at kalacia.com Tue Jul 3 06:46:31 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jul 3 06:46:34 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> Message-ID: <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> Mono is a programming lauguage. You compile to CIL (or MSIL if you are Bill Gates) which is handled by the .NET libraries. The source is still in Mono. On 7/2/07, Argent Stonecutter wrote: > > > lets say written in Mono instead of LSL > > Side comment: Mono is a VM. LSL is a programming language. You don't > write in mono, you compile to mono... the source may still be in LSL. > > IN fact you've got an LSL to Mono compiler on your disk right now. > _______________________________________________ > 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/20070703/6eba5611/attachment.htm From dzonatas at dzonux.net Tue Jul 3 06:54:44 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 06:54:21 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4689B9FD.2020307@gwala.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> Message-ID: <468A5524.7080307@dzonux.net> Adam Frisby wrote: > Argent Stonecutter wrote: >> IN fact you've got an LSL to Mono compiler on your disk right now. > > We do? I thought LL were keeping that internal since it's > simulator-only stuff? > Kewl! I could make a LSL to Atomatrix compiler. Mono/.NET and Sun's Java are nice, but they fall short of the more advanced object-orientated systems. Mono/.NET and Java are more of a object-oriented program language rather than an object-orientated program environment. -- Power to Change the Void From soft at lindenlab.com Tue Jul 3 07:55:47 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 3 07:55:49 2007 Subject: [sldev] Kudos to Jesse Linden!!!!!!!! In-Reply-To: <468A4A48.2050605@dzonux.net> References: <468A4A48.2050605@dzonux.net> Message-ID: <9e6e5c9e0707030755ida91027r8067e89e4e50c6b1@mail.gmail.com> On 7/3/07, Dzonatas wrote: > > Thank you! For Lindens that have access to the "the machine," give Jesse > lots-o-love! > > =) Done! From robla at lindenlab.com Tue Jul 3 08:53:18 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 3 08:53:21 2007 Subject: [sldev] Jira Sicknes In-Reply-To: <4689F45D.8040105@blueflash.cc> References: <4689F45D.8040105@blueflash.cc> Message-ID: <468A70EE.9080601@lindenlab.com> On 7/3/07 12:01 AM, Nicholaz Beresford wrote: > Just tried to do a Link: > > Errors > * An error occurred: java.lang.ArrayIndexOutOfBoundsException: 5 > > > Also, indexing seems to have stopped. We're looking into it now. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070703/e151c439/signature.pgp From chance at kalacia.com Tue Jul 3 09:38:49 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jul 3 09:38:55 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468A5524.7080307@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> Message-ID: <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> So are you suggesting we need visual studio to script our prims now? Um no thanks, ill stick with SL. On 7/3/07, Dzonatas wrote: > > Adam Frisby wrote: > > Argent Stonecutter wrote: > >> IN fact you've got an LSL to Mono compiler on your disk right now. > > > > We do? I thought LL were keeping that internal since it's > > simulator-only stuff? > > > > Kewl! I could make a LSL to Atomatrix compiler. > > Mono/.NET and Sun's Java are nice, but they fall short of the more > advanced object-orientated systems. Mono/.NET and Java are more of a > object-oriented program language rather than an object-orientated > program environment. > > -- > Power to Change the Void > _______________________________________________ > 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/20070703/4ff63914/attachment.htm From dzonatas at dzonux.net Tue Jul 3 10:01:40 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 10:01:18 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> Message-ID: <468A80F4.2050509@dzonux.net> LOL not even. It can be completely transparent, if desired, all in SL. Just like Mono enabled sims, it would be limited to those, however. One feature I've had built-in to Atomatrix from the start is the ability to compile on-the-fly (or just-in-time). A simple flag that an LSL script is compilable and validated is all that is needed to effectively handle on-the-fly compilation. It validation tracking is needed, we could add resources to track origination of the validator, like a PGP stamp. This is a very useful tool. For example, lets say I want to take a script compiled in LSL, to a sim that uses Mono and use it there. It would recompile when it arrives at that sim. Same thing for the event to take that Mono-compiled LSL script or to a sim that uses Atomatrix. When it arrives, it gets recompiled. That way each sim can easily use the best local implementation and not worry about foreign compilations. =) Chance Unknown wrote: > So are you suggesting we need visual studio to script our prims now? > Um no thanks, ill stick with SL. > > On 7/3/07, *Dzonatas* < dzonatas@dzonux.net > > wrote: > > Adam Frisby wrote: > > Argent Stonecutter wrote: > >> IN fact you've got an LSL to Mono compiler on your disk right now. > > > > We do? I thought LL were keeping that internal since it's > > simulator-only stuff? > > > > Kewl! I could make a LSL to Atomatrix compiler. > > Mono/.NET and Sun's Java are nice, but they fall short of the more > advanced object-orientated systems. Mono/.NET and Java are more of a > object-oriented program language rather than an object-orientated > program environment. > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070703/ae282f19/attachment-0001.htm From chance at kalacia.com Tue Jul 3 10:21:56 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jul 3 10:21:59 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468A80F4.2050509@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> Message-ID: <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> i thought the point was that the bytecodes stored with the scripts would be in CIL (or MSIL for gates fanboys), allowing the binary image to be transported around without the need to recompile it. wasnt that the ooooooo thing babbage linden was working on? On 7/3/07, Dzonatas wrote: > > LOL not even. It can be completely transparent, if desired, all in SL. Just > like Mono enabled sims, it would be limited to those, however. > > One feature I've had built-in to Atomatrix from the start is the ability to > compile on-the-fly (or just-in-time). A simple flag that an LSL script is > compilable and validated is all that is needed to effectively handle > on-the-fly compilation. It validation tracking is needed, we could add > resources to track origination of the validator, like a PGP stamp. > > This is a very useful tool. For example, lets say I want to take a script > compiled in LSL, to a sim that uses Mono and use it there. It would > recompile when it arrives at that sim. > > Same thing for the event to take that Mono-compiled LSL script or to a sim > that uses Atomatrix. When it arrives, it gets recompiled. > > That way each sim can easily use the best local implementation and not > worry about foreign compilations. > > =) > > > > Chance Unknown wrote: > So are you suggesting we need visual studio to script our prims now? Um no > thanks, ill stick with SL. > > > On 7/3/07, Dzonatas < dzonatas@dzonux.net> wrote: > > Adam Frisby wrote: > > > Argent Stonecutter wrote: > > >> IN fact you've got an LSL to Mono compiler on your disk right now. > > > > > > We do? I thought LL were keeping that internal since it's > > > simulator-only stuff? > > > > > > > Kewl! I could make a LSL to Atomatrix compiler. > > > > Mono/.NET and Sun's Java are nice, but they fall short of the more > > advanced object-orientated systems. Mono/.NET and Java are more of a > > object-oriented program language rather than an object-orientated > > program environment. > > > > -- > > Power to Change the Void > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > Power to Change the Void From dzonatas at dzonux.net Tue Jul 3 10:50:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 10:50:36 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> Message-ID: <468A8C83.3080309@dzonux.net> I've benchmarked fast compilations. One of the first steps to speed-up up compilations tremendously is to use a fully mapped and state written LR parser. When you use bison/yacc, you get as far as the tables being generated. Bison/yacc also has the rarely used features to map all the states and put it in a very nicely detailed output format. Those state maps can be used to design a highly efficient parser. One that can compile on-the-fly much faster than the default, the straight bison/yacc created look-up table. For one, you get the full C/C++ compiler optimization with the specially designed state maps for which the default created look-up table prevents. It appears hinted on Babbage's website that the ability to compile scripts under VS, or such, would be possible in-order to better optimize the executable. I highly doubt there real is any time savings for such import process in comparison to what a faster parser can do. Especially, when it comes time where one would like to take those same scripts and allow them to work efficiently on sims that don't speak Mono. I heard a rumor that Sun wanted to offer a Java enabled SL sim, but I haven't heard of the LSL to Java compiler. The only reason why you really want to keep these executables pre-compiled is to hide the source. In thinking in terms of a sim that might be running a business that does tons of monetary transactions in a day, I highly doubt that sim would want something like Mono or Java compiled programs on its sim because Mono and Java feature unmanaged pointers for their speed. Not only is that a disaster waiting to happen, I bet it takes more time to try to validate unmanaged pointers than it would to compile on-the-fly the right way without any unmanaged pointers. Oh wait, these are just fictional businesses, like I'm just a fictional peon. Chance Unknown wrote: > i thought the point was that the bytecodes stored with the scripts > would be in CIL (or MSIL for gates fanboys), allowing the binary image > to be transported around without the need to recompile it. > > wasnt that the ooooooo thing babbage linden was working on? > > On 7/3/07, Dzonatas wrote: >> >> LOL not even. It can be completely transparent, if desired, all in >> SL. Just >> like Mono enabled sims, it would be limited to those, however. >> >> One feature I've had built-in to Atomatrix from the start is the >> ability to >> compile on-the-fly (or just-in-time). A simple flag that an LSL >> script is >> compilable and validated is all that is needed to effectively handle >> on-the-fly compilation. It validation tracking is needed, we could add >> resources to track origination of the validator, like a PGP stamp. >> >> This is a very useful tool. For example, lets say I want to take a >> script >> compiled in LSL, to a sim that uses Mono and use it there. It would >> recompile when it arrives at that sim. >> >> Same thing for the event to take that Mono-compiled LSL script or to >> a sim >> that uses Atomatrix. When it arrives, it gets recompiled. >> >> That way each sim can easily use the best local implementation and not >> worry about foreign compilations. >> >> =) >> >> >> >> Chance Unknown wrote: >> So are you suggesting we need visual studio to script our prims now? >> Um no >> thanks, ill stick with SL. >> >> >> On 7/3/07, Dzonatas < dzonatas@dzonux.net> wrote: >> > Adam Frisby wrote: >> > > Argent Stonecutter wrote: >> > >> IN fact you've got an LSL to Mono compiler on your disk right now. >> > > >> > > We do? I thought LL were keeping that internal since it's >> > > simulator-only stuff? >> > > >> > >> > Kewl! I could make a LSL to Atomatrix compiler. >> > >> > Mono/.NET and Sun's Java are nice, but they fall short of the more >> > advanced object-orientated systems. Mono/.NET and Java are more of a >> > object-oriented program language rather than an object-orientated >> > program environment. >> > >> > -- >> > Power to Change the Void >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > >> >> >> >> -- >> Power to Change the Void > > -- Power to Change the Void From Dana.Fagerstrom at Sun.COM Tue Jul 3 11:41:39 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Tue Jul 3 11:44:39 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468A8C83.3080309@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> Message-ID: <468A9863.7090506@sun.com> > I heard a rumor that Sun wanted to offer a Java enabled SL sim, but I > haven't heard of the LSL to Java compiler. There was a project started by someone who thought a Java version of the SL viewer could be done. I don't know if that was a Sun employee but it sure was/is a pipe dream. Sun has a Java-based environment like SL the we developed for the Gaming industry using two engines: Darkstar for the server and Wonderland for the client. Both are open sourced. Of course adapting Wonderland to work with SL's grid is way beyond scope at the moment. Sun Labs has an environment called MPK20 that's used as a virtual meeting place for Sun employees. If you want the details on any of this stuff take a look at Darkstar - https://games-darkstar.dev.java.net/ Wonderland - https://lg3d-wonderland.dev.java.net/ MPK20 - http://research.sun.com/projects/mc/mpk20.html. As for what Sun is doing in SecondLife, we have a presence inside SL ramping up and I am doing the Solaris port of the x86 and SPARC SL viewers. The x86 port is complete except for sound (which is awaiting a Solaris FMOD). The SPARC port has been a nightmare due to assumed x86-isms like data alignment and the binary message data packers/unpackers. If folks ever hope to see a "lite" version of the viewer on say handheld devices I'd recommend scrapping the current data packer in favor of XML, XDR, SXDF, or Java-like universal encoders. Of course using XML for everything would require much too much overhead therefore a universal binary format like XDR would be more applicable. [Let the flames begin...] HTH, D From dzonatas at dzonux.net Tue Jul 3 11:46:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 11:46:36 2007 Subject: Bounties (or the carrot-on-a-stick story?) Re: [sldev] Opening the server source? In-Reply-To: <468A8C83.3080309@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> Message-ID: <468A99A3.8010209@dzonux.net> Just like these bounties were found, so far, to be completely fictional: http://wiki.secondlife.com/wiki/Linden_Lab_Bounties "We'd like to work with the community to come up with feature coding ideas that are worthy of large bounties (e.g. best submission for a problem receives several islands for several years). NOTE: we are not yet offering bounties. This page is here to describe how the program should work. Some suggestions This list is here to point out avenues of development that are impedance-matched for bounty development. They're relatively self-contained, and could be accomplished by a small group of hackers. * At least a 5x improvement in OpenJPEG performance as used in the Second Life Viewer to decode images * Move avatar mouths in a believable way based on voice audio chat streams being played * Cross platform TTS with tunable voices and a quality level on par with ATT Natural Voices. Must be able to tune number of simultaneous voices to control CPU load, be thread safe, and play back audio with correct stereo positioning. * Cross platform STT with accuracy on par with current speech-to-text solutions. Must consume less than 5% of the CPU and be thread safe. * Rearchitect the keyboard handling in a non-hacky way, so that it becomes possible to do key remapping (and also solve all of our other keyboard architectural foibles!). If you aren't a Linden, please don't add more features to this list, but instead file the issue in JIRA, and perhaps refer to it from the talk page. Process for making this a reality We want the community to help us build this program. To that end, we're putting this in the list of items to consider for future roundtables, and encourage discussion on the mailing list. " NOTE: It's not like LL has not shown any intention to move forward on these. All, except one, of the items listed above have been done and that one I know has had several contributors, so far. The only barrier I see that stops LL from paying these bounties is the fact that LL is not in agreement with itself on how to pay these. That fact may be hidden from other LL employees who don't know who is being contracted to do work for LL and being payed-off a little sum (while being pushed to the street). Lindens, would you *please* learn to work together on this offer you made! Dzonatas wrote: > I've benchmarked fast compilations. One of the first steps to speed-up > up compilations tremendously is to use a fully mapped and state > written LR parser. When you use bison/yacc, you get as far as the > tables being generated. Bison/yacc also has the rarely used features > to map all the states and put it in a very nicely detailed output > format. Those state maps can be used to design a highly efficient > parser. One that can compile on-the-fly much faster than the default, > the straight bison/yacc created look-up table. For one, you get the > full C/C++ compiler optimization with the specially designed state > maps for which the default created look-up table prevents. > > It appears hinted on Babbage's website that the ability to compile > scripts under VS, or such, would be possible in-order to better > optimize the executable. I highly doubt there real is any time savings > for such import process in comparison to what a faster parser can do. > Especially, when it comes time where one would like to take those same > scripts and allow them to work efficiently on sims that don't speak Mono. > > I heard a rumor that Sun wanted to offer a Java enabled SL sim, but I > haven't heard of the LSL to Java compiler. > > The only reason why you really want to keep these executables > pre-compiled is to hide the source. In thinking in terms of a sim that > might be running a business that does tons of monetary transactions in > a day, I highly doubt that sim would want something like Mono or Java > compiled programs on its sim because Mono and Java feature unmanaged > pointers for their speed. Not only is that a disaster waiting to > happen, I bet it takes more time to try to validate unmanaged pointers > than it would to compile on-the-fly the right way without any > unmanaged pointers. > > Oh wait, these are just fictional businesses, like I'm just a > fictional peon. > > Chance Unknown wrote: >> i thought the point was that the bytecodes stored with the scripts >> would be in CIL (or MSIL for gates fanboys), allowing the binary image >> to be transported around without the need to recompile it. >> >> wasnt that the ooooooo thing babbage linden was working on? >> >> On 7/3/07, Dzonatas wrote: >>> >>> LOL not even. It can be completely transparent, if desired, all in >>> SL. Just >>> like Mono enabled sims, it would be limited to those, however. >>> >>> One feature I've had built-in to Atomatrix from the start is the >>> ability to >>> compile on-the-fly (or just-in-time). A simple flag that an LSL >>> script is >>> compilable and validated is all that is needed to effectively handle >>> on-the-fly compilation. It validation tracking is needed, we could add >>> resources to track origination of the validator, like a PGP stamp. >>> >>> This is a very useful tool. For example, lets say I want to take a >>> script >>> compiled in LSL, to a sim that uses Mono and use it there. It would >>> recompile when it arrives at that sim. >>> >>> Same thing for the event to take that Mono-compiled LSL script or >>> to a sim >>> that uses Atomatrix. When it arrives, it gets recompiled. >>> >>> That way each sim can easily use the best local implementation and not >>> worry about foreign compilations. >>> >>> =) >>> >>> >>> >>> Chance Unknown wrote: >>> So are you suggesting we need visual studio to script our prims now? >>> Um no >>> thanks, ill stick with SL. >>> >>> >>> On 7/3/07, Dzonatas < dzonatas@dzonux.net> wrote: >>> > Adam Frisby wrote: >>> > > Argent Stonecutter wrote: >>> > >> IN fact you've got an LSL to Mono compiler on your disk right now. >>> > > >>> > > We do? I thought LL were keeping that internal since it's >>> > > simulator-only stuff? >>> > > >>> > >>> > Kewl! I could make a LSL to Atomatrix compiler. >>> > >>> > Mono/.NET and Sun's Java are nice, but they fall short of the more >>> > advanced object-orientated systems. Mono/.NET and Java are more of a >>> > object-oriented program language rather than an object-orientated >>> > program environment. >>> > >>> > -- >>> > Power to Change the Void >>> > _______________________________________________ >>> > Click here to unsubscribe or manage your list subscription: >>> > >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> > >>> >>> >>> >>> -- >>> Power to Change the Void >> >> > -- Power to Change the Void From robla at lindenlab.com Tue Jul 3 11:57:57 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 3 11:58:51 2007 Subject: Bounties (or the carrot-on-a-stick story?) Re: [sldev] Opening the server source? In-Reply-To: <468A99A3.8010209@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A99A3.8010209@dzonux.net> Message-ID: <468A9C35.5020208@lindenlab.com> Liana isn't here this week, but she's working out something now. I'll give you a little bit of the inside story on this. There was a lot of pressure at launch time to say something about this, even though I personally didn't feel like bounties were the right thing to do at this stage. We should have remained silent on this, since we didn't have a concrete plan for moving forward. I don't want to have this conversation this week, while Liana's out, so I'll leave it at that. Can we pick this back up next week? Rob On 7/3/07 11:46 AM, Dzonatas wrote: > Just like these bounties were found, so far, to be completely fictional: > > http://wiki.secondlife.com/wiki/Linden_Lab_Bounties > > "We'd like to work with the community to come up with feature coding > ideas that are worthy of large bounties (e.g. best submission for a > problem receives several islands for several years). > > NOTE: we are not yet offering bounties. This page is here to describe > how the program should work. > > Some suggestions > > This list is here to point out avenues of development that are > impedance-matched for bounty development. They're relatively > self-contained, and could be accomplished by a small group of hackers. > > * At least a 5x improvement in OpenJPEG performance as used in the > Second Life Viewer to decode images > * Move avatar mouths in a believable way based on voice audio chat > streams being played > * Cross platform TTS with tunable voices and a quality level on par > with ATT Natural Voices. Must be able to tune number of simultaneous > voices to control CPU load, be thread safe, and play back audio with > correct stereo positioning. > * Cross platform STT with accuracy on par with current > speech-to-text solutions. Must consume less than 5% of the CPU and be > thread safe. > * Rearchitect the keyboard handling in a non-hacky way, so that it > becomes possible to do key remapping (and also solve all of our other > keyboard architectural foibles!). > > If you aren't a Linden, please don't add more features to this list, > but instead file the issue in JIRA, and perhaps refer to it from the > talk page. > Process for making this a reality > > We want the community to help us build this program. To that end, > we're putting this in the list of items to consider for future > roundtables, and encourage discussion on the mailing list. " > > NOTE: It's not like LL has not shown any intention to move forward on > these. All, except one, of the items listed above have been done and > that one I know has had several contributors, so far. The only barrier > I see that stops LL from paying these bounties is the fact that LL is > not in agreement with itself on how to pay these. That fact may be > hidden from other LL employees who don't know who is being contracted > to do work for LL and being payed-off a little sum (while being pushed > to the street). > > Lindens, would you *please* learn to work together on this offer you > made! > > Dzonatas wrote: >> I've benchmarked fast compilations. One of the first steps to >> speed-up up compilations tremendously is to use a fully mapped and >> state written LR parser. When you use bison/yacc, you get as far as >> the tables being generated. Bison/yacc also has the rarely used >> features to map all the states and put it in a very nicely detailed >> output format. Those state maps can be used to design a highly >> efficient parser. One that can compile on-the-fly much faster than >> the default, the straight bison/yacc created look-up table. For one, >> you get the full C/C++ compiler optimization with the specially >> designed state maps for which the default created look-up table >> prevents. >> >> It appears hinted on Babbage's website that the ability to compile >> scripts under VS, or such, would be possible in-order to better >> optimize the executable. I highly doubt there real is any time >> savings for such import process in comparison to what a faster parser >> can do. Especially, when it comes time where one would like to take >> those same scripts and allow them to work efficiently on sims that >> don't speak Mono. >> >> I heard a rumor that Sun wanted to offer a Java enabled SL sim, but I >> haven't heard of the LSL to Java compiler. >> >> The only reason why you really want to keep these executables >> pre-compiled is to hide the source. In thinking in terms of a sim >> that might be running a business that does tons of monetary >> transactions in a day, I highly doubt that sim would want something >> like Mono or Java compiled programs on its sim because Mono and Java >> feature unmanaged pointers for their speed. Not only is that a >> disaster waiting to happen, I bet it takes more time to try to >> validate unmanaged pointers than it would to compile on-the-fly the >> right way without any unmanaged pointers. >> >> Oh wait, these are just fictional businesses, like I'm just a >> fictional peon. >> >> Chance Unknown wrote: >>> i thought the point was that the bytecodes stored with the scripts >>> would be in CIL (or MSIL for gates fanboys), allowing the binary image >>> to be transported around without the need to recompile it. >>> >>> wasnt that the ooooooo thing babbage linden was working on? >>> >>> On 7/3/07, Dzonatas wrote: >>>> >>>> LOL not even. It can be completely transparent, if desired, all in >>>> SL. Just >>>> like Mono enabled sims, it would be limited to those, however. >>>> >>>> One feature I've had built-in to Atomatrix from the start is the >>>> ability to >>>> compile on-the-fly (or just-in-time). A simple flag that an LSL >>>> script is >>>> compilable and validated is all that is needed to effectively handle >>>> on-the-fly compilation. It validation tracking is needed, we could >>>> add >>>> resources to track origination of the validator, like a PGP stamp. >>>> >>>> This is a very useful tool. For example, lets say I want to take a >>>> script >>>> compiled in LSL, to a sim that uses Mono and use it there. It would >>>> recompile when it arrives at that sim. >>>> >>>> Same thing for the event to take that Mono-compiled LSL script or >>>> to a sim >>>> that uses Atomatrix. When it arrives, it gets recompiled. >>>> >>>> That way each sim can easily use the best local implementation and >>>> not >>>> worry about foreign compilations. >>>> >>>> =) >>>> >>>> >>>> >>>> Chance Unknown wrote: >>>> So are you suggesting we need visual studio to script our prims >>>> now? Um no >>>> thanks, ill stick with SL. >>>> >>>> >>>> On 7/3/07, Dzonatas < dzonatas@dzonux.net> wrote: >>>> > Adam Frisby wrote: >>>> > > Argent Stonecutter wrote: >>>> > >> IN fact you've got an LSL to Mono compiler on your disk right >>>> now. >>>> > > >>>> > > We do? I thought LL were keeping that internal since it's >>>> > > simulator-only stuff? >>>> > > >>>> > >>>> > Kewl! I could make a LSL to Atomatrix compiler. >>>> > >>>> > Mono/.NET and Sun's Java are nice, but they fall short of the more >>>> > advanced object-orientated systems. Mono/.NET and Java are more of a >>>> > object-oriented program language rather than an object-orientated >>>> > program environment. >>>> > >>>> > -- >>>> > Power to Change the Void >>>> > _______________________________________________ >>>> > Click here to unsubscribe or manage your list subscription: >>>> > >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> > >>>> >>>> >>>> >>>> -- >>>> Power to Change the Void >>> >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070703/59fd46ef/signature-0001.pgp From secret.argent at gmail.com Tue Jul 3 12:10:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 3 12:10:26 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> Message-ID: On 03-Jul-2007, at 08:46, Chance Unknown wrote: > Mono is a programming lauguage. Mono is not a programming language. C# is a programming language, J# is a programming language. VB.Net is a programming language. All these programming languages compile to CIL code which is run in the Mono virtual machine. Linden Labs was not, so far as I know, planning on supporting any language but LSL even after converting to Mono. From dzonatas at dzonux.net Tue Jul 3 12:11:10 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 12:10:47 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <468A9863.7090506@sun.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> Message-ID: <468A9F4E.1030704@dzonux.net> Dana Fagerstrom wrote: > If folks ever hope to see a "lite" version of the viewer on say > handheld devices I'd recommend scrapping the current data packer in > favor of XML, XDR, SXDF, or Java-like universal encoders. Of course > using XML for everything would require much too much overhead > therefore a universal binary format like XDR would be more applicable. > [Let the flames begin...] > ... For "lite" versions, an extreme XML validator is not needed. The extreme XML validator is the default recommendation. The XML validator not only slows down the XML intake process, it also has been a tool in the likeness of a vendor lock-in. There is no need to validate most XML in the way large businesses, like Sun's biggest competitor, have recommended. I've written a clean, "what's essential", XML parser that does not depend on any external website for format definitions, like the kind you find in DOCTYPE headers, and it is fast. There is no extra overhead when it is done that way. I know it can be done. I personally know it (being derived from SL business features) is currently in demand for the reason you state, handhelds devices. Being that Atomatrix is pre-Java, I'm sure you'll understand I have my niche with object-orientated program environments and such patent issues. For these handheld devices being used in likewise desire, I might make a kind-of compromise but not really a compromise. Hmm. It appears GPLv3 hurts Java technology more than anything else unlike Microsoft/Novell. I *might* move Atomatrix to GPLv3, as that is my current path. (I'm showing opportunity to work together... not blowing steam.) =) -- Power to Change the Void From secret.argent at gmail.com Tue Jul 3 12:16:11 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 3 12:16:15 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468A80F4.2050509@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> Message-ID: <73C2E0FF-E48A-4345-9D98-3A65125ED092@gmail.com> > This is a very useful tool. For example, lets say I want to take a > script compiled in LSL, to a sim that uses Mono and use it there. > It would recompile when it arrives at that sim. So all the local variables and script state would get thrown away? And people thought sim border crossing and teleports were slow now. From secret.argent at gmail.com Tue Jul 3 12:30:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 3 12:31:00 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468A8C83.3080309@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> Message-ID: <70E20202-C37C-4C7F-9D4D-B0C6E8335BD7@gmail.com> > The only reason why you really want to keep these executables pre- > compiled is to hide the source. The executable isn't just "not recompiled", it's also "not halted and restarted". The internal state (the virtual machine equivalent of the registers, program counter, variables, and so on) has to be retained on sim border crossings. Also, I think you underestimate the amount of recompilation you would need. 1. Border crossings are *frequent*... even just using the regular vehicle scripts you can fly at 50 meters a second. That means a border crossing every five seconds flying along a compass direction, more diagonally. There are boosted vehicles that can cross a sim in a second. 2. There are *lots* of scripts involved. Some of my older scripted attachments have hundreds of scripts in them, and there are dragon avatars with thousands. How long will a border crossing take for an Isle of Wyrms greater dragon entering one of your sims? From monkowsk at watson.ibm.com Tue Jul 3 12:53:11 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jul 3 12:52:37 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46899634.5080407@gwala.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> <46858B1D.10907@watson.ibm.com> <46858EC0.7070309@gwala.net> <468981FB.1040903@watson.ibm.com> <468985D1.4010105@gwala.net> <468993D2.2070601@watson.ibm.com> <46899634.5080407@gwala.net> Message-ID: <468AA927.3010601@watson.ibm.com> I thought you were talking about scripting. If not, what are you uploading and to where? I don't understand the security problems that you see. Mike Adam Frisby wrote: > Right, but are we talking scripting here or hard compiled engines > themselves? (Little confused what's being reffered to) > > Adam > > Mike Monkowski wrote: > >> Adam Frisby wrote: >> >>> In terms of scripting / physics engines - you still need to be able >>> to upload and compile, and once you are allowing that, you open a big >>> can of worms with security, doing it without opening that would be a >>> very interesting challenge. >> >> >> >> I understand that scripts could be visible to the private sims, but >> they're just assets served up by another server. If you don't want >> your scripts sent to private sims, it would be just as easy as making >> them non-editable now. Just another flag in a database. >> >> The upload part I don't understand, though. You would upload through >> the LL transaction server, not the physics/scripting server. The >> physics/scripting server would also get the objects through the LL >> transaction server. The viewer would in turn receive objects from the >> physics/scripting server. Presumably, the server would have a local >> cache, so the viewer wouldn't see the fetch lag for objects that are >> resident to the sim. >> >> Mike From Dana.Fagerstrom at Sun.COM Tue Jul 3 13:04:43 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Tue Jul 3 13:07:48 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <468A9F4E.1030704@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> Message-ID: <468AABDB.6000003@sun.com> Cool! XML without the hairballs. Excellent! Thanks, D Dzonatas wrote: > Dana Fagerstrom wrote: >> If folks ever hope to see a "lite" version of the viewer on say >> handheld devices I'd recommend scrapping the current data packer in >> favor of XML, XDR, SXDF, or Java-like universal encoders. Of course >> using XML for everything would require much too much overhead >> therefore a universal binary format like XDR would be more applicable. >> [Let the flames begin...] >> > ... > > For "lite" versions, an extreme XML validator is not needed. The extreme > XML validator is the default recommendation. The XML validator not only > slows down the XML intake process, it also has been a tool in the > likeness of a vendor lock-in. There is no need to validate most XML in > the way large businesses, like Sun's biggest competitor, have > recommended. I've written a clean, "what's essential", XML parser that > does not depend on any external website for format definitions, like the > kind you find in DOCTYPE headers, and it is fast. There is no extra > overhead when it is done that way. I know it can be done. > > I personally know it (being derived from SL business features) is > currently in demand for the reason you state, handhelds devices. > > Being that Atomatrix is pre-Java, I'm sure you'll understand I have my > niche with object-orientated program environments and such patent > issues. For these handheld devices being used in likewise desire, I > might make a kind-of compromise but not really a compromise. Hmm. It > appears GPLv3 hurts Java technology more than anything else unlike > Microsoft/Novell. I *might* move Atomatrix to GPLv3, as that is my > current path. (I'm showing opportunity to work together... not blowing > steam.) > > =) > -- ===================================================================== Dana Fagerstrom Phone: 877.851.6343 Sun Services Fax: 877.851.6343 400 Atrium Dr. Email: dana.fagerstrom@Sun.COM Somerset, NJ 08873 SneakerNet: USMT01 ===================================================================== Pressure - It can turn a lump of coal into a flawless diamond, and an average person into a perfect basketcase. -- www.despair.com ===================================================================== From seg at haxxed.com Tue Jul 3 13:41:41 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jul 3 13:41:38 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468A9863.7090506@sun.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> Message-ID: <1183495302.23514.3.camel@localhost> On Tue, 2007-07-03 at 14:41 -0400, Dana Fagerstrom wrote: > As for what Sun is doing in SecondLife, we have a presence inside SL > ramping up and I am doing the Solaris port of the x86 and SPARC SL > viewers. The x86 port is complete except for sound (which is awaiting a > Solaris FMOD). Have you tried my OpenAL patch? Testing on non-Linux platforms would be useful, as my long term goal is to dump fmod on all platforms. http://www.haxxed.com/code/slviewer-1.17.1.0-openal-20070703.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070703/b7940ac9/attachment.pgp From robla at lindenlab.com Tue Jul 3 13:56:37 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 3 13:56:45 2007 Subject: [sldev] Jira Sicknes In-Reply-To: <468A70EE.9080601@lindenlab.com> References: <4689F45D.8040105@blueflash.cc> <468A70EE.9080601@lindenlab.com> Message-ID: <468AB805.6070101@lindenlab.com> Sorry, forgot to send out the all clear. Things should have been better from about 10am PDT onward. Let me know if things are still flaky for you. Thanks Rob On 7/3/07 8:53 AM, Rob Lanphier wrote: > On 7/3/07 12:01 AM, Nicholaz Beresford wrote: > >> Just tried to do a Link: >> >> Errors >> * An error occurred: java.lang.ArrayIndexOutOfBoundsException: 5 >> >> >> Also, indexing seems to have stopped. >> > > We're looking into it now. > > Rob > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070703/53470919/signature-0001.pgp From dzonatas at dzonux.net Tue Jul 3 16:10:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 3 16:10:12 2007 Subject: [sldev] Tournaments In-Reply-To: <70E20202-C37C-4C7F-9D4D-B0C6E8335BD7@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <70E20202-C37C-4C7F-9D4D-B0C6E8335BD7@gmail.com> Message-ID: <468AD76D.3010603@dzonux.net> Argent Stonecutter wrote: > Some of my older scripted attachments have hundreds of scripts in > them, and there are dragon avatars with thousands. How long will a > border crossing take for an Isle of Wyrms greater dragon entering one > of your sims? ... Heh... Bring it on... that is when I formally have my one of my own sims to host CoreWar games. I'll be happy to assimilate your Wyrms and teleport them back to their creator. =) ..but for the next week, lets keep it friendly. =) -- Power to Change the Void From adam at gwala.net Tue Jul 3 17:39:26 2007 From: adam at gwala.net (Adam Frisby) Date: Tue Jul 3 17:39:37 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> Message-ID: <468AEC3E.3000208@gwala.net> There's been whispers of it occasionally. Technically it shouldnt be hard to do, the key is in making sure you dont support language features linking to the system class library (since that makes for a nice security risk). Adam Argent Stonecutter wrote: > On 03-Jul-2007, at 08:46, Chance Unknown wrote: > >> Mono is a programming lauguage. > > > Mono is not a programming language. C# is a programming language, J# is > a programming language. VB.Net is a programming language. All these > programming languages compile to CIL code which is run in the Mono > virtual machine. > > Linden Labs was not, so far as I know, planning on supporting any > language but LSL even after converting to Mono. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kfa at gmx.net Wed Jul 4 03:13:30 2007 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Jul 4 03:13:26 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer Message-ID: <468B72CA.5030403@gmx.net> Dear @, Not sure if it's appropriate to turn to the list for attention grabbing, but I've been posting this issue for a while now and there doesn't seem to be anybody picking it up: https://jira.secondlife.com/browse/VWR-1183 Please somebody let me know if the information provided is insufficient or the description unclear. Thanks! Felix From morris1 at ix.netcom.com Wed Jul 4 08:41:50 2007 From: morris1 at ix.netcom.com (morris) Date: Wed Jul 4 09:08:12 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer In-Reply-To: <468B72CA.5030403@gmx.net> References: <468B72CA.5030403@gmx.net> Message-ID: <200707040841.50712.morris1@ix.netcom.com> I had the same problem and reported it as a bug with Win2K since I have other systems running XP and Vista and they worked ok. I tested this also with another Win2K system and it failed. I have since upgraded the original Win2K machine to Vista and the microphone works ok with no other changes. Morris Ford On Wednesday 04 July 2007 03:13, Felix Duesenburg wrote: > Dear @, > > Not sure if it's appropriate to turn to the list for attention grabbing, > but I've been posting this issue for a while now and there doesn't seem > to be anybody picking it up: > > https://jira.secondlife.com/browse/VWR-1183 > > Please somebody let me know if the information provided is insufficient > or the description unclear. > > Thanks! > > Felix > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From chance at kalacia.com Wed Jul 4 11:43:07 2007 From: chance at kalacia.com (Chance Unknown) Date: Wed Jul 4 11:43:10 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer In-Reply-To: <200707040841.50712.morris1@ix.netcom.com> References: <468B72CA.5030403@gmx.net> <200707040841.50712.morris1@ix.netcom.com> Message-ID: <2925011a0707041143q33188c99x996d4af589076dce@mail.gmail.com> Unable to adequately check; crashing issues on a number of machines. Stability bites. On 7/4/07, morris wrote: > > I had the same problem and reported it as a bug with Win2K since I have > other > systems running XP and Vista and they worked ok. I tested this also with > another Win2K system and it failed. I have since upgraded the original > Win2K > machine to Vista and the microphone works ok with no other changes. > Morris Ford > > On Wednesday 04 July 2007 03:13, Felix Duesenburg wrote: > > Dear @, > > > > Not sure if it's appropriate to turn to the list for attention grabbing, > > but I've been posting this issue for a while now and there doesn't seem > > to be anybody picking it up: > > > > https://jira.secondlife.com/browse/VWR-1183 > > > > Please somebody let me know if the information provided is insufficient > > or the description unclear. > > > > Thanks! > > > > Felix > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > 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/20070704/0e3bfedc/attachment.htm From nicholaz at blueflash.cc Wed Jul 4 12:07:46 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 4 12:07:58 2007 Subject: [sldev] JIRA down again? Message-ID: <468BF002.8000606@blueflash.cc> I was just getting a Errors * An error occurred: org.apache.commons.lang.exception.NestableRuntimeException: com.atlassian.jira.issue.index.IndexException: com.atlassian.bonnie.LuceneException: java.io.IOException: Lock obtain timed out: Lock@/usr/local/jira/temp/lucene-d648072af0ef8ad175c65308c892469a-write.lock when trying to link an issue. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From agrimes at speakeasy.net Wed Jul 4 19:24:07 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Wed Jul 4 18:24:00 2007 Subject: [sldev] An experiment in paleocomputing Message-ID: <468C5647.5050209@speakeasy.net> I fired up my 150 mhz Pentium MMX; 64mb ram a few minutes ago. I ran quake, and was treated to a very responsive 20 fps... (more or less), at 640x480. This machine from the mid '90s was playing Quake 1 with nothing but a linear framebuffer for graphics and beating the living $#!7 out of my dual athlon 1.2ghz/linux on Second life... Granted linux extracts a fairly hefty performance penalty for 3D apps but the degree of slowdown I've been seeing is outrageous. The bus on this machine is 5x faster than the Pentium 150, it has a video card that's faster than the sum total of every transistor in the elder machine, What gives? -- Opera: Sing it loud! :o( )>-< From dzonatas at dzonux.net Wed Jul 4 18:33:08 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 4 18:32:40 2007 Subject: [sldev] An experiment in paleocomputing In-Reply-To: <468C5647.5050209@speakeasy.net> References: <468C5647.5050209@speakeasy.net> Message-ID: <468C4A54.7080906@dzonux.net> The original quake used prebaked tiles and shadows.. nothing was dynamic. It was one step up from wolfenstein, which didn't use any shadow. The topology of objects is limited, also. If you notice, you really can't see multifloors in any room. You can go around corners and it appears like multifloors, but you'll never actually see multifloors in one screen. That is how it gain it speed. There was always a single "top" and a single "bottom" draw path for every vertical render line. Quake 2 introduced dynamic shadows and effects lighting. Quake 3 introduced the multifloors and dynamic scenes with real-time lighting, if enabled. The rest is history. Even still, Quake series still use prebaked lighting and a know set of objects to work with. SL constantly loads and unloads objects into the render buffer. The scene is no where near as static as found in Quake. Alan Grimes wrote: > I fired up my 150 mhz Pentium MMX; 64mb ram a few minutes ago. > > I ran quake, and was treated to a very responsive 20 fps... (more or > less), at 640x480. > > This machine from the mid '90s was playing Quake 1 with nothing but a > linear framebuffer for graphics and beating the living $#!7 out of my > dual athlon 1.2ghz/linux on Second life... Granted linux extracts a > fairly hefty performance penalty for 3D apps but the degree of slowdown > I've been seeing is outrageous. The bus on this machine is 5x faster > than the Pentium 150, it has a video card that's faster than the sum > total of every transistor in the elder machine, > > What gives? > > -- Power to Change the Void From labrat.hb at gmail.com Wed Jul 4 18:59:29 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Jul 4 18:59:31 2007 Subject: [sldev] An experiment in paleocomputing In-Reply-To: <468C5647.5050209@speakeasy.net> References: <468C5647.5050209@speakeasy.net> Message-ID: Let's see. Quake Minimum System Requirements: Intel Pentium(R) 75 MHz processor or better Memory: DOS -- 8 MB RAM required (16 MB recommended) Win 95 -- 16 MB RAM required (24 recommended) -------------------------------------- You were running the game on a system that was twice the speed, and had 4 to 8 times the amount of memory the game called for.... If you had used GLQuake you probably would have gotten even higher framerates. ------------------------------------- But as Dzonatas said, the Quake Engine has no relation to the SecondLife engine in any way. You're talking about an engine that was designed for fast interior rendering. The maps were pre-culled to eliminate polys that would never be rendered, lighting was pre-generated and the maps them selves were broken apart into sub-sections to keep only a small number of polys in view. The closest engine to what SL has would have been Tribes (Torque), and even then they had two seperate rendering engines, a Quake like system for interiors and a seperate renderer for exterior scenes. Even then these engines relied on the fact that everything they will display was on your HD and had been pre-optimized for 3d Rendering. On 7/4/07, Alan Grimes wrote: > > I fired up my 150 mhz Pentium MMX; 64mb ram a few minutes ago. > > I ran quake, and was treated to a very responsive 20 fps... (more or > less), at 640x480. > > This machine from the mid '90s was playing Quake 1 with nothing but a > linear framebuffer for graphics and beating the living $#!7 out of my > dual athlon 1.2ghz/linux on Second life... Granted linux extracts a > fairly hefty performance penalty for 3D apps but the degree of slowdown > I've been seeing is outrageous. The bus on this machine is 5x faster > than the Pentium 150, it has a video card that's faster than the sum > total of every transistor in the elder machine, > > What gives? > > -- > Opera: Sing it loud! :o( )>-< > _______________________________________________ > 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/20070704/fefc6b83/attachment.htm From dzonatas at dzonux.net Wed Jul 4 19:14:22 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 4 19:13:54 2007 Subject: A Good Deal -- XML/Handheld Devices Re: [sldev] Opening the server source? In-Reply-To: <468AABDB.6000003@sun.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> <468AABDB.6000003@sun.com> Message-ID: <468C53FE.80709@dzonux.net> =) Related news: "Carlos Slim Hel?" http://en.wikipedia.org/wiki/Carlos_Slim_Hel%C3%BA "World's richest? Gates may have cashed it in" "Second place would suit Microsoft chairman fine" http://seattlepi.nwsource.com/business/322239_richest04.html?source=mypi Dana Fagerstrom wrote: > Cool! XML without the hairballs. Excellent! > > Thanks, > D > > Dzonatas wrote: >> Dana Fagerstrom wrote: >>> If folks ever hope to see a "lite" version of the viewer on say >>> handheld devices I'd recommend scrapping the current data packer in >>> favor of XML, XDR, SXDF, or Java-like universal encoders. Of course >>> using XML for everything would require much too much overhead >>> therefore a universal binary format like XDR would be more >>> applicable. [Let the flames begin...] >>> >> ... >> >> For "lite" versions, an extreme XML validator is not needed. The >> extreme XML validator is the default recommendation. The XML >> validator not only slows down the XML intake process, it also has >> been a tool in the likeness of a vendor lock-in. There is no need to >> validate most XML in the way large businesses, like Sun's biggest >> competitor, have recommended. I've written a clean, "what's >> essential", XML parser that does not depend on any external website >> for format definitions, like the kind you find in DOCTYPE headers, >> and it is fast. There is no extra overhead when it is done that way. >> I know it can be done. >> >> I personally know it (being derived from SL business features) is >> currently in demand for the reason you state, handhelds devices. >> >> Being that Atomatrix is pre-Java, I'm sure you'll understand I have >> my niche with object-orientated program environments and such patent >> issues. For these handheld devices being used in likewise desire, I >> might make a kind-of compromise but not really a compromise. Hmm. It >> appears GPLv3 hurts Java technology more than anything else unlike >> Microsoft/Novell. I *might* move Atomatrix to GPLv3, as that is my >> current path. (I'm showing opportunity to work together... not >> blowing steam.) >> >> =) >> > -- Power to Change the Void From odysseus654 at gmail.com Wed Jul 4 20:49:28 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Jul 4 20:49:30 2007 Subject: [sldev] An experiment in paleocomputing In-Reply-To: References: <468C5647.5050209@speakeasy.net> Message-ID: <1674f6c70707042049l17ef6bcfr53d1355c74041429@mail.gmail.com> Just another input, after compiling the map (which takes a little bit), one of the steps done before releasing a Quake level is something called "VIS" that takes a few hours to run and basically compiles a list of what polygons are visible from what locations on the map. Something like this occlusion culling except precalculated everywhere. The same thing happens with "LIGHT", which precalculates how bright the light is on each polygon. On 7/4/07, Harold Brown wrote: > > Let's see. > > Quake Minimum System Requirements: > > Intel Pentium(R) 75 MHz processor or better > Memory: DOS -- 8 MB RAM required (16 MB recommended) > Win 95 -- 16 MB RAM required (24 recommended) > -------------------------------------- > > You were running the game on a system that was twice the speed, and had 4 > to 8 times the amount of memory the game called for.... If you had used > GLQuake you probably would have gotten even higher framerates. > > ------------------------------------- > > But as Dzonatas said, the Quake Engine has no relation to the SecondLife > engine in any way. > > You're talking about an engine that was designed for fast interior > rendering. The maps were pre-culled to eliminate polys that would never be > rendered, lighting was pre-generated and the maps them selves were broken > apart into sub-sections to keep only a small number of polys in view. > > The closest engine to what SL has would have been Tribes (Torque), and > even then they had two seperate rendering engines, a Quake like system for > interiors and a seperate renderer for exterior scenes. > > Even then these engines relied on the fact that everything they will > display was on your HD and had been pre-optimized for 3d Rendering. > > On 7/4/07, Alan Grimes wrote: > > > > I fired up my 150 mhz Pentium MMX; 64mb ram a few minutes ago. > > > > I ran quake, and was treated to a very responsive 20 fps... (more or > > less), at 640x480. > > > > This machine from the mid '90s was playing Quake 1 with nothing but a > > linear framebuffer for graphics and beating the living $#!7 out of my > > dual athlon 1.2ghz/linux on Second life... Granted linux extracts a > > fairly hefty performance penalty for 3D apps but the degree of slowdown > > I've been seeing is outrageous. The bus on this machine is 5x faster > > than the Pentium 150, it has a video card that's faster than the sum > > total of every transistor in the elder machine, > > > > What gives? > > > > -- > > Opera: Sing it loud! :o( )>-< > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > 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/20070704/09f8ade4/attachment-0001.htm From gigstaggart at gmail.com Wed Jul 4 20:58:45 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 4 20:59:01 2007 Subject: A Good Deal -- XML/Handheld Devices Re: [sldev] Opening the server source? In-Reply-To: <468C53FE.80709@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> <468AABDB.6000003@sun.com> <468C53FE.80709@dzonux.net> Message-ID: <468C6C75.9010503@gmail.com> Dzonatas wrote: > =) > > Related news: > "Carlos Slim Hel?" > http://en.wikipedia.org/wiki/Carlos_Slim_Hel%C3%BA > > "World's richest? Gates may have cashed it in" > "Second place would suit Microsoft chairman fine" > http://seattlepi.nwsource.com/business/322239_richest04.html?source=mypi > > Uh, what? Do you have a "do not call" list by any chance? Can we be added? -Jason From dzonatas at dzonux.net Thu Jul 5 00:14:01 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 5 00:13:34 2007 Subject: [sldev] DNC Gigs In-Reply-To: <468C6C75.9010503@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> <468AABDB.6000003@sun.com> <468C53FE.80709@dzonux.net> <468C6C75.9010503@gmail.com> Message-ID: <468C9A39.4060403@dzonux.net> Jason Giglio wrote: > Uh, what? Do you have a "do not call" list by any chance? Can we be > added? I'll be sure to speak with a concierge about your request, but you probably already know to create a PJIRA issue for it. While I'm in the process of this request, should I also link that issue to this: https://jira.secondlife.com/browse/MISC-197 And, this: https://jira.secondlife.com/browse/SVC-205 And, while I'm at it, I'll make sure the transcripts of the last few Bug Triages, that you attended, are publicly posted, like the rest of them when you weren't there. Your statement above kinda set out a rather rude carping, which hasn't been the first time you have much such notions at me. To follow in the footsteps of Slim, your carping inspired me to go ahead and create a sting: https://jira.secondlife.com/browse/MISC-376 Enjoy. :-( -- Power to Change the Void From labrat.hb at gmail.com Thu Jul 5 00:36:49 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jul 5 00:36:51 2007 Subject: [sldev] DNC Gigs In-Reply-To: <468C9A39.4060403@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> <468AABDB.6000003@sun.com> <468C53FE.80709@dzonux.net> <468C6C75.9010503@gmail.com> <468C9A39.4060403@dzonux.net> Message-ID: I closed MISC-376 as misfiled. The Brown Act is a california statute in regards to city legislature in california. It has nothing to do with companies that run in california. And yes I agreed with Gigs in a "WTF?" regarding your post with the links about Carlos Slim vs Bill Gates networth. On 7/5/07, Dzonatas wrote: > > Jason Giglio wrote: > > Uh, what? Do you have a "do not call" list by any chance? Can we be > > added? > > I'll be sure to speak with a concierge about your request, but you > probably already know to create a PJIRA issue for it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070705/375f78f0/attachment.htm From nicholaz at blueflash.cc Thu Jul 5 00:57:45 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 5 00:57:53 2007 Subject: [sldev] crashes in glDrawRangeElements Message-ID: <468CA479.8080003@blueflash.cc> Before (as with the crash in llrenderpoll) I spend time on crashes someone else already researched, does anyone know something about the crashes in glDrawRangeElements in lldrawpool.cpp / lldrawpoolalpha.cpp? It looks like we've got something really nasty going on there ... Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Thu Jul 5 02:26:02 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 5 02:25:35 2007 Subject: [sldev] DNC Gigs In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> <468AABDB.6000003@sun.com> <468C53FE.80709@dzonux.net> <468C6C75.9010503@gmail.com> <468C9A39.4060403@dzonux.net> Message-ID: <468CB92A.2080907@dzonux.net> Harold Brown wrote: > I closed MISC-376 as misfiled. The Brown Act is a california statute > in regards to city legislature in california. It has nothing to do > with companies that run in california. ... If LL would un-incorporate its business status, it may then be a "private" or "fictitious" company and may find it a waste of time to effectuate the Brown Act. Since Linden Labs is Incorporated, there is the portion of the business known as "local governance" or "public agency" that California grants to Incorporations and educational institutions. The Brown Act does not harm the entity of Linden Labs in any way. It's has been reopened. If there is something that is not clear about the issue, please do send me a e-mail off list we can work it over in detail. Also, it is suggested to use the created jira issue for further discussion. Hope you had a Happy 4th. -- Power to Change the Void From matthew.dowd at hotmail.co.uk Thu Jul 5 02:30:08 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 5 02:30:09 2007 Subject: [sldev] JIRA down again? Message-ID: OK - I'm getting Exception org.apache.jasper.JasperException: Issue with id 'null' or key 'null' could not be found in the system when I try to upload attachments! Matthew ---------------------------------------- > Date: Wed, 4 Jul 2007 21:07:46 +0200 > From: nicholaz@blueflash.cc > To: sldev@lists.secondlife.com > Subject: [sldev] JIRA down again? > > > I was just getting a > > > Errors > > * An error occurred: org.apache.commons.lang.exception.NestableRuntimeException: com.atlassian.jira.issue.index.IndexException: com.atlassian.bonnie.LuceneException: java.io.IOException: Lock obtain timed out: Lock@/usr/local/jira/temp/lucene-d648072af0ef8ad175c65308c892469a-write.lock > > when trying to link an issue. > > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From seg at haxxed.com Thu Jul 5 02:38:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 5 02:38:21 2007 Subject: [sldev] An experiment in paleocomputing In-Reply-To: <468C4A54.7080906@dzonux.net> References: <468C5647.5050209@speakeasy.net> <468C4A54.7080906@dzonux.net> Message-ID: <1183628316.10840.12.camel@localhost> On Wed, 2007-07-04 at 18:33 -0700, Dzonatas wrote: > Even still, Quake series still use prebaked lighting and a know set of > objects to work with. Also, the total polycount in an entire Quake level is probably less than a handful of SL prims. Quake only had to fill out a 320x200 screen. There's actually a very good series of articles out there about the development of the Quake 1 engine... http://www.gamedev.net/reference/list.asp?categoryid=40#221 Really, SL is quite fast, except for avatars. Avatars are the killer. There was a thread a while back about optimizing the avatar transform, is there anyone within LL still working on that? It looks like to really gain speed from vectorized matrix multiplies, you have to unroll your loops and pipeline an entire array of vertexes at a time. To pull that off in SL it looks like some major class restructuring needs to be done... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070705/d850abca/attachment.pgp From adam at gwala.net Thu Jul 5 02:54:22 2007 From: adam at gwala.net (Adam Frisby) Date: Thu Jul 5 02:54:38 2007 Subject: [sldev] An experiment in paleocomputing In-Reply-To: <1183628316.10840.12.camel@localhost> References: <468C5647.5050209@speakeasy.net> <468C4A54.7080906@dzonux.net> <1183628316.10840.12.camel@localhost> Message-ID: <468CBFCE.5020802@gwala.net> I think there's a good deal of room for improvement in the SL renderer if it was rewritten again today - among other things geometry shaders would be a real blessing (hell even doing the transforms in a vertex shader today may be worth considering). I'm actually contemplating somewhat, idea of benchmarking a few of these ideas in a quick & dirty libsl based viewer. I'll post back the results if I get around to building it. Adam Callum Lerwick wrote: > On Wed, 2007-07-04 at 18:33 -0700, Dzonatas wrote: > >>Even still, Quake series still use prebaked lighting and a know set of >>objects to work with. > > > Also, the total polycount in an entire Quake level is probably less than > a handful of SL prims. Quake only had to fill out a 320x200 screen. > There's actually a very good series of articles out there about the > development of the Quake 1 engine... > > http://www.gamedev.net/reference/list.asp?categoryid=40#221 > > Really, SL is quite fast, except for avatars. Avatars are the killer. > There was a thread a while back about optimizing the avatar transform, > is there anyone within LL still working on that? It looks like to really > gain speed from vectorized matrix multiplies, you have to unroll your > loops and pipeline an entire array of vertexes at a time. To pull that > off in SL it looks like some major class restructuring needs to be > done... > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From matthew.dowd at hotmail.co.uk Thu Jul 5 02:59:36 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 5 02:59:37 2007 Subject: [sldev] JIRA down again? Message-ID: And I'm also getting the error Nicholaz is getting when linking! Matthew ---------------------------------------- > From: matthew.dowd@hotmail.co.uk > To: nicholaz@blueflash.cc; sldev@lists.secondlife.com > Subject: RE: [sldev] JIRA down again? > Date: Thu, 5 Jul 2007 09:30:08 +0000 > > > OK - I'm getting > > Exception org.apache.jasper.JasperException: Issue with id 'null' or key 'null' could not be found in the system > > when I try to upload attachments! > > Matthew > > > > > ---------------------------------------- > > Date: Wed, 4 Jul 2007 21:07:46 +0200 > > From: nicholaz@blueflash.cc > > To: sldev@lists.secondlife.com > > Subject: [sldev] JIRA down again? > > > > > > I was just getting a > > > > > > Errors > > > > * An error occurred: org.apache.commons.lang.exception.NestableRuntimeException: com.atlassian.jira.issue.index.IndexException: com.atlassian.bonnie.LuceneException: java.io.IOException: Lock obtain timed out: Lock@/usr/local/jira/temp/lucene-d648072af0ef8ad175c65308c892469a-write.lock > > > > when trying to link an issue. > > > > > > Nick > > > > -- > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > http://www.live.com/?mkt=en-gb _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From nicholaz at blueflash.cc Thu Jul 5 03:58:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 5 03:59:04 2007 Subject: [sldev] JIRA down again? In-Reply-To: References: Message-ID: <468CCEED.9070105@blueflash.cc> Matthew Dowd wrote: > OK - I'm getting > > Exception org.apache.jasper.JasperException: Issue with id 'null' or key 'null' could not be found in the system > > when I try to upload attachments! *sigh* Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From matthew.dowd at hotmail.co.uk Thu Jul 5 05:17:53 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 5 05:17:54 2007 Subject: [sldev] JIRA down again? Message-ID: It looks like the links (but not the attachments) do get created despite the error! Matthew ---------------------------------------- > Date: Thu, 5 Jul 2007 12:58:53 +0200 > From: nicholaz@blueflash.cc > To: matthew.dowd@hotmail.co.uk > CC: sldev@lists.secondlife.com > Subject: Re: [sldev] JIRA down again? > > > Matthew Dowd wrote: > > OK - I'm getting > > > > Exception org.apache.jasper.JasperException: Issue with id 'null' or key 'null' could not be found in the system > > > > when I try to upload attachments! > > *sigh* > > > Nick > --- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From labrat.hb at gmail.com Thu Jul 5 07:21:05 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jul 5 07:21:07 2007 Subject: [sldev] DNC Gigs In-Reply-To: <468CB92A.2080907@dzonux.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <468A8C83.3080309@dzonux.net> <468A9863.7090506@sun.com> <468A9F4E.1030704@dzonux.net> <468AABDB.6000003@sun.com> <468C53FE.80709@dzonux.net> <468C6C75.9010503@gmail.com> <468C9A39.4060403@dzonux.net> <468CB92A.2080907@dzonux.net> Message-ID: Again.. the Brown Act ONLY applies to City Legislature in California. It has nothing to do with businesses incorporated or not. As Linden Labs is NOT a city in California, there is nothing in regards to the Brown Act that they are legally required to follow. The Bagley-Keane Act you brought up next in the JIRA ONLY applies to STATE Legistature in California. Again nothing to do with a business, incorporated or not. On 7/5/07, Dzonatas wrote: > > Harold Brown wrote: > > I closed MISC-376 as misfiled. The Brown Act is a california statute > > in regards to city legislature in california. It has nothing to do > > with companies that run in california. > ... > If LL would un-incorporate its business status, it may then be a > "private" or "fictitious" company and may find it a waste of time to > effectuate the Brown Act. Since Linden Labs is Incorporated, there is > the portion of the business known as "local governance" or "public > agency" that California grants to Incorporations and educational > institutions. The Brown Act does not harm the entity of Linden Labs in > any way. It's has been reopened. > > If there is something that is not clear about the issue, please do send > me a e-mail off list we can work it over in detail. Also, it is > suggested to use the created jira issue for further discussion. > > Hope you had a Happy 4th. > > -- > Power to Change the Void > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070705/58a8a421/attachment.htm From nicholaz at blueflash.cc Thu Jul 5 08:59:48 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 5 08:59:59 2007 Subject: [sldev] Compare functions (llspatialpartition.h) Message-ID: <468D1574.70502@blueflash.cc> There are two compare functions in llspatialpartition.h which I believe are wrong. When doing pointer compares, if NULL pointers are involved I think the result should be consistent (i.e. a NULL either being always considered more or less than a pointer value). With these implementations however, NULL is considered greater if it appears as lhs, but if it appears as rhs the function returns also TRUE, which implicitely means that NULL is lesser (as far as I understand it, these compare functions for std::sort are bound to return if left is greater than right. Also in case both are NULL, I think false should be returned (neither is greater). Shouldn't that be (assuming that NULL should be greater, to be sorted to the end of the list): return lhs != rhs && (lhs == NULL || (rhs != NULL && lhs->mTexture > rhs->mTexture)); Or am I missing something? Original snippet: struct CompareTexturePtr { bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) { return lhs == NULL || rhs == NULL || lhs->mTexture > rhs->mTexture; } }; struct CompareBump { bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) { return lhs == NULL || rhs == NULL || lhs->mBump > rhs->mBump; } }; -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From matthew.dowd at hotmail.co.uk Thu Jul 5 09:29:55 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 5 09:29:57 2007 Subject: [sldev] Compare functions (llspatialpartition.h) Message-ID: I think you are correct. However, where are these functions called? Whilst the current behaviour may not be correct, is there any code relying on the current (faulty) behaviour which would need fixing too? Matthew ---------------------------------------- > Date: Thu, 5 Jul 2007 17:59:48 +0200 > From: nicholaz@blueflash.cc > To: sldev@lists.secondlife.com > Subject: [sldev] Compare functions (llspatialpartition.h) > > > There are two compare functions in llspatialpartition.h which I believe > are wrong. > > When doing pointer compares, if NULL pointers are involved I think the > result should be consistent (i.e. a NULL either being always considered > more or less than a pointer value). With these implementations however, > NULL is considered greater if it appears as lhs, but if it appears as > rhs the function returns also TRUE, which implicitely means that NULL > is lesser (as far as I understand it, these compare functions for std::sort > are bound to return if left is greater than right. Also in case both are > NULL, I think false should be returned (neither is greater). > > Shouldn't that be (assuming that NULL should be greater, to be sorted to > the end of the list): > > return lhs != rhs && (lhs == NULL || (rhs != NULL && lhs->mTexture > rhs->mTexture)); > > Or am I missing something? > > > > Original snippet: > > struct CompareTexturePtr > { > bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) > { > > return lhs == NULL || rhs == NULL || lhs->mTexture > rhs->mTexture; > } > }; > > struct CompareBump > { > bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) > { > return lhs == NULL || rhs == NULL || lhs->mBump > rhs->mBump; > } > }; > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From nicholaz at blueflash.cc Thu Jul 5 10:15:01 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 5 10:15:22 2007 Subject: [sldev] Compare functions (llspatialpartition.h) In-Reply-To: References: Message-ID: <468D2715.8000304@blueflash.cc> They are called for sorts on DrawInfo structure (if you grep CompareTexturePtr or CompareBump you'll just see one reference for a std::sort). In fact I have no idea why someone would sort an array of objects by address ... except maybe hoping to optimize for cpu cache prefetch or something. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matthew Dowd wrote: > I think you are correct. > > However, where are these functions called? Whilst the current behaviour may not be correct, is there any code relying on the current (faulty) behaviour which would need fixing too? > > Matthew > > > > > ---------------------------------------- >> Date: Thu, 5 Jul 2007 17:59:48 +0200 >> From: nicholaz@blueflash.cc >> To: sldev@lists.secondlife.com >> Subject: [sldev] Compare functions (llspatialpartition.h) >> >> >> There are two compare functions in llspatialpartition.h which I believe >> are wrong. >> >> When doing pointer compares, if NULL pointers are involved I think the >> result should be consistent (i.e. a NULL either being always considered >> more or less than a pointer value). With these implementations however, >> NULL is considered greater if it appears as lhs, but if it appears as >> rhs the function returns also TRUE, which implicitely means that NULL >> is lesser (as far as I understand it, these compare functions for std::sort >> are bound to return if left is greater than right. Also in case both are >> NULL, I think false should be returned (neither is greater). >> >> Shouldn't that be (assuming that NULL should be greater, to be sorted to >> the end of the list): >> >> return lhs != rhs && (lhs == NULL || (rhs != NULL && lhs->mTexture > rhs->mTexture)); >> >> Or am I missing something? >> >> >> >> Original snippet: >> >> struct CompareTexturePtr >> { >> bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) >> { >> >> return lhs == NULL || rhs == NULL || lhs->mTexture > rhs->mTexture; >> } >> }; >> >> struct CompareBump >> { >> bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) >> { >> return lhs == NULL || rhs == NULL || lhs->mBump > rhs->mBump; >> } >> }; >> >> -- >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > 100?s of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html From chance at kalacia.com Thu Jul 5 10:28:15 2007 From: chance at kalacia.com (Chance Unknown) Date: Thu Jul 5 10:28:17 2007 Subject: [sldev] Compare functions (llspatialpartition.h) In-Reply-To: <468D1574.70502@blueflash.cc> References: <468D1574.70502@blueflash.cc> Message-ID: <2925011a0707051028s3a5b3477m804067ae3eeb72ae@mail.gmail.com> when in doubt: make it more than one statement. the compiler wont care. On 7/5/07, Nicholaz Beresford wrote: > > > There are two compare functions in llspatialpartition.h which I believe > are wrong. > > When doing pointer compares, if NULL pointers are involved I think the > result should be consistent (i.e. a NULL either being always considered > more or less than a pointer value). With these implementations however, > NULL is considered greater if it appears as lhs, but if it appears as > rhs the function returns also TRUE, which implicitely means that NULL > is lesser (as far as I understand it, these compare functions for > std::sort > are bound to return if left is greater than right. Also in case both are > NULL, I think false should be returned (neither is greater). > > Shouldn't that be (assuming that NULL should be greater, to be sorted to > the end of the list): > > return lhs != rhs && (lhs == NULL || (rhs != NULL && lhs->mTexture > > rhs->mTexture)); > > Or am I missing something? > > > > Original snippet: > > struct CompareTexturePtr > { > bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& > rhs) > { > > return lhs == NULL || rhs == NULL || lhs->mTexture > > rhs->mTexture; > } > }; > > struct CompareBump > { > bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& > rhs) > { > return lhs == NULL || rhs == NULL || lhs->mBump > rhs->mBump; > } > }; > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > 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/20070705/b84e9a90/attachment.htm From tateru.nino at gmail.com Thu Jul 5 10:39:02 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jul 5 10:39:10 2007 Subject: [sldev] Compare functions (llspatialpartition.h) In-Reply-To: <468D2715.8000304@blueflash.cc> References: <468D2715.8000304@blueflash.cc> Message-ID: <468D2CB6.9090700@gmail.com> Nicholaz Beresford wrote: > > In fact I have no idea why someone would sort an array of objects > by address ... except maybe hoping to optimize for cpu cache prefetch > or something. > Optimization for an underlying DMA transfer comes to mind. -- Tateru Nino http://dwellonit.blogspot.com/ From bos at lindenlab.com Thu Jul 5 11:55:57 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jul 5 11:56:06 2007 Subject: [sldev] -Werror? In-Reply-To: References: <1182896080.14627.3.camel@localhost> <468199D2.4030606@lindenlab.com> <1182904406.14627.22.camel@localhost> <4682B1F0.7070707@lindenlab.com> <1182973288.27151.2.camel@localhost> Message-ID: <468D3EBD.4020207@lindenlab.com> MATSUU Takuto wrote: > same here. I created a patch. > http://overlays.gentoo.org/dev/matsuu/browser/secondlife/games-simulation/secondlife/files/secondlife-1.17.2.0-size_t.patch Thank you for bringing this up, Callum and Matsuu-san. Turning _FORTIFY_SOURCE off is really not the right approach, so we won't be accepting such a patch. I am instead turning _FORTIFY_SOURCE on, going through the viewer code, and fixing the problems that it is highlighting. This will obviously take a little longer, but it's the responsible thing to do. References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> Message-ID: <468D4D8B.2010001@lindenlab.com> Hi Able, I'm not going to be able to get you off the hook for reading and understanding all of the license files in order to redistribute a product based on them. It puts me in dangerous territory to try to paraphrase them. What you have a license to redistribute depends on which components you pull in. Most of the viewer is available under GPL. Some components (e.g. Kakadu, FMOD, etc), are available under separate licenses, and are marked in the libraries distribution. Using our trademarks requires you to follow our branding guidelines. You'll need to read and understand all of the applicable licenses in order to understand what rights and obligations you have. Rob On 7/2/07 9:38 PM, Able Whitman wrote: > Wow, I feel like tonight is the Soft and Able hour... :) > > On 7/2/07, *Soft Linden* > wrote: > > > This is a good one to ping Rob or the licensing SL alias on directly. > I'm betting if you want to get Linden Lab's blessings on an official, > sanctioned release though, you'd find you had to relicense some > libraries yourself. :( > > > Just to clarify, I'm definitely not looking for an official blessing. > My only goal is to make it easier to package up a test build of the > viewer that involves more than just the viewer executable. > > If I have to distribute a Zip file of loose files and provide > instructions for hacking up an existing client install, that's okay. > But being able to roll my own installer means that people who want to > test my private build (or anyone's private build for that matter) can > have a convenient way of installing a side-by-side viewer so that they > can easily fallback to the official viewer if they so choose. > > Perhaps a compromise solution would be to distribute an installer > which includes all the files except for the libraries that aren't > redistributable? Then users could simply copy those missing files from > their existing install into the folder for the private build. > > I don't know exactly what files can and can't be redistributed, nor do > I pretend to know the particulars of the licensing issues, so I'll CC: > Rob on this as well. > > Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070705/f66aff44/signature.pgp From josh at lindenlab.com Thu Jul 5 13:02:35 2007 From: josh at lindenlab.com (Joshua Bell) Date: Thu Jul 5 13:03:16 2007 Subject: [sldev] Free coverity scan? In-Reply-To: <468608E8.9020401@gmail.com> References: <468608E8.9020401@gmail.com> Message-ID: <468D4E5B.1080504@lindenlab.com> Sorry about the delay in replying - I was away on vacation for several days. "Jason Giglio" wrote: > Coverity has been giving out free static analysis to some open source > projects. > [snip] > So who wants to be the "official contact" to approach Coverity about it? > Linden Lab actually has a license for Coverity Prevent, and we've been running this against the internal code base in an automated fashion. > I'm sure the SL client could use it, considering the number of null > pointer crash patches lately. :) > I believe we've so far addressed 90% of the issues identified by the static analysis tools (either fixed or determined they were false positives), and developers are plowing through them as time and other priorities permit. We've been focused on getting the backlog of pre-existing issues dealt with, but should shortly switch over to doing analysis of in-progress code branches to prevent issues from going out in the first place. Joshua From gwardell at ApprovalSystems.net Thu Jul 5 13:26:54 2007 From: gwardell at ApprovalSystems.net (Gary Wardell) Date: Thu Jul 5 13:27:11 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <468D4D8B.2010001@lindenlab.com> Message-ID: <007001c7bf42$d4261200$a4689943@gwsystems2.com> Hi Able and Rob, Could I make a suggestion here? How about having the end user first install the Linden build of the viewer and then installing updated/modified components/files on top the Linden install. Presumably if Able modified certain files they would not be restricted files and the Linden install would already be covered under Linden's licensing. Admittedly this would be two installs where Able wanted only one, but I think it would get around a potentially sticky issue. Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Rob Lanphier > Sent: Thu, July 05, 2007 3:59 PM > To: Able Whitman > Cc: Second Life Developer Mailing List > Subject: Re: [sldev] Rolling a custom viewer installer? > > > Hi Able, > > I'm not going to be able to get you off the hook for reading and > understanding all of the license files in order to redistribute a > product based on them. It puts me in dangerous territory to try to > paraphrase them. > > What you have a license to redistribute depends on which > components you > pull in. Most of the viewer is available under GPL. Some components > (e.g. Kakadu, FMOD, etc), are available under separate > licenses, and are > marked in the libraries distribution. Using our trademarks > requires you > to follow our branding guidelines. You'll need to read and understand > all of the applicable licenses in order to understand what rights and > obligations you have. > > Rob > > On 7/2/07 9:38 PM, Able Whitman wrote: > > Wow, I feel like tonight is the Soft and Able hour... :) > > > > On 7/2/07, *Soft Linden* > > wrote: > > > > > > This is a good one to ping Rob or the licensing SL > alias on directly. > > I'm betting if you want to get Linden Lab's blessings > on an official, > > sanctioned release though, you'd find you had to relicense some > > libraries yourself. :( > > > > > > Just to clarify, I'm definitely not looking for an official > blessing. > > My only goal is to make it easier to package up a test build of the > > viewer that involves more than just the viewer executable. > > > > If I have to distribute a Zip file of loose files and provide > > instructions for hacking up an existing client install, that's okay. > > But being able to roll my own installer means that people > who want to > > test my private build (or anyone's private build for that > matter) can > > have a convenient way of installing a side-by-side viewer > so that they > > can easily fallback to the official viewer if they so choose. > > > > Perhaps a compromise solution would be to distribute an installer > > which includes all the files except for the libraries that aren't > > redistributable? Then users could simply copy those missing > files from > > their existing install into the folder for the private build. > > > > I don't know exactly what files can and can't be > redistributed, nor do > > I pretend to know the particulars of the licensing issues, > so I'll CC: > > Rob on this as well. > > > > Thanks! > > > From robla at lindenlab.com Thu Jul 5 13:30:11 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 5 13:30:18 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <007001c7bf42$d4261200$a4689943@gwsystems2.com> References: <007001c7bf42$d4261200$a4689943@gwsystems2.com> Message-ID: <468D54D3.2060607@lindenlab.com> Once again, I can't paraphrase the individual licenses or offer legal advice. Rob On 7/5/07 1:26 PM, Gary Wardell wrote: > Hi Able and Rob, > > Could I make a suggestion here? > > How about having the end user first install the Linden build of the viewer and then installing updated/modified components/files > on top the Linden install. > > Presumably if Able modified certain files they would not be restricted files and the Linden install would already be covered under > Linden's licensing. > > Admittedly this would be two installs where Able wanted only one, but I think it would get around a potentially sticky issue. > > Gary > > >> -----Original Message----- >> From: sldev-bounces@lists.secondlife.com >> [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Rob Lanphier >> Sent: Thu, July 05, 2007 3:59 PM >> To: Able Whitman >> Cc: Second Life Developer Mailing List >> Subject: Re: [sldev] Rolling a custom viewer installer? >> >> >> Hi Able, >> >> I'm not going to be able to get you off the hook for reading and >> understanding all of the license files in order to redistribute a >> product based on them. It puts me in dangerous territory to try to >> paraphrase them. >> >> What you have a license to redistribute depends on which >> components you >> pull in. Most of the viewer is available under GPL. Some components >> (e.g. Kakadu, FMOD, etc), are available under separate >> licenses, and are >> marked in the libraries distribution. Using our trademarks >> requires you >> to follow our branding guidelines. You'll need to read and understand >> all of the applicable licenses in order to understand what rights and >> obligations you have. >> >> Rob >> >> On 7/2/07 9:38 PM, Able Whitman wrote: >> >>> Wow, I feel like tonight is the Soft and Able hour... :) >>> >>> On 7/2/07, *Soft Linden* >> > wrote: >>> >>> >>> This is a good one to ping Rob or the licensing SL >>> >> alias on directly. >> >>> I'm betting if you want to get Linden Lab's blessings >>> >> on an official, >> >>> sanctioned release though, you'd find you had to relicense some >>> libraries yourself. :( >>> >>> >>> Just to clarify, I'm definitely not looking for an official >>> >> blessing. >> >>> My only goal is to make it easier to package up a test build of the >>> viewer that involves more than just the viewer executable. >>> >>> If I have to distribute a Zip file of loose files and provide >>> instructions for hacking up an existing client install, that's okay. >>> But being able to roll my own installer means that people >>> >> who want to >> >>> test my private build (or anyone's private build for that >>> >> matter) can >> >>> have a convenient way of installing a side-by-side viewer >>> >> so that they >> >>> can easily fallback to the official viewer if they so choose. >>> >>> Perhaps a compromise solution would be to distribute an installer >>> which includes all the files except for the libraries that aren't >>> redistributable? Then users could simply copy those missing >>> >> files from >> >>> their existing install into the folder for the private build. >>> >>> I don't know exactly what files can and can't be >>> >> redistributed, nor do >> >>> I pretend to know the particulars of the licensing issues, >>> >> so I'll CC: >> >>> Rob on this as well. >>> >>> Thanks! >>> >> >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070705/060297c3/signature.pgp From able.whitman at gmail.com Thu Jul 5 13:46:21 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 5 13:46:24 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <468D4D8B.2010001@lindenlab.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> <468D4D8B.2010001@lindenlab.com> Message-ID: <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> Rob, I apologize, I haven't been clear enough in asking my questions. I'm not asking you, or anyone else, to interpret the licensing agreements for the component libraries for me. Like you said, the licenses are included and the onus is on me to adhere to them. Assuming that I have taken the responsibility for adhering to all the various component licenses, if I also adhere to the guidelines for distributing the software itself ( http://secondlife.com/corporate/trademark/distribution.php), as well as the trademark usage for web and print material ( http://secondlife.com/corporate/trademark/print_web.php) and the policy for fan sites (http://secondlife.com/community/fansites_regs.php), will it be permissible for me to distribute an installer for the viewer built using the scripts included with the viewer source, or are there other guidelines I need to follow as well? --Able On 7/5/07, Rob Lanphier wrote: > > Hi Able, > > I'm not going to be able to get you off the hook for reading and > understanding all of the license files in order to redistribute a > product based on them. It puts me in dangerous territory to try to > paraphrase them. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070705/709b2a5f/attachment.htm From tom at cornish-pasty.com Thu Jul 5 14:28:36 2007 From: tom at cornish-pasty.com (Thomas Rowland) Date: Thu Jul 5 14:28:42 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <468A9F4E.1030704@dzonux.net> Message-ID: <002901c7bf4b$73d9e260$08061f52@tomhome> Just my 2pence on this. > > Dana Fagerstrom wrote: > > If folks ever hope to see a "lite" version of the viewer on say > > handheld devices I'd recommend scrapping the current data packer in > > favor of XML, XDR, SXDF, or Java-like universal encoders. Of course > > using XML for everything would require much too much overhead > > therefore a universal binary format like XDR would be more > applicable. > > [Let the flames begin...] > > > ... So far as my JAVA/J2ME goes, the DataInuptStream and DataOutputStream are more or less the data packer/unpacker, only adding the float/double to/from fixed point stuff may be needed. (http://java.sun.com/javame/reference/apis/jsr118/java/lang/Math.html) Dzonatas, in reply to Dana Fagerstrom wrote: > > For "lite" versions, an extreme XML validator is not needed. > The extreme > XML validator is the default recommendation. The XML > validator not only > slows down the XML intake process, it also has been a tool in the > likeness of a vendor lock-in. There is no need to validate > most XML in > the way large businesses, like Sun's biggest competitor, have > recommended. I've written a clean, "what's essential", XML > parser that > does not depend on any external website for format > definitions, like the > kind you find in DOCTYPE headers, and it is fast. There is no extra > overhead when it is done that way. I know it can be done. > > I personally know it (being derived from SL business features) is > currently in demand for the reason you state, handhelds devices. > > Being that Atomatrix is pre-Java, I'm sure you'll understand > I have my > niche with object-orientated program environments and such patent > issues. For these handheld devices being used in likewise desire, I > might make a kind-of compromise but not really a compromise. Hmm. It > appears GPLv3 hurts Java technology more than anything else unlike > Microsoft/Novell. I *might* move Atomatrix to GPLv3, as that is my > current path. (I'm showing opportunity to work together... > not blowing > steam.) > > =) > While I welcome that, I still think XML is a bit bloated, when most are still paying on a 'bytes transferred' tariff. I also question the need for using XML when working with LL formatted byte data. Also, you could target devices with this optional; http://java.sun.com/javame/reference/apis/jsr172/ From nicholaz at blueflash.cc Thu Jul 5 14:42:17 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 5 14:42:27 2007 Subject: [sldev] Compare functions (llspatialpartition.h) In-Reply-To: <2925011a0707051028s3a5b3477m804067ae3eeb72ae@mail.gmail.com> References: <468D1574.70502@blueflash.cc> <2925011a0707051028s3a5b3477m804067ae3eeb72ae@mail.gmail.com> Message-ID: <468D65B9.6090603@blueflash.cc> Chance Unknown wrote: > when in doubt: make it more than one statement. the > compiler wont care. I was teaching that stuff for 10 years, some things are a matter of personal pride :-) Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From kamilion at gmail.com Thu Jul 5 15:02:43 2007 From: kamilion at gmail.com (Kamilion) Date: Thu Jul 5 15:02:44 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> <468D4D8B.2010001@lindenlab.com> <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> Message-ID: Here's a little idea I'll throw out there. How about a commandline function to the Linden Labs provided SL binaries: "--installpath". With this, it's trivial to embed/download the LL installer within another installer for the third party binaries, call the LL installer first with the requested path from the container installer, and then install the required files over the originals in the requested path. What are your thoughts on that? -- Kamilion On 7/5/07, Able Whitman wrote: > Rob, > > I apologize, I haven't been clear enough in asking my questions. I'm not > asking you, or anyone else, to interpret the licensing agreements for the > component libraries for me. Like you said, the licenses are included and the > onus is on me to adhere to them. > > Assuming that I have taken the responsibility for adhering to all the > various component licenses, if I also adhere to the guidelines for > distributing the software itself ( > http://secondlife.com/corporate/trademark/distribution.php), > as well as the trademark usage for web and print material > (http://secondlife.com/corporate/trademark/print_web.php ) > and the policy for fan sites > (http://secondlife.com/community/fansites_regs.php), will > it be permissible for me to distribute an installer for the viewer built > using the scripts included with the viewer source, or are there other > guidelines I need to follow as well? > > --Able > > > On 7/5/07, Rob Lanphier wrote: > > Hi Able, > > > > I'm not going to be able to get you off the hook for reading and > > understanding all of the license files in order to redistribute a > > product based on them. It puts me in dangerous territory to try to > > paraphrase them. > > > > From anthony at lindenlab.com Thu Jul 5 15:48:29 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Jul 5 15:48:37 2007 Subject: [sldev] Source release for 1.18.0.4 Message-ID: <468D753D.2020906@lindenlab.com> Hello Everyone, 1.18.0.4 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_beta-1.18.0.4 Release note information here: Posted below. Checksums: 5595c61a86722721ec7fe6dbe8aaaae5 slviewer-darwin-libs-beta-1.18.0.4.tar.gz 09a953f7019b3a9336f2f2f8c4188bcb slviewer-linux-libs-beta-1.18.0.4.tar.gz f87cc2735f04e61df3a0905249aea7f1 slviewer-src-beta-1.18.0.4.tar.gz e406240ff3d85ca6a5df8af6561f2ee0 slviewer-artwork-beta-1.18.0.4.zip 0d6dccd5369f04d9cb5d9e5a7c05e8b1 slviewer-src-beta-1.18.0.4.zip fdcead59fa41d6488e3bcc8452bcafa1 slviewer-win32-libs-beta-1.18.0.4.zip SVN checkout: http://svn.secondlife.com/svn/linden/branches/release-candidate Enjoy. -Anthony Bug fixes: * Fixed SVC-371: Fix the legibility and grammar/consistency of the new llOwnerSay implementation * Fixed SVC-286: deleted fully-permissive objects owned by others skip trash * Fixed SVC-251: Death teleport fails when teleporting to a home point you no longer have access to * Fixed VWR-1418: Progressive memory consumption (leak) since 1.17.1 * Fixed VWR-1410: Quirk in net.cpp * Fixed VWR-1351: Violation against the conding standard in llfloaterchat.cpp * Fixed VWR-1184: [Linux VWR] Signal 7 (SIGBUS) Error (caused by libtcmalloc) * Fixed VWR-1147: A patch set is provided to add an optional 'Confirm Exit' pop-up window for most user client exit methods. Prevents the 'Accidental Quit'. * Fixed VWR-962: llprocessor.cpp: enable x86 detection for GCC * Fixed VWR-605: Include the SL date & day with the time * Fixed VWR-561: Blurry arrows in camera control and other graphics issues * Fixed VWR-53: Inconsistency in order of AV texture layer between the upper and lower body * Fixed group chat sessions not working * Fixed script email only receiving after sim is restarted * Fixed permission requests not properly muted * Fixed viewer "channel" now visible in the lower right corner next to the version number * Fixed presence not properly being report to others upon initial login * Fixed double text overlay on About Land > General tab * Fixed "Top Scripts" window does not refresh when button is pressed while "Top Colliders" list is still open From dzonatas at dzonux.net Thu Jul 5 17:02:31 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 5 17:02:01 2007 Subject: [sldev] Hunger Strike Message-ID: <468D8697.1090907@dzonux.net> It appears I have no option left to do except a hunger strike. This will be my last day to eat food until I'm *formally* employed by Linden Labs with a decent salary to support my family. I want my family back. This came about a conversation today/yesterday with Gigs about the DNC. There are other serious matter occurring in my family that the issues touched upon. I believe I replied in likewise sarcastic remark while I still handle these other personal issues. I can't figure out why one is ok to joke around but when I do it I get torn down. Whatever. Let me continue my motive here. Gigs, I believe you deserve your own private sim that you can host at your own home office and still have it connected straight off of Agni. Very simple reason, your commercial interests *may appear* as anti-trust. The answer is simple... your own sim... your own office... Agni enabled. If your not really interested in that, fine. My bad for even trying. I thought we were having fun at this even if sarcastical. Rob asked if there is something he could do for me, why not start right there Rob. Make it very formal contract or commercial license that enables Gigs to run an Agni sim from his home office with access to server source. It's terrible people can't see my good intentions. As for me, tonight will begin the start of day 1. Sure.. I got time... I'm severely overweight and know I can survive on water alone... right? Linden Labs has a new motto... I have a goal to test that motto. 232lbs right now and I'm about to eat my last solid meal for... until... I don't know. Take care -- Power to Change the Void From kerdezixe at gmail.com Thu Jul 5 17:20:04 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jul 5 17:20:06 2007 Subject: [sldev] Hunger Strike In-Reply-To: <468D8697.1090907@dzonux.net> References: <468D8697.1090907@dzonux.net> Message-ID: <8a1bfe660707051720h2887717dkba51b5f9b478e4dd@mail.gmail.com> On 7/6/07, Dzonatas wrote: > It appears I have no option left to do except a hunger strike. This will > be my last day to eat food until I'm *formally* employed by Linden Labs > with a decent salary to support my family. I want my family back. What the.... huh ? is it a weird joke ? > As for me, tonight will begin the start of day 1. Sure.. I got time... > I'm severely overweight and know I can survive on water alone... right? wrong :) > -- > Power to Change the Void With an hunger strike ? -- kerunix Flan From jhurliman at wsu.edu Thu Jul 5 18:28:58 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Jul 5 18:30:45 2007 Subject: [sldev] Hunger Strike In-Reply-To: <468D8697.1090907@dzonux.net> References: <468D8697.1090907@dzonux.net> Message-ID: <468D9ADA.6040308@wsu.edu> Dzonatas wrote: > > As for me, tonight will begin the start of day 1. Sure.. I got time... > I'm severely overweight and know I can survive on water alone... right? > > Linden Labs has a new motto... I have a goal to test that motto. > > 232lbs right now and I'm about to eat my last solid meal for... > until... I don't know. > > Take care > You shouldn't go on just water alone. Add a few spoonfuls of salt and sugar here and there, and supplement the glasses of water with sports drinks that have electrolytes like Gatorade or Powerade. John Hurliman From kerdezixe at gmail.com Thu Jul 5 18:36:55 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jul 5 18:36:57 2007 Subject: [sldev] Hunger Strike In-Reply-To: <468D9ADA.6040308@wsu.edu> References: <468D8697.1090907@dzonux.net> <468D9ADA.6040308@wsu.edu> Message-ID: <8a1bfe660707051836l75d3571di33d6e57e50240cea@mail.gmail.com> On 7/6/07, John Hurliman wrote: > > You shouldn't go on just water alone. Add a few spoonfuls of salt and > sugar here and there, and supplement the glasses of water with sports > drinks that have electrolytes like Gatorade or Powerade. Electrolytes ? like in Idiocracy ? :) -- kerunix Flan From jianr3n at gmail.com Thu Jul 5 20:57:22 2007 From: jianr3n at gmail.com (jianren chua) Date: Thu Jul 5 20:57:25 2007 Subject: [sldev] SL/RL Interfaces Message-ID: <76d226120707052057w5314ae6frc8154606b20c3184@mail.gmail.com> Hi all, I'm currently doing a project base on second life which involve communicating between the in-world and the real world. Actually, my hardware is connected directly to the PC which the 2nd client is running. Hence, if there are some event handler inside the 2nd client which can capture inputs triggered by the LSL inside an in-world object, I would then be able to control the hardware. I have actually managed to control the LEDs by hardcoding it in the client code. I guessed I have to do more research on the 2nd Life classes and libraries, but I was hoping you could shed some light if you have done it before and come across it somewhere. Jr -- Time aNd t|de waIt f0r No mAn, St0p t|me! ~Life is for now, work is for later~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070706/757f31ad/attachment.htm From odysseus654 at gmail.com Thu Jul 5 21:19:38 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Thu Jul 5 21:19:40 2007 Subject: [sldev] SL/RL Interfaces In-Reply-To: <76d226120707052057w5314ae6frc8154606b20c3184@mail.gmail.com> References: <76d226120707052057w5314ae6frc8154606b20c3184@mail.gmail.com> Message-ID: <1674f6c70707052119x6028724csd782f3a14e81e6cc@mail.gmail.com> If you are trying to get feedback from an in-world object, then I'm not sure that a custom connection with the agent through the client is the way to go here. Can you clarify how communications with the client would help if your in-world object is running purely on the SL sim servers? It might be more appropriate to use the traditional communication pathways like llHTTPRequest or XML-RPC, possibly with a website to mediate the communication. On 7/5/07, jianren chua wrote: > > Hi all, > I'm currently doing a project base on second life which involve > communicating between the in-world and the real world. > Actually, my hardware is connected directly to the PC which the 2nd client > is running. Hence, if there are some event handler inside the 2nd client > which can capture inputs triggered by the LSL inside an in-world object, I > would then be able to control the hardware. I have actually managed to > control the LEDs by hardcoding it in the client code. I guessed I have to do > more research on the 2nd Life classes and libraries, but I was hoping you > could shed some light if you have done it before and come across it > somewhere. > > Jr > > > -- > Time aNd t|de waIt f0r No mAn, St0p t|me! > > ~Life is for now, work is for later~ > _______________________________________________ > 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/20070705/16a564c9/attachment-0001.htm From kerdezixe at gmail.com Thu Jul 5 22:03:30 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jul 5 22:03:32 2007 Subject: [sldev] SL/RL Interfaces In-Reply-To: <1674f6c70707052119x6028724csd782f3a14e81e6cc@mail.gmail.com> References: <76d226120707052057w5314ae6frc8154606b20c3184@mail.gmail.com> <1674f6c70707052119x6028724csd782f3a14e81e6cc@mail.gmail.com> Message-ID: <8a1bfe660707052203k429880uf9e9562c3d583010@mail.gmail.com> Unless it require fast update. e.g : moving/rotating some prims ingame to control a robot arm irl (or a camera, or any remote controlable device) I think something like that could be done using libsecondlife and the script sending his state to an agent using chat/text/im. Could match some need, even if it's not always the best solution. -- kerunix Flan On 7/6/07, Erik Anderson wrote: > If you are trying to get feedback from an in-world object, then I'm not sure > that a custom connection with the agent through the client is the way to go > here. Can you clarify how communications with the client would help if your > in-world object is running purely on the SL sim servers? It might be more > appropriate to use the traditional communication pathways like llHTTPRequest > or XML-RPC, possibly with a website to mediate the communication. > > > On 7/5/07, jianren chua wrote: > > > > > > Hi all, > > I'm currently doing a project base on second life which involve > communicating between the in-world and the real world. > > Actually, my hardware is connected directly to the PC which the 2nd client > is running. Hence, if there are some event handler inside the 2nd client > which can capture inputs triggered by the LSL inside an in-world object, I > would then be able to control the hardware. I have actually managed to > control the LEDs by hardcoding it in the client code. I guessed I have to do > more research on the 2nd Life classes and libraries, but I was hoping you > could shed some light if you have done it before and come across it > somewhere. > > > > Jr > > > > -- > > Time aNd t|de waIt f0r No mAn, St0p t|me! > > > > ~Life is for now, work is for later~ > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From gigstaggart at gmail.com Fri Jul 6 01:41:10 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jul 6 01:41:27 2007 Subject: [sldev] Free coverity scan? In-Reply-To: <468D4E5B.1080504@lindenlab.com> References: <468608E8.9020401@gmail.com> <468D4E5B.1080504@lindenlab.com> Message-ID: <468E0026.4030309@gmail.com> Joshua Bell wrote: > I believe we've so far addressed 90% of the issues identified by the > static analysis tools (either fixed or determined they were false > positives), and developers are plowing through them as time and other > priorities permit. Why not post the remaining parts of the report then, so we can help? -Jason From blakar at gmail.com Fri Jul 6 02:35:29 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Fri Jul 6 02:35:33 2007 Subject: [sldev] Source release for 1.18.0.4 In-Reply-To: <468D753D.2020906@lindenlab.com> References: <468D753D.2020906@lindenlab.com> Message-ID: <7992d0d60707060235j2567abbt6326934b6e9ea8c1@mail.gmail.com> Any Linden wish to comment on the SSE stuff? What did tests show upto now? Will it be enabled in future default builds? Can we spread the love and use the same tags to add SSE code elsewhere? Dirk aka Blakar Ogre On 7/6/07, Anthony Foster wrote: > Hello Everyone, > > 1.18.0.4 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_beta-1.18.0.4 > > > Release note information here: Posted below. > > Checksums: > > 5595c61a86722721ec7fe6dbe8aaaae5 slviewer-darwin-libs-beta-1.18.0.4.tar.gz > 09a953f7019b3a9336f2f2f8c4188bcb slviewer-linux-libs-beta-1.18.0.4.tar.gz > f87cc2735f04e61df3a0905249aea7f1 slviewer-src-beta-1.18.0.4.tar.gz > e406240ff3d85ca6a5df8af6561f2ee0 slviewer-artwork-beta-1.18.0.4.zip > 0d6dccd5369f04d9cb5d9e5a7c05e8b1 slviewer-src-beta-1.18.0.4.zip > fdcead59fa41d6488e3bcc8452bcafa1 slviewer-win32-libs-beta-1.18.0.4.zip > > SVN checkout: > http://svn.secondlife.com/svn/linden/branches/release-candidate > > > Enjoy. > -Anthony > > > Bug fixes: > * Fixed SVC-371: Fix the legibility and grammar/consistency of the new > llOwnerSay implementation > * Fixed SVC-286: deleted fully-permissive objects owned by others skip trash > * Fixed SVC-251: Death teleport fails when teleporting to a home point > you no longer have access to > * Fixed VWR-1418: Progressive memory consumption (leak) since 1.17.1 > * Fixed VWR-1410: Quirk in net.cpp > * Fixed VWR-1351: Violation against the conding standard in > llfloaterchat.cpp > * Fixed VWR-1184: [Linux VWR] Signal 7 (SIGBUS) Error (caused by > libtcmalloc) > * Fixed VWR-1147: A patch set is provided to add an optional 'Confirm > Exit' pop-up window for most user client exit methods. Prevents the > 'Accidental Quit'. > * Fixed VWR-962: llprocessor.cpp: enable x86 detection for GCC > * Fixed VWR-605: Include the SL date & day with the time > * Fixed VWR-561: Blurry arrows in camera control and other graphics issues > * Fixed VWR-53: Inconsistency in order of AV texture layer between the > upper and lower body > * Fixed group chat sessions not working > * Fixed script email only receiving after sim is restarted > * Fixed permission requests not properly muted > * Fixed viewer "channel" now visible in the lower right corner next to > the version number > * Fixed presence not properly being report to others upon initial login > * Fixed double text overlay on About Land > General tab > * Fixed "Top Scripts" window does not refresh when button is pressed > while "Top Colliders" list is still open > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sllists at boroon.dasgupta.ch Fri Jul 6 04:58:24 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri Jul 6 04:58:32 2007 Subject: VWR-1401 "ImportError: No module named indra" in linden/scripts/template_verifier.py [Re: [sldev] Source release for 1.18.0.4] In-Reply-To: <468D753D.2020906@lindenlab.com> References: <468D753D.2020906@lindenlab.com> Message-ID: <20070706135824.sdvbralsg0cwsgcw@datendelphin.net> anybody else seeing this (VWR-1401)[1] or am I doing something wrong? Boroondas Links: ------ [1] https://jira.secondlife.com/browse/VWR-1401 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070706/caa84603/attachment.htm From nicholaz at blueflash.cc Fri Jul 6 05:50:31 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 6 05:50:36 2007 Subject: [sldev] Jira still has a problem Message-ID: <468E3A97.4000605@blueflash.cc> There's stil a problem with JIRA indexing. One of my issues with patch is there if I reference it directly but does not show in "my reported issues" or anywhere else Nick From matthew.dowd at hotmail.co.uk Fri Jul 6 07:33:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Jul 6 07:33:19 2007 Subject: [sldev] Jira still has a problem Message-ID: Well, the reason I posted the patch for VWR-1549 twice was because the first time, I somehow posted it anonymously (see https://jira.secondlife.com/secure/ManageAttachments.jspa?id=12842). Whilst Torley's blog on using jira was laudable, it could have been timed after all these problems have been fixed - any news on the upgrade to a newer version - jira.secondlife is on 3.71, 3.7.2 alledgedly fixes some of the bugs we've seen, but the latest release of Jira which came out on 3rd July is 3.9.3! Matthew ---------------------------------------- > Date: Fri, 6 Jul 2007 14:50:31 +0200 > From: nicholaz@blueflash.cc > To: sldev@lists.secondlife.com > Subject: [sldev] Jira still has a problem > > > There's stil a problem with JIRA indexing. One of my issues > with patch is there if I reference it directly but does not > show in "my reported issues" or anywhere else > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From dzonatas at dzonux.net Fri Jul 6 06:48:22 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 6 07:36:24 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <002901c7bf4b$73d9e260$08061f52@tomhome> References: <002901c7bf4b$73d9e260$08061f52@tomhome> Message-ID: <468E4826.1010705@dzonux.net> Thomas Rowland wrote: > While I welcome that, I still think XML is a bit bloated, when most are > still paying > on a 'bytes transferred' tariff. > ... That is a good concern, and I agree for that reason. XML appears based off of older word processor document formats like Word Perfect, but done with all upper ASCII until of control characters. With that side note, the default XML is very bloated to make sure a variety of XML readers understand the content. It is pointless to force readers to work through highly-portable format when the sender and reader can negotiate a more efficient format. That would be something like what "caps" does in the current SL technology. It is a good feature to have. Likewise, in Atomatrix, I still use non-XML formats for better storage formats. > I also question the need for using XML when working with LL formatted byte > data. > ... It really depends on the negotiation levels. There is no rule in XML that everything must stay in XML. > Also, you could target devices with this optional; > http://java.sun.com/javame/reference/apis/jsr172/ > ... Excellent! Consider that T-Mobil just started to offer mesh-network enabled handhelds (with java), I look forward to being able to negotiate and incorporate virtual realities with the real world. =) Hehe, reminds me of the PADD object found in virtual worlds about 20-25 years ago. The real world is just so far behind! =) -- Power to Change the Void From nicholaz at blueflash.cc Fri Jul 6 07:47:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 6 07:47:35 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> Message-ID: <468E5602.2090001@blueflash.cc> Dirk, did you find more of those virtualy in performance senstitiv areas of the viewer? Nick Dirk Moerenhout wrote: > For starters: I'm no C++ guru so I might be missing something. Feel > free to enlighten me if so ;-) > > My question is the following: > Is there a purpose to declare a function virtual if you've no > intention to overload it? As an example I'd like to take LLTreeNode. > > In LLTreeNode we've "virtual LLTreeListener* getListener(U32 index) > const { return mListeners[index]; }" From blakar at gmail.com Fri Jul 6 08:10:47 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Fri Jul 6 08:10:53 2007 Subject: [sldev] Question on Overuse of virtual in C++ In-Reply-To: <468E5602.2090001@blueflash.cc> References: <7992d0d60707011105t1822eff3r7dfc1b41855d8f0@mail.gmail.com> <7992d0d60707011107g54da1c06kc168bbefe1e1306@mail.gmail.com> <468E5602.2090001@blueflash.cc> Message-ID: <7992d0d60707060810k3788a3a0j88406ff0f11909af@mail.gmail.com> Not yet, I'm still working on the consequences of the change resulting from the below. I just removed all the virtuals except for the destructor (it's the only virtual that will have an effect on how stuff gets executed). The result of getting inlined functions is that it's now more clear who is doing all the calls as the cycles shift towards the caller. It hence reduces fragmentation in the top consumers. As such it's becoming easier to identify some of the top targets for improvement. I'm using Event Based Profiling in CodeAnalyst and hence I not only see the hotspots but also other info like IPC. Low IPC helps identifying similar cases as IPC drops a lot if you've too much "overhead" instructions. So I guess I'll try to weed out some more over-use (if possible). Resulting patches will be split in order to have clear split for each on what they touch. I was near to testing something yesterday evening when somebody decided to swith to 18.0.0.4 just when I wanted to do the next profile :) I'll hence migrate to 18.0.0.4 first and then continue. FYI: I've also tried to experiment with the heap but enabling LFH has not yet proven to be that useful. I'm now considering whether we shouldn't guide some of the vector usage. We can cut down on allocations if we avoid the need to grow/shrink memory allocation too much. Dirk aka Blakar Ogre On 7/6/07, Nicholaz Beresford wrote: > > Dirk, > > did you find more of those virtualy in performance senstitiv > areas of the viewer? > > > Nick > > > Dirk Moerenhout wrote: > > For starters: I'm no C++ guru so I might be missing something. Feel > > free to enlighten me if so ;-) > > > > My question is the following: > > Is there a purpose to declare a function virtual if you've no > > intention to overload it? As an example I'd like to take LLTreeNode. > > > > In LLTreeNode we've "virtual LLTreeListener* getListener(U32 index) > > const { return mListeners[index]; }" > > From nicholaz at blueflash.cc Fri Jul 6 09:03:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 6 09:03:32 2007 Subject: [sldev] Collection of JIRAs suitable for open source Message-ID: <468E67C7.4040008@blueflash.cc> I just created a JIRA to serve as a link list to issues that lend themselves to be solved by open sourcers. If you happen to come across something on the JIRA, please link it there: https://jira.secondlife.com/browse/VWR-1577 I also put a link ot it onto the Wiki (page for "Implementing Feetures). Nick From robla at lindenlab.com Fri Jul 6 10:06:20 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jul 6 10:06:31 2007 Subject: [sldev] JIRA upgrade, Sunday, 7/8, 10pm-12am PDT Message-ID: <468E768C.4080307@lindenlab.com> Hi all, Sorry for the flaky performance of JIRA lately. We're hoping that upgrading to the latest version will address the issues that we're seeing, so an upgrade is scheduled for Sunday, July 8 at 10pm PDT until midnight. During this time, jira.secondlife.com will be unavailable. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070706/d9f53644/signature.pgp From dale at daleglass.net Fri Jul 6 12:07:41 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Fri Jul 6 12:08:02 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <468E4826.1010705@dzonux.net> References: <002901c7bf4b$73d9e260$08061f52@tomhome> <468E4826.1010705@dzonux.net> Message-ID: <20070706190741.GA21402@bruno.sbruno> On Fri, Jul 06, 2007 at 06:48:22AM -0700, Dzonatas wrote: > Thomas Rowland wrote: > >While I welcome that, I still think XML is a bit bloated, when most are > >still paying > >on a 'bytes transferred' tariff. > > > ... > That is a good concern, and I agree for that reason. > > XML appears based off of older word processor document formats like Word > Perfect, but done with all upper ASCII until of control characters. XML is based on SGML, which had largely the same goals. XML is a simplification of it. http://en.wikipedia.org/wiki/SGML > > With that side note, the default XML is very bloated to make sure a > variety of XML readers understand the content. It is pointless to force > readers to work through highly-portable format when the sender and > reader can negotiate a more efficient format. That would be something > like what "caps" does in the current SL technology. It is a good feature > to have. XML is bloated to be human readable. For example, the stuff syntax. They could have done stuff, and actually I think SGML supports that. But take any HTML document, and turn all closing tags into a . Now how do you tell quickly where the effect of or is ending? Programming languages have it easier due to indentation, but in a XML document it'd be impractical. The nice thing about XML is that it's extensible -- it takes serious work to design such a format that you can add something extra without breaking backwards compatibility. And then, pretty much everybody ends up designing about the same thing in slightly different ways. As far as I can tell, pretty much everybody comes up with some way of transmitting key/value pairs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070706/da108a38/attachment.pgp From able.whitman at gmail.com Fri Jul 6 12:44:52 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jul 6 12:44:54 2007 Subject: [sldev] Mute Visibility Preview (Re: More on Mute Visibility) Message-ID: <7b3a84fb0707061244p5b8ecfaahcd8aabadd9f7ed0d@mail.gmail.com> Howdy, In between work and occasionally catching some sleep, I've got a preview of my Mute Visibility feature ready to test. Before I make it generally available, I'd like a couple people to install it and take a look, to shake out any "well it works on my machine" problems that I've overlooked. My build is available for Windows only, and requires an existing 1.17.2.0install (I have not tried it with 1.7.3.0, so it may or may not work). If you'd like to give it a go, please reply just to me, and I'll send it to the first couple folks to reply. Once I've got some confidence that the test release is usable, I'll post a download link here. Cheers! --Able On 6/21/07, Able Whitman wrote: > > Howdy, > > On and off, I've been investigating the feasibility of implementing > "Visibility Muting" as Nicholaz describes in VWR-1017 (https://jira.secondlife.com/browse/VWR-1017 > ), and as discussed in a few threads on this list. I'm pretty close to > having a proof-of-concept patch ready which adds the ability to mute the > visibility of objects by their ID, in much the same fashion that the > existing chat muting function works. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070706/01c9c31f/attachment.htm From dzonatas at dzonux.net Fri Jul 6 13:35:01 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 6 13:34:28 2007 Subject: [sldev] Hunger Strike In-Reply-To: <468D9ADA.6040308@wsu.edu> References: <468D8697.1090907@dzonux.net> <468D9ADA.6040308@wsu.edu> Message-ID: <468EA775.1030104@dzonux.net> John Hurliman wrote: > You shouldn't go on just water alone. Add a few spoonfuls of salt and > sugar here and there, and supplement the glasses of water with sports > drinks that have electrolytes like Gatorade or Powerade. > > John Hurliman Right. Chemistry class says, "pure water no good," so herbal teas and real mineral water are safe. -- Power to Change the Void From dzonatas at dzonux.net Fri Jul 6 13:44:38 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 6 13:44:05 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <20070706190741.GA21402@bruno.sbruno> References: <002901c7bf4b$73d9e260$08061f52@tomhome> <468E4826.1010705@dzonux.net> <20070706190741.GA21402@bruno.sbruno> Message-ID: <468EA9B6.9030700@dzonux.net> dale@daleglass.net wrote: > XML is based on SGML, which had largely the same goals. XML is a > simplification of it. > > http://en.wikipedia.org/wiki/SGML > ... Yep. > XML is bloated to be human readable. For example, the stuff > syntax. They could have done stuff, and actually I think SGML > supports that. But take any HTML document, and turn all closing tags > into a . Now how do you tell quickly where the effect of or > is ending? > ... Compression methods better than RLE use a technique to replace common pattens with shorter ones, and they put the original pattern in an array. It wouldn't be to hard to compress XML keywords this way, so those aren't critical for size counts. -- Power to Change the Void From eponymousdylan at googlemail.com Fri Jul 6 14:07:43 2007 From: eponymousdylan at googlemail.com (EponymousDylan Ra) Date: Fri Jul 6 14:07:47 2007 Subject: [sldev] Artist/Song info from audio stream - what to do with it? Message-ID: Hi all I'd like to be able to display in-world the artist and song name from the audio stream that is currently playing. Extracting the information from the audio stream looks easy. In fact, the code to do it is already in audioengine_fmod.cpp - just commented out for some reason. My question is - what do I do with this information once I've got it? I guess it needs to be accessible from script, so does that imply adding a new script method, e.g. llGetParcelMusicInfo()? Or maybe there's already some generic GetData() method that I could piggy-back on? I guess ideally the data would be pushed as an event to a script, so the script doesn't have to poll for the info. If the new script method/event is the right way to go, how much resistance am I likely to get for adding this through a patch? If it's not the right way to go, any other ideas? Thanks E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070706/37c3da0e/attachment.htm From josh at lindenlab.com Fri Jul 6 14:13:05 2007 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jul 6 14:12:03 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <468EA9B6.9030700@dzonux.net> References: <002901c7bf4b$73d9e260$08061f52@tomhome> <468E4826.1010705@dzonux.net> <20070706190741.GA21402@bruno.sbruno> <468EA9B6.9030700@dzonux.net> Message-ID: <468EB061.2000804@lindenlab.com> Dzonatas wrote: > Compression methods better than RLE use a technique to replace common > pattens with shorter ones, and they put the original pattern in an > array. It wouldn't be to hard to compress XML keywords this way, so > those aren't critical for size counts. Before anyone goes off to try reinventing the wheel, there are existing projects in place to study more efficient transportation of XML (e.g. binary formats, compression schemes, etc) http://www.w3.org/XML/EXI/ Which appears to be the follow-on to a working group explicitly focused on binary XML formats: http://www.w3.org/XML/Binary/ Token-based compressors (think: gzip) take care of a lot of XML's verbosity (i.e. tags & attributes). The next killer is often numbers - ints and floats bloat up when serialized as strings, and efficiently compressing those requires some understanding of the data being serialized as XML in the first place. From soft at lindenlab.com Fri Jul 6 14:31:45 2007 From: soft at lindenlab.com (Soft Linden) Date: Fri Jul 6 14:31:47 2007 Subject: [sldev] Hunger Strike In-Reply-To: <468D8697.1090907@dzonux.net> References: <468D8697.1090907@dzonux.net> Message-ID: <9e6e5c9e0707061431l5b16b761m47886ba7b0ed415e@mail.gmail.com> On 7/5/07, Dzonatas wrote: > It appears I have no option left to do except a hunger strike. This will > be my last day to eat food until I'm *formally* employed by Linden Labs > with a decent salary to support my family. I want my family back. Dzonatas, we're going to get back to you off-list, but I don't know that it can be before the weekend. In the mean time, I'd really encourage ya not to do what you're talking about here. We can never be in the position where we do something just because someone made a threat to hurt themselves, even if it's just starving for a while. Other people might follow your example if we did. So let us know you're eating something, even if ya want it to be just diet-sized, okay? :( You've helped so much with the optimization and some of the preparation for and participation in the triage meetings. Please don't undo the good reputation you've built here. If any of the rest of ya know Dzonatas well, maybe it's a good time to talk some in-world or in private email. But please don't start making jokes and stuff on the list. From mattk at electricsheepcompany.com Fri Jul 6 14:39:28 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Fri Jul 6 14:39:20 2007 Subject: [sldev] Source release for 1.18.0.4 In-Reply-To: <468D753D.2020906@lindenlab.com> References: <468D753D.2020906@lindenlab.com> Message-ID: <468EB690.2040007@electricsheepcompany.com> Hey all, I just uploaded some new VS2005 project files for 1.18.0.4 to VWR-1151. See: https://jira.secondlife.com/browse/VWR-1151 -Matt Anthony Foster wrote: > Hello Everyone, > > 1.18.0.4 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_beta-1.18.0.4 > > > Release note information here: Posted below. > > Checksums: > > 5595c61a86722721ec7fe6dbe8aaaae5 slviewer-darwin-libs-beta-1.18.0.4.tar.gz > 09a953f7019b3a9336f2f2f8c4188bcb slviewer-linux-libs-beta-1.18.0.4.tar.gz > f87cc2735f04e61df3a0905249aea7f1 slviewer-src-beta-1.18.0.4.tar.gz > e406240ff3d85ca6a5df8af6561f2ee0 slviewer-artwork-beta-1.18.0.4.zip > 0d6dccd5369f04d9cb5d9e5a7c05e8b1 slviewer-src-beta-1.18.0.4.zip > fdcead59fa41d6488e3bcc8452bcafa1 slviewer-win32-libs-beta-1.18.0.4.zip > > SVN checkout: > http://svn.secondlife.com/svn/linden/branches/release-candidate > > > Enjoy. > -Anthony > > > Bug fixes: > * Fixed SVC-371: Fix the legibility and grammar/consistency of the new > llOwnerSay implementation > * Fixed SVC-286: deleted fully-permissive objects owned by others skip > trash > * Fixed SVC-251: Death teleport fails when teleporting to a home point > you no longer have access to > * Fixed VWR-1418: Progressive memory consumption (leak) since 1.17.1 > * Fixed VWR-1410: Quirk in net.cpp > * Fixed VWR-1351: Violation against the conding standard in > llfloaterchat.cpp > * Fixed VWR-1184: [Linux VWR] Signal 7 (SIGBUS) Error (caused by > libtcmalloc) > * Fixed VWR-1147: A patch set is provided to add an optional 'Confirm > Exit' pop-up window for most user client exit methods. Prevents the > 'Accidental Quit'. > * Fixed VWR-962: llprocessor.cpp: enable x86 detection for GCC > * Fixed VWR-605: Include the SL date & day with the time > * Fixed VWR-561: Blurry arrows in camera control and other graphics issues > * Fixed VWR-53: Inconsistency in order of AV texture layer between the > upper and lower body > * Fixed group chat sessions not working > * Fixed script email only receiving after sim is restarted > * Fixed permission requests not properly muted > * Fixed viewer "channel" now visible in the lower right corner next to > the version number > * Fixed presence not properly being report to others upon initial login > * Fixed double text overlay on About Land > General tab > * Fixed "Top Scripts" window does not refresh when button is pressed > while "Top Colliders" list is still open > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From seg at haxxed.com Fri Jul 6 14:43:37 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jul 6 14:43:17 2007 Subject: [sldev] Artist/Song info from audio stream - what to do with it? In-Reply-To: References: Message-ID: <1183758217.16828.12.camel@localhost> On Fri, 2007-07-06 at 22:07 +0100, EponymousDylan Ra wrote: > Hi all > > I'd like to be able to display in-world the artist and song name from > the audio stream that is currently playing. > > Extracting the information from the audio stream looks easy. In fact, > the code to do it is already in audioengine_fmod.cpp - just commented > out for some reason. > > My question is - what do I do with this information once I've got it? > I guess it needs to be accessible from script, so does that imply > adding a new script method, e.g. llGetParcelMusicInfo()? Or maybe > there's already some generic GetData() method that I could piggy-back > on? I guess ideally the data would be pushed as an event to a script, > so the script doesn't have to poll for the info. Scripts run sim-side, audio streaming is entirely client side. You can't really connect the two very easily. I've hacked together a system, where my oddcastv2-xmms streaming source uses the songchange plugin to call a python script that makes an XML-RPC call to push the metadata to an in-world object. Apparently there's another system about that apparently involves an in-world script polling the streaming server directly over http. I haven't gotten my hands on it so I don't know the details. Really, I'd like to rework the streaming UI to be more than a couple buttons and a slider on the bottom of the screen, I'd like to make it a full floating window, which can display metadata and whatnot. I'd also like to eliminate the property owner monopoly on streaming music, what I'd really like to see is a "Radio Station" object that could be freely passed around, and played in any location, much like a landmarks and notecards. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070706/1bdabf3e/attachment-0001.pgp From dzonatas at dzonux.net Fri Jul 6 15:30:40 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 6 15:30:07 2007 Subject: The Tao of Ceasar Chavez Re: [sldev] Hunger Strike In-Reply-To: <9e6e5c9e0707061431l5b16b761m47886ba7b0ed415e@mail.gmail.com> References: <468D8697.1090907@dzonux.net> <9e6e5c9e0707061431l5b16b761m47886ba7b0ed415e@mail.gmail.com> Message-ID: <468EC290.4040703@dzonux.net> Soft Linden wrote: > We can never be in the position where we do something just because > someone made a > threat to hurt themselves, even if it's just starving for a while. > Other people might follow your example if we did. I doubt I'd be an example, unlike Ceaser Chavez: http://www.colapublib.org/chavez/bio.htm His strikes were not to hurt himself. His strikes were to relieve pain and make improvements. As Philip himself wrote, "to improve the human condition..."... by doing what? Besides such off-path and daunting visions on this list, like "low hanging fruit..." Si se pueda! -- Power to Change the Void From eponymousdylan at googlemail.com Fri Jul 6 15:44:11 2007 From: eponymousdylan at googlemail.com (EponymousDylan Ra) Date: Fri Jul 6 15:44:14 2007 Subject: [sldev] Re: Artist/Song info from audio stream - what to do with it? In-Reply-To: References: Message-ID: > Scripts run sim-side, audio streaming is entirely client side. You can't > really connect the two very easily. Of course - how silly of me. > I've hacked together a system, where my oddcastv2-xmms streaming source > uses the songchange plugin to call a python script that makes an XML-RPC > call to push the metadata to an in-world object. I haven't looked at the XML-RPC mechanism at all so that will be my next port of call. Thanks for the help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070706/c234df41/attachment.htm From kerdezixe at gmail.com Fri Jul 6 15:47:33 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jul 6 15:47:35 2007 Subject: The Tao of Ceasar Chavez Re: [sldev] Hunger Strike In-Reply-To: <468EC290.4040703@dzonux.net> References: <468D8697.1090907@dzonux.net> <9e6e5c9e0707061431l5b16b761m47886ba7b0ed415e@mail.gmail.com> <468EC290.4040703@dzonux.net> Message-ID: <8a1bfe660707061547u649bd392xcd1bef483bd00eed@mail.gmail.com> On 7/7/07, Dzonatas wrote: > > His strikes were not to hurt himself. His strikes were to relieve pain > and make improvements. > There is a lot of BDSM group that can profide support in SL, heh. written by Cicero in 45 BC : "But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful. Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure?" -- kerunix Flan From josh at lindenlab.com Fri Jul 6 17:47:27 2007 From: josh at lindenlab.com (Joshua Bell) Date: Fri Jul 6 17:45:28 2007 Subject: [sldev] 1.17.3 Source now available Message-ID: <468EE29F.3090203@lindenlab.com> It was posted earlier today on the Wiki, but mail wasn't sent: http://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.3.0 Have at it! From dzonatas at dzonux.net Fri Jul 6 19:07:38 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 6 19:07:07 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer Message-ID: <468EF56A.9000400@dzonux.net> In order to improve the quality of textures without an increase in cost on the sims, we need to use P2P Web textures. Steps required*: 1. A mod in the viewer that enables lossless compression for image uploads. 2. A mod on the sim server to *prevent* image downloads of those images that have greater quality than lossy formats. (This would only be a prevention, not to disable the ability completely.) 3. If the extra prim parameter (https://jira.secondlife.com/browse/SVC-350) can't be used for this, a mod in the sim to support viewer redirection to a torrent tracker. (not the entire http address) 4. A mod in the viewer to support P2P torrents. 5. An external site to host the default torrents, and a fallback to collect data from the sim for images that are not stored on the host or found over DHT. (This may override the prevention in #2.) 6. A mod in a viewer to try to download all textures via the P2P method *first* from the tracker(s) found in #3, or a possible default list of trackers if the prim parameter doesn't redirect, before it fallbacks to get the texture from the sim itself. 7. If the viewer is not privilege to override the prim parameter (in #3), then "missing texture" texture is displayed on the attempt to download when it can't find the texture via P2P trackers. 8. A special login account status (like a daemon) that allows trackers to login SL to request/download textures normally that would be prevented from download by a regular viewer account. *NOTE: These are just basic steps involved subject to change. -- Power to Change the Void From dale at daleglass.net Fri Jul 6 19:27:56 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Fri Jul 6 19:28:00 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <468EF56A.9000400@dzonux.net> References: <468EF56A.9000400@dzonux.net> Message-ID: <20070707022756.GA3868@bruno.sbruno> On Fri, Jul 06, 2007 at 07:07:38PM -0700, Dzonatas wrote: > In order to improve the quality of textures without an increase in cost > on the sims, we need to use P2P Web textures. Hmm, what for? Textures seem to look very good to me. Maybe you could post a comparison of textures that look ugly due to compression? [snip] > 8. A special login account status (like a daemon) that allows trackers > to login SL to request/download textures normally that would be > prevented from download by a regular viewer account. > > *NOTE: These are just basic steps involved subject to change. Now, textures over P2P sounds interesting, but potentially troublesome. You need to ensure integrity by say, having LL run the trackers, or you risk people serving the wrong stuff. Practical problems: 1. How do you find a tracker to request the image from? The full DB would be ENORMOUS, so it can't be all in one place. And a single tracker couldn't handle the load. 2. Which files get hosted in which tracker? Let's say there's a tracker per sim, that seems to be a possible option. But this has problems. 3. Even with a sim per tracker, are current trackers able to handle a workload where lots of small files get posted? This may not be a huge problem, and I don't have a deep understanding of BitTorrent, but AFAIK, it's made for large amounts of data. Lots of small files might be suboptimal. Privacy problem: Alice comes to sim. Mallory has some sort of problem with Alice. Mallory wants to find Alice's IP address. It's simple: 1. Mallory creates a new texture and uploads it 2. Then he sets it on some object, maybe his own avatar 3. Since the texture is new, there are 2 places with it: the sim, and Mallory. 4. Alice starts trying to download the texture. Mallory now only has to see who else is on the tracker. Sure, you can trick people to go to websites where you can check the logs, or set a stream to something you control, but the first isn't automatic, and the second requires control of a parcel and enabled streaming. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/f1501acc/attachment.pgp From labrat.hb at gmail.com Fri Jul 6 19:44:30 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Jul 6 19:44:33 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <20070707022756.GA3868@bruno.sbruno> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> Message-ID: Alice comes to sim. Mallory has some sort of problem with Alice. Mallory wants to find Alice's IP address. It's simple: Mallory just uses the the Parcel Media Stream to set a specific URL call for Alice and gets her IP without any fuss or muss or any changes to the current SL codebase.... as long as Alice isn't on Linux. Yes the whole "But your IP wouldn't be safe" is a straw-man arguement. People can already get your IP address and tie it to an Avatar now. There's also the option of open a web service like SLExchange, SLBoutiqe, Apez, etc. etc. Every one of those sites has access to IP's tied to specific Avatar names. On 7/6/07, dale@daleglass.net wrote: > > Privacy problem: > > Alice comes to sim. Mallory has some sort of problem with Alice. Mallory > wants to find Alice's IP address. It's simple: > > 1. Mallory creates a new texture and uploads it > 2. Then he sets it on some object, maybe his own avatar > 3. Since the texture is new, there are 2 places with it: the sim, and > Mallory. > 4. Alice starts trying to download the texture. Mallory now only has to > see who else is on the tracker. > > Sure, you can trick people to go to websites where you can check the > logs, or set a stream to something you control, but the first isn't > automatic, and the second requires control of a parcel and enabled > streaming. > > > > _______________________________________________ > 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/20070706/d48b0718/attachment.htm From odysseus654 at gmail.com Fri Jul 6 19:51:53 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Fri Jul 6 19:51:54 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <20070707022756.GA3868@bruno.sbruno> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> Message-ID: <1674f6c70707061951h7f452261k8b22ed938fd6e3dd@mail.gmail.com> A quick couple comments. The whole "IP address spying" is always going to be an issue when dealing with external stores. There have been a couple attempts to resolve this (take a look at the MP3 obfuscating filesharing clients). It is very difficult to serve the "wrong" image via BitTorrent, the "link" that you are given when told to begin downloading it contains numerous hashes of the file that would discard any bad data. This may have changed since I read this, but there have been numerous requests to the people that run Debian Linux to move their package system to BitTorrent. Their response is that the packages are so small that the torrent system would not be optimized for retrieving them; the time it takes to establish the connection to the torrent would cause too much of a performance hit. I'm also a bit worried about people that don't want P2P connections on their network. University campuses may not be too happy about it (MP3 sharing again?) and an early version of Uru had a number of complaints lodged against it for its use of P2P to handle voicechat. On 7/6/07, dale@daleglass.net wrote: > > On Fri, Jul 06, 2007 at 07:07:38PM -0700, Dzonatas wrote: > > In order to improve the quality of textures without an increase in cost > > on the sims, we need to use P2P Web textures. > > Hmm, what for? Textures seem to look very good to me. Maybe you could > post a comparison of textures that look ugly due to compression? > > [snip] > > 8. A special login account status (like a daemon) that allows trackers > > to login SL to request/download textures normally that would be > > prevented from download by a regular viewer account. > > > > *NOTE: These are just basic steps involved subject to change. > > Now, textures over P2P sounds interesting, but potentially troublesome. > You need to ensure integrity by say, having LL run the trackers, or you > risk people serving the wrong stuff. > > Practical problems: > > 1. How do you find a tracker to request the image from? The full DB > would be ENORMOUS, so it can't be all in one place. And a single tracker > couldn't handle the load. > > 2. Which files get hosted in which tracker? Let's say there's a tracker > per sim, that seems to be a possible option. But this has problems. > > 3. Even with a sim per tracker, are current trackers able to handle a > workload where lots of small files get posted? This may not be a huge > problem, and I don't have a deep understanding of BitTorrent, but AFAIK, > it's made for large amounts of data. Lots of small files might be > suboptimal. > > > Privacy problem: > > Alice comes to sim. Mallory has some sort of problem with Alice. Mallory > wants to find Alice's IP address. It's simple: > > 1. Mallory creates a new texture and uploads it > 2. Then he sets it on some object, maybe his own avatar > 3. Since the texture is new, there are 2 places with it: the sim, and > Mallory. > 4. Alice starts trying to download the texture. Mallory now only has to > see who else is on the tracker. > > Sure, you can trick people to go to websites where you can check the > logs, or set a stream to something you control, but the first isn't > automatic, and the second requires control of a parcel and enabled > streaming. > > > > _______________________________________________ > 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/20070706/4ed16e4c/attachment-0001.htm From dale at daleglass.net Fri Jul 6 19:54:09 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Fri Jul 6 19:54:15 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> Message-ID: <20070707025409.GB3868@bruno.sbruno> On Fri, Jul 06, 2007 at 07:44:30PM -0700, Harold Brown wrote: > Mallory just uses the the Parcel Media Stream to set a specific URL call for > Alice and gets her IP without any fuss or muss or any changes to the current > SL codebase.... as long as Alice isn't on Linux. I already mentioned that, it works perfectly fine on Linux with an audio stream. Differences: 1. You can have it disabled without losing anything terribly important. 2. If somebody abuses it, it'd be easy enough to create a whitelist Neither of those will work with textures, as it'll be automatic, without warning, and impossible to disable unless you want to see grey everywhere. > Yes the whole "But your IP wouldn't be safe" is a straw-man arguement. > People can already get your IP address and tie it to an Avatar now. Crucial differences: Currently you can prevent it, and it doesn't give everybody the ability to automatically determine who you are. > There's also the option of open a web service like SLExchange, SLBoutiqe, > Apez, etc. etc. Every one of those sites has access to IP's tied to > specific Avatar names. Again, you don't have to use it. And it's not automatic. And you can SSH into some other box and check it from there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/7ec19ec5/attachment.pgp From dale at daleglass.net Fri Jul 6 20:00:36 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Fri Jul 6 20:00:42 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <1674f6c70707061951h7f452261k8b22ed938fd6e3dd@mail.gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <1674f6c70707061951h7f452261k8b22ed938fd6e3dd@mail.gmail.com> Message-ID: <20070707030036.GC3868@bruno.sbruno> On Fri, Jul 06, 2007 at 07:51:53PM -0700, Erik Anderson wrote: > It is very difficult to serve the "wrong" image via BitTorrent, the "link" > that you are given when told to begin downloading it contains numerous > hashes of the file that would discard any bad data. What I mean is that unless LL hosts the tracker, there's nothing stopping the one running it from hosting a file with the right name, but the wrong content. Obviously announced with the correct checksums and all. This is the same problem as what people propose taking advantage of when they discuss "P2P backups": Take your stuff, encrypt it, call it "porn.zip" and wait for it to be replicated. > This may have changed since I read this, but there have been numerous > requests to the people that run Debian Linux to move their package system to > BitTorrent. Their response is that the packages are so small that the > torrent system would not be optimized for retrieving them; the time it takes > to establish the connection to the torrent would cause too much of a > performance hit. My thoughts exactly -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/69979678/attachment.pgp From kamilion at gmail.com Fri Jul 6 21:39:36 2007 From: kamilion at gmail.com (Kamilion) Date: Fri Jul 6 21:39:39 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <20070707030036.GC3868@bruno.sbruno> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <1674f6c70707061951h7f452261k8b22ed938fd6e3dd@mail.gmail.com> <20070707030036.GC3868@bruno.sbruno> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Have you considered aggregating a full linked object's load of textures into a single torrent? It would be trivial to simply request .torrent which contains all the pertinent texture, animation, and sound assets associated with the object instead of requesting them all individually. Considering that LL is already hosting the assets, Adding a custom torrent tracker and torrent client into the asset server should be able to force the user's client to connect to the asset torrent client as the first peer, and THEN pick up third party peers. Also, since most torrent client and tracker code is open sourced, it would be trivial to fork and then clip out all the 'unneeded' bits. Additionally, most modern torrent clients can scrape peers from multiple trackers at the same time. However, there is already a much much better way of performing these functions -- since the assets should be served via HTTP soon, Squid should be able to transparently cache the assets on a more local server and skip requesting from the LL asset grid entirely. Remember: Assets never change; any modification of an existing asset forces the creation of a new asset. -- Kamilion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://firegpg.tuxfamily.org iD8DBQFGjxjt+Hm92PVlrtQRAmoCAJ9kwnawIrokUPYHrQCi/9O8BHUSDwCgoeI9 AEX6LeTpFlm9i9INuC4DJdg= =zG2L -----END PGP SIGNATURE----- On 7/6/07, dale@daleglass.net wrote: > On Fri, Jul 06, 2007 at 07:51:53PM -0700, Erik Anderson wrote: > > This may have changed since I read this, but there have been numerous > > requests to the people that run Debian Linux to move their package system to > > BitTorrent. Their response is that the packages are so small that the > > torrent system would not be optimized for retrieving them; the time it takes > > to establish the connection to the torrent would cause too much of a > > performance hit. > My thoughts exactly From kerdezixe at gmail.com Fri Jul 6 21:57:25 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jul 6 21:57:27 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <1674f6c70707061951h7f452261k8b22ed938fd6e3dd@mail.gmail.com> <20070707030036.GC3868@bruno.sbruno> Message-ID: <8a1bfe660707062157n49c49b18l17fa041fd89717cc@mail.gmail.com> On 7/7/07, Kamilion wrote: > > However, there is already a much much better way of performing these > functions -- since the assets should be served via HTTP soon, Squid > should be able to transparently cache the assets on a more local > server and skip requesting from the LL asset grid entirely. Yup, i hope to able to do that, my own local cache of texture with a good performance squid and a descent filesystem (not my actual NTFS and the SL texture cache). and any proxyfication could be very nice for company using SL in office as a tool. -- kerunix Flan From gigstaggart at gmail.com Sat Jul 7 02:36:15 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jul 7 02:36:39 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> Message-ID: <468F5E8F.3040406@gmail.com> Harold Brown wrote: > > Yes the whole "But your IP wouldn't be safe" is a straw-man arguement. > People can already get your IP address and tie it to an Avatar now. I agree 100%. This argument has already been used to stifle the discussion of (non-P2P) web fetched textures with irrelevancies about IP address exposure. Making the privacy of an IP address a priority paralyzes Second Life into a centralized paradigm, making Linden Lab something more like a horribly inefficient, centralized version of Akamai. If these "chicken littles" had their way years ago, we wouldn't have parcel audio and video streaming, and we wouldn't have a live music community. -Jason From kerdezixe at gmail.com Sat Jul 7 03:13:00 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Jul 7 03:13:02 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <468F5E8F.3040406@gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> Message-ID: <8a1bfe660707070313n3baf96c7wbfe4feb1e8684f1@mail.gmail.com> On 7/7/07, Jason Giglio wrote: > Harold Brown wrote: > > > > Yes the whole "But your IP wouldn't be safe" is a straw-man arguement. > > People can already get your IP address and tie it to an Avatar now. > > I agree 100%. This argument has already been used to stifle the > discussion of (non-P2P) web fetched textures with irrelevancies about IP > address exposure. > > Making the privacy of an IP address a priority paralyzes Second Life > into a centralized paradigm, making Linden Lab something more like a > horribly inefficient, centralized version of Akamai. > > If these "chicken littles" had their way years ago, we wouldn't have > parcel audio and video streaming, and we wouldn't have a live music > community. Same problem with website, audio streaming, video streaming, and everything on internet. As 99% of my residents in my sims are french i'd love to be able to host all the textures used to build the sim on one of my french dedicated servers, for performance (maybe LL asset servers are huge monster with billions of transaction a day, but what the end-user have is just poor performance). It's dirt cheap if you compare with the cost of a sim. so i don't mind paying some dedicated servers to host texture for my 23 sims. I have... what... 100MB of texture max, let's say 1GB just for fun ? Pfft... nothing. Bandwidth ? i have 3x100Mbps and all that for less than the cost of a private island. (and just because i'm a techno-nerdo-geeky i'd love to host external texture just for the fun of running and tunning high performance, high availabilty, servers... it's my main job and i like it) But i don't like the idea of P2P. (and company running SL in their office will hate it) -- kerunix Flan From dale at daleglass.net Sat Jul 7 06:02:10 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sat Jul 7 06:02:15 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <468F5E8F.3040406@gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> Message-ID: <20070707130209.GD3868@bruno.sbruno> On Sat, Jul 07, 2007 at 05:36:15AM -0400, Jason Giglio wrote: > Harold Brown wrote: > > > >Yes the whole "But your IP wouldn't be safe" is a straw-man arguement. > >People can already get your IP address and tie it to an Avatar now. > > I agree 100%. This argument has already been used to stifle the > discussion of (non-P2P) web fetched textures with irrelevancies about IP > address exposure. Why irrelevancies? I find it very relevant. > If these "chicken littles" had their way years ago, we wouldn't have > parcel audio and video streaming, and we wouldn't have a live music > community. Like I repeatedly said already (and you seem to insist on ignoring), there's one big difference: I can choose not to click random website links, or not use streaming if I want to. I have absolutely no problem with things that are *optional* for me to use. Audio streams can only be set if you control the parcel, too. You can't simply show up anywhere on the grid and do something that lets you have everybody's IP address. I can't however realistically choose not to load textures. > > -Jason > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/d0d222df/attachment.pgp From kfa at gmx.net Sat Jul 7 06:26:05 2007 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Jul 7 06:25:59 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer In-Reply-To: <200707040841.50712.morris1@ix.netcom.com> References: <468B72CA.5030403@gmx.net> <200707040841.50712.morris1@ix.netcom.com> Message-ID: <468F946D.2010107@gmx.net> You mean you downgraded ;) Oh well. I'm not sure how many people still use Win2k or if support for it will be knocked off eventually. I've seen nobody vote for the issue, so I gather it's not that important. Thanks for replying, Cheers morris wrote: > I had the same problem and reported it as a bug with Win2K since I have other > systems running XP and Vista and they worked ok. I tested this also with > another Win2K system and it failed. I have since upgraded the original Win2K > machine to Vista and the microphone works ok with no other changes. > Morris Ford > > On Wednesday 04 July 2007 03:13, Felix Duesenburg wrote: > >> Dear @, >> >> Not sure if it's appropriate to turn to the list for attention grabbing, >> but I've been posting this issue for a while now and there doesn't seem >> to be anybody picking it up: >> >> https://jira.secondlife.com/browse/VWR-1183 >> >> Please somebody let me know if the information provided is insufficient >> or the description unclear. >> >> Thanks! >> >> Felix >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From gigstaggart at gmail.com Sat Jul 7 06:25:38 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jul 7 06:26:03 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <20070707130209.GD3868@bruno.sbruno> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> <20070707130209.GD3868@bruno.sbruno> Message-ID: <468F9452.1080503@gmail.com> dale@daleglass.net wrote: > I can't however realistically choose not to load textures. You can choose not to use the Internet if you are afraid of people hosting content getting your IP address. From dale at daleglass.net Sat Jul 7 07:00:18 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sat Jul 7 07:00:23 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <468F9452.1080503@gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> <20070707130209.GD3868@bruno.sbruno> <468F9452.1080503@gmail.com> Message-ID: <20070707140018.GE3868@bruno.sbruno> On Sat, Jul 07, 2007 at 09:25:38AM -0400, Jason Giglio wrote: > >I can't however realistically choose not to load textures. > > You can choose not to use the Internet if you are afraid of people > hosting content getting your IP address. Sheesh, it's not a black or white sort of thing. And it's not my IP address I'm concerned about, it's the sum of information about me. My IP address on some random website's log is unimportant. If I don't want them to have anything at all, I just use tor. My IP address, plus knowledge of who I am and what I do, etc, that's what I consider rather too much info. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/9d1388c7/attachment-0001.pgp From matthew.dowd at hotmail.co.uk Sat Jul 7 07:01:02 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 7 07:01:03 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer Message-ID: > Oh well. I'm not sure how many people still use Win2k or if support for > it will be knocked off eventually. I've seen nobody vote for the issue, > so I gather it's not that important. Jira voting is not a good measure of support. Take my suggestion here: https://jira.secondlife.com/browse/SVC-376 it has 4 votes, however, the forum poll I created to initial gauge interest has 126 votes for it (and 31 against). Matthew _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From dzonatas at dzonux.net Sat Jul 7 07:12:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 07:11:37 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 Message-ID: <468F9F39.4060707@dzonux.net> First, let me reply to a few questions in summary here: * Image Quality On a questions about image quality comparisons, this is highly noticeable with sculpties that have the slightest artifact of difference. Higher quality images are not just about visible textures that go on the face a prim. * Static Transfer Rates, Bandwdith, and Lag On top of that is the cost, I believe people understand the cost of per GB that remote storage and colocation facilities charge. Besides that, there is also the immense bandwidth increase with larger images, so we also want to reduce the cost of server lag. For these reasons, the sim network can only be seen as a fallback rather than a primary resource to acquire the images. * Squid &. P2P torrents I did forget to jot down about Squid, but I did remember to put the "web" in between "p2p WEB textures." To make it clearer, I change the title of this to "P2P/Squid Web Textures." Squid is not a drop-in solution from what has been found/tested so far. It works well in some situations and horrible in others. I'm thinking a shallow Squid that is P2P enabled to connect to others like Squids will be the best solution. The Squid would be able to determine if a P2P connection or a http redirect (to another Squid) is the best optimal route. It would be a custom solution, so there is no way to immediately use Squid as-is. It can help avoid sim and viewer changes, however. Main advantage here is the ability/potential to transfer smaller images faster without the bottleneck of torrent initialization. Main disadvantage: facilities like Amazon S3 only support P2P and can't do a custom squid. * P2P Viewer-Side & Security Obvious, the P2P option on the viewer side has to be optional. To enable P2P in the viewer is probably the easier solution, but not everyone will be able to use it. For those that can't use P2P in the viewer, they would have to override all request to the Squid texture server address. As for IP addresses, we could enable Tor, but I doubt it is really needed just to enable higher quality images. * Aggregation/Combined Textures Yep. This has been thought about in many ways. The sim server could currently patch tiles of images together and send them as one, but from what I gather this kind of option just won't happen on the sim level. It doesn't appear to be about process time, as it appears more about lag and that the sim network shouldn't be dealing directly with textures like they are now. The feature to combine textures together is a gain for optimal performance, especially over P2P. It is of lower-priority, however. * P2P Scrapes/DHT If there was a way to filter out non-SL users from scrapes and the DHT, this would help optimize torrents that are smaller in size. It's an idea, but I'd mark it down as lower-priority. +++ There has already been some work done (or has been available) on the sim side. For the proof-of-concept stage, we don't need to make any sim side changes. In the future, special accounts can help the sim optimize the connection for daemons or provide an optional level of security. A quick update to the steps without sim changes: In order to improve the quality of textures without an increase in cost on the sims, we need to use P2P Web textures. Steps required*: 1. A mod in the viewer that enables lossless compression for image uploads. 2. Optional use of the extra prim parameter (https://jira.secondlife.com/browse/SVC-350), to help redirect the viewer to Squid addresses or torrent trackers rather than the defaults. 3. A mod in the viewer to support P2P torrents -- made optional -- and default to Squid addresses. 4. An external site to host the default torrents, and a fallback to collect data from the sim for images that are not stored on the host Squid or found over DHT (if enabled). 5. A mod in a viewer to try to download all textures via the P2P/Squid method *first* from #4 *NOTE: These are just basic steps involved subject to change. The other steps posted in the previous version help insure there won't be an extra cost hit on the sim network, so these were taken out to narrow the above list. What else needs to change before we fill-in the details? -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070707/548737d2/attachment.htm From dale at daleglass.net Sat Jul 7 07:33:59 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sat Jul 7 07:34:06 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <468F9F39.4060707@dzonux.net> References: <468F9F39.4060707@dzonux.net> Message-ID: <20070707143358.GF3868@bruno.sbruno> On Sat, Jul 07, 2007 at 07:12:09AM -0700, Dzonatas wrote: > First, let me reply to a few questions in summary here: > > * Image Quality > On a questions about image quality comparisons, this is highly > noticeable with sculpties that have the slightest artifact of > difference. Higher quality images are not just about visible textures > that go on the face a prim. But scuplties use really tiny textures. You could simply get LL to make an exception for 64x64 textures. At 16 bit color, uncompressed, that's just 8K. You could not compress it at all. I don't think BitTorrent, or nearly any other P2P system for that matter will work well for files that small. You'll probably have more protocol overhead than data transferred. Other than sculpties, I'd say pretty much everything looks almost as good as possible. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/b65bf321/attachment.pgp From dzonatas at dzonux.net Sat Jul 7 08:05:50 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 08:05:15 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <20070707143358.GF3868@bruno.sbruno> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> Message-ID: <468FABCE.80109@dzonux.net> dale@daleglass.net wrote: > But scuplties use really tiny textures. You could simply get LL to make > an exception for 64x64 textures. At 16 bit color, uncompressed, that's > just 8K. You could not compress it at all. > Internally (in the viewer), all images are converted to 32 bit. Uncompressed, that would be at least 130k. Sculpties use the full 8 bit RGB values, and there is discussion on how to use the alpha channel as well. There are artist that have asked for lossless detail on their images. It sounds as if that is how they want to do their business. It is beyond just scuplties. Nevertheless, there is the overhead to transfer images (even at 8k) through the sim network with UDP or TCP. All of that can be moved externally to reduce server lag. More images added to the sim network mean more chances of lag. Consider that another continent is now under way, there will be more textures on the network even if they are just 64x64 sculpties. We can reduce this traffic. There is no magic to distinguish a sculptie image from another texture image, as it doesn't exist. While we could just enable lossless uploads right now with a flick of a switch, that would mean there is no immediate way to stop people from uploading lossless 1024x1024 images. I rather not have this implementation be the cause as for why everybody's tier rate would increase. Even though it is possible right now directly with the sim, a cache that is external to the sim is more practical. -- Power to Change the Void From nicholaz at blueflash.cc Sat Jul 7 08:17:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jul 7 08:17:37 2007 Subject: [sldev] SSE/Vector stuff Message-ID: <468FAE83.6060505@blueflash.cc> Did anyone notice the changes about SSE optimization in the 1.17.3 viewer? I have not looked at them yet, but I've seen comments on my blog (and Linden blog also) that 1.17.3 was slow (e.g. with flexi prims) and that stuff is the only I've seen in the source diff that could account for that. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From blakar at gmail.com Sat Jul 7 08:25:16 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jul 7 08:25:19 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <468FAE83.6060505@blueflash.cc> References: <468FAE83.6060505@blueflash.cc> Message-ID: <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> Is it enabled? There's SSE stuff in 1.18.0.4 too but I don't think it's on by default. Dirk aka Blakar Ogre On 7/7/07, Nicholaz Beresford wrote: > > Did anyone notice the changes about SSE optimization > in the 1.17.3 viewer? I have not looked at them yet, > but I've seen comments on my blog (and Linden blog also) > that 1.17.3 was slow (e.g. with flexi prims) and that > stuff is the only I've seen in the source diff that could > account for that. > > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dale at daleglass.net Sat Jul 7 08:33:24 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sat Jul 7 08:33:30 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <468FABCE.80109@dzonux.net> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FABCE.80109@dzonux.net> Message-ID: <20070707153324.GG3868@bruno.sbruno> On Sat, Jul 07, 2007 at 08:05:50AM -0700, Dzonatas wrote: > dale@daleglass.net wrote: > >But scuplties use really tiny textures. You could simply get LL to make > >an exception for 64x64 textures. At 16 bit color, uncompressed, that's > >just 8K. You could not compress it at all. > > > Internally (in the viewer), all images are converted to 32 bit. > Uncompressed, that would be at least 130k. Sculpties use the full 8 bit > RGB values, and there is discussion on how to use the alpha channel as well. Huh? That's some bad math there. A 64x64 image has 64 * 64 = 4096 pixels. 16 bit color is 2 bytes per pixel, in 555 or 565 format (doesn't matter which), so 8K. 32 bit color is 4 bytes per pixel, 8 bits for each of R, G, B, A. That's 16K. ATM, I think textures as small as 16K wouldn't amount to much bandwidth at all. Most textures I see around are a lot larger. > There are artist that have asked for lossless detail on their images. It > sounds as if that is how they want to do their business. It is beyond > just scuplties. Fair enough, but in that case I'd like to see comparison images. First we see what it looks like, and based on that we could see what could be done. Other possiblities include tweaking compression quality, or allowing uncompressed uploads but charging more for them. > Nevertheless, there is the overhead to transfer images (even at 8k) > through the sim network with UDP or TCP. All of that can be moved > externally to reduce server lag. More images added to the sim network > mean more chances of lag. Consider that another continent is now under > way, there will be more textures on the network even if they are just > 64x64 sculpties. We can reduce this traffic. IMO, if you want to reduce bandwidth usage that's a very good goal to have, but the logical thing would be to start from the BIG things, not from the tiny ones. For example, how about *reducing* quality? Make the price dependent on texture size and compression quality. This would give the people an incentive to avoid upload things that are larger than necessary. > There is no magic to distinguish a sculptie image from another texture > image, as it doesn't exist. While we could just enable lossless uploads > right now with a flick of a switch, that would mean there is no > immediate way to stop people from uploading lossless 1024x1024 images. I > rather not have this implementation be the cause as for why everybody's > tier rate would increase. Even though it is possible right now directly > with the sim, a cache that is external to the sim is more practical. Sure there is: image size. There's no reason why you couldn't accept uncompressed images only up to 64x64. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/6359881c/attachment.pgp From nicholaz at blueflash.cc Sat Jul 7 09:03:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jul 7 09:03:31 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> Message-ID: <468FB947.8060908@blueflash.cc> From what I saw it does a test run with and without at the beginning and then saves an option. Dunno if that option is buried in the debug menus somewhere, I was just looking at the source diffs. But the regular log should show a few new entries about "Vector" ... Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dirk Moerenhout wrote: > Is it enabled? There's SSE stuff in 1.18.0.4 too but I don't think > it's on by default. > > Dirk aka Blakar Ogre > > On 7/7/07, Nicholaz Beresford wrote: >> >> Did anyone notice the changes about SSE optimization >> in the 1.17.3 viewer? I have not looked at them yet, >> but I've seen comments on my blog (and Linden blog also) >> that 1.17.3 was slow (e.g. with flexi prims) and that >> stuff is the only I've seen in the source diff that could >> account for that. >> >> >> Nick >> >> -- >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> From dzonatas at dzonux.net Sat Jul 7 09:05:10 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 09:04:35 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <20070707153324.GG3868@bruno.sbruno> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FABCE.80109@dzonux.net> <20070707153324.GG3868@bruno.sbruno> Message-ID: <468FB9B6.8020700@dzonux.net> dale@daleglass.net wrote: > Huh? That's some bad math there. > LOL, i was counting bitplanes instead of bytes. My bad. > First we see what it looks like, and based on that we could see what > could be done. Other possiblities include tweaking compression quality, > or allowing uncompressed uploads but charging more for them. > Even if there is an extra charge, it still doesn't immediately help the sim network performance. > > IMO, if you want to reduce bandwidth usage that's a very good goal to > have, but the logical thing would be to start from the BIG things, not > from the tiny ones. > > For example, how about *reducing* quality? Make the price dependent on > texture size and compression quality. This would give the people an > incentive to avoid upload things that are larger than necessary. > That has been suggested for awhile even by LL. It would be another sim-side change... more things to support... more work piled on LL. > There's no reason why you couldn't accept uncompressed images only up to > 64x64. > Thought about that, also. It still doesn't reduce cost on the sim network, and it would be another sim-side change. How do we avoid sim-side changes until they are actually needed? Is there anything to prevent the steps being done externally? -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070707/24ec1874/attachment.htm From dale at daleglass.net Sat Jul 7 09:26:05 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sat Jul 7 09:26:10 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <468FB9B6.8020700@dzonux.net> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FABCE.80109@dzonux.net> <20070707153324.GG3868@bruno.sbruno> <468FB9B6.8020700@dzonux.net> Message-ID: <20070707162604.GH3868@bruno.sbruno> On Sat, Jul 07, 2007 at 09:05:10AM -0700, Dzonatas wrote: > >First we see what it looks like, and based on that we could see what > >could be done. Other possiblities include tweaking compression quality, > >or allowing uncompressed uploads but charging more for them. > > > > Even if there is an extra charge, it still doesn't immediately help the > sim network performance. Ok, but let's not confuse issues here. If you want quality, then let's do quality: Get people to submit images for comparison. AFAIK, JPEG 2000 has a configurable quality level, just as the usual JPEG. This probably can be tweaked without any server changes. Then we can do tests, and judge the results based on quality. IMO it's meaningless to talk about the quality of something without providing any proof of it. If you want network performance, then let's talk about that as well, but in that case it's weird to consider things like sculpties at all, as they're really tiny in comparison to everything else. Here we should be talking about 1024x1024 textures instead. Just one of them is 256 times larger than a 64x64 sculptie texture. > > > > >IMO, if you want to reduce bandwidth usage that's a very good goal to > >have, but the logical thing would be to start from the BIG things, not > >from the tiny ones. > > > >For example, how about *reducing* quality? Make the price dependent on > >texture size and compression quality. This would give the people an > >incentive to avoid upload things that are larger than necessary. > > > That has been suggested for awhile even by LL. It would be another > sim-side change... more things to support... more work piled on LL. Why server change? Charging for textures is actually client-side IIRC. Compression is client-side. It can really be done without involving the grid at all, unless there's something server-side that checks that the texture has been uploaded with specific parameters. > > >There's no reason why you couldn't accept uncompressed images only up to > >64x64. > > > > Thought about that, also. It still doesn't reduce cost on the sim > network, and it would be another sim-side change. Assuming there's anything at all server-side, it'be tiny. Patching something like: if (image.isLossless()) reject(); To something like: if (image.isLossless && image.width > 64 && image.height > 64) reject(); This is overly simplistic of course, but I doubt it'd require anything very complicated server-side. > > How do we avoid sim-side changes until they are actually needed? Is > there anything to prevent the steps being done externally? But P2P will require server-side changes as well. Who will run the tracker for instance? You will need LOTS of them to cope with the load SL currently has. This can't be something running from a cheap box in somebody's basement, and I doubt a single box could handle it (not to mention reliability problems). IMO, P2P would need to be organized by LL, with a server-side tracker. Which means sim-side changes. > > > -- > Power to Change the Void -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/876ef19d/attachment.pgp From blakar at gmail.com Sat Jul 7 09:49:08 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jul 7 09:49:11 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <468FB947.8060908@blueflash.cc> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> Message-ID: <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> Output of 1.17.3.0 2007-07-07T16:30:19Z INFO: update_vector_performances: Vectorization : ENABLED 2007-07-07T16:30:19Z INFO: update_vector_performances: Vector Processor : SSE2 2007-07-07T16:30:19Z INFO: update_vector_performances: Vectorized Skinning : ENABLED Output from my test 1.18.0.4 build: 2007-07-07T16:38:27Z INFO: update_vector_performances: Vectorization : ENABLED 2007-07-07T16:38:27Z INFO: update_vector_performances: Vector Processor : SSE2 2007-07-07T16:38:27Z INFO: update_vector_performances: Vectorized Skinning : ENABLED BUT! If you check the source (llviewerjointmesh_sse.cpp and llviewerjointmesh_sse2.cpp) you'll find that if #LL_VECTORIZE is not defined SSE and SSE2 call the non-SSE version. In 1.18.0.4 it seems turned off by default. I guess same may apply to 1.17.3.0. So the log doesn't guarantee you you're actually using SSE. Dirk aka Blakar Ogre On 7/7/07, Nicholaz Beresford wrote: > > From what I saw it does a test run with and without > at the beginning and then saves an option. Dunno if > that option is buried in the debug menus somewhere, > I was just looking at the source diffs. But the > regular log should show a few new entries about > "Vector" ... > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Dirk Moerenhout wrote: > > Is it enabled? There's SSE stuff in 1.18.0.4 too but I don't think > > it's on by default. > > > > Dirk aka Blakar Ogre > > > > On 7/7/07, Nicholaz Beresford wrote: > >> > >> Did anyone notice the changes about SSE optimization > >> in the 1.17.3 viewer? I have not looked at them yet, > >> but I've seen comments on my blog (and Linden blog also) > >> that 1.17.3 was slow (e.g. with flexi prims) and that > >> stuff is the only I've seen in the source diff that could > >> account for that. > >> > >> > >> Nick > >> > >> -- > >> Second Life from the inside out: > >> http://nicholaz-beresford.blogspot.com/ > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > From tateru.nino at gmail.com Sat Jul 7 10:05:52 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jul 7 10:05:59 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <20070707143358.GF3868@bruno.sbruno> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> Message-ID: <468FC7F0.3080409@gmail.com> dale@daleglass.net wrote: > On Sat, Jul 07, 2007 at 07:12:09AM -0700, Dzonatas wrote: > >> First, let me reply to a few questions in summary here: >> >> * Image Quality >> On a questions about image quality comparisons, this is highly >> noticeable with sculpties that have the slightest artifact of >> difference. Higher quality images are not just about visible textures >> that go on the face a prim. >> > But scuplties use really tiny textures. You could simply get LL to make > an exception for 64x64 textures. At 16 bit color, uncompressed, that's > just 8K. You could not compress it at all. > > I don't think BitTorrent, or nearly any other P2P system for that matter > will work well for files that small. You'll probably have more protocol > overhead than data transferred. Several dozen times at least, and startup costs potentially exceeding one minute for many existing p2p systems. Even a well spread tiny file can take many minutes just to contact peers, send requests, find a peer/seed with the data that isn't already backlogged with requests, and actually get data back. P2P systems become increasingly efficient as file-sizes increase, with your sweet spot being about 15 peers/seeds per requester, and a file size that is about 10 blocks per peer/seed. Roughly. That's a bit back-of-the-envelope. -- Tateru Nino http://dwellonit.blogspot.com/ From dzonatas at dzonux.net Sat Jul 7 10:09:16 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 10:08:41 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> Message-ID: <468FC8BC.7000605@dzonux.net> Dirk Moerenhout wrote: > In 1.18.0.4 it seems turned off by default. I guess same may apply to > 1.17.3.0. So the log doesn't guarantee you you're actually using SSE. It is not really "turned off" unless the compiler default is to turn it off, so it is really the "compiler default." Whereas, the other settings are specific to SSE/SSE2. It runs the test once and saves the result. The test performs a render benchmark on avatar vertex skinner and determines to use LLV4 math or not. The test (Kudos to James for his idea on this!) avoids further look-up into processors features and bios settings along with more code to best suit each situation. The main issue that affects the SSE performance is the cache pollution, which is random on each machine. There is no best default setting at this time. -- Power to Change the Void From blakar at gmail.com Sat Jul 7 10:13:02 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jul 7 10:13:05 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> Message-ID: <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> I checked why my version won't use SSE and it might be related to the fact that I use my own adaptation of the solution files. In llv4math.h it checks for _M_IX86_FP which is a predefined macro that returns 0 if you enabled no SSE, 1 for SSE and 2 for SSE2. As I did not enable compiling SSE yet it'll return 0 and hence LL_VECTORIZE is not set. Strange thing is that as far as I know LL is still building using VS 2003 and VS 2003 does not have the _M_IX86_FP macro so even if you compile with /arch:SSE2 in VS2003 you'll not get SSE2 support. 1.17.3.0 is still build using VS2003 (linker version returned from exe is 7.1) so I guess you won't have SSE support regardless of whether they compiled with /arch:SSE2 or not. I'm also not completely convinced their approach is safe as relying on the macro outside the files that contain the actual SSE code means you must enable /arch:SSE2 for files that may end up having things translated into SSE for all platforms. As such your binary may no longer run on non-SSE enabled CPU's even though you thought it would. Dirk aka Blakar Ogre On 7/7/07, Dirk Moerenhout wrote: > Output of 1.17.3.0 > 2007-07-07T16:30:19Z INFO: update_vector_performances: Vectorization > : ENABLED > 2007-07-07T16:30:19Z INFO: update_vector_performances: Vector > Processor : SSE2 > 2007-07-07T16:30:19Z INFO: update_vector_performances: Vectorized > Skinning : ENABLED > > Output from my test 1.18.0.4 build: > 2007-07-07T16:38:27Z INFO: update_vector_performances: Vectorization > : ENABLED > 2007-07-07T16:38:27Z INFO: update_vector_performances: Vector > Processor : SSE2 > 2007-07-07T16:38:27Z INFO: update_vector_performances: Vectorized > Skinning : ENABLED > > BUT! > > If you check the source (llviewerjointmesh_sse.cpp and > llviewerjointmesh_sse2.cpp) you'll find that if #LL_VECTORIZE is not > defined SSE and SSE2 call the non-SSE version. > > In 1.18.0.4 it seems turned off by default. I guess same may apply to > 1.17.3.0. So the log doesn't guarantee you you're actually using SSE. > > Dirk aka Blakar Ogre > > On 7/7/07, Nicholaz Beresford wrote: > > > > From what I saw it does a test run with and without > > at the beginning and then saves an option. Dunno if > > that option is buried in the debug menus somewhere, > > I was just looking at the source diffs. But the > > regular log should show a few new entries about > > "Vector" ... > > > > > > Nick > > > > > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > > > > > Dirk Moerenhout wrote: > > > Is it enabled? There's SSE stuff in 1.18.0.4 too but I don't think > > > it's on by default. > > > > > > Dirk aka Blakar Ogre > > > > > > On 7/7/07, Nicholaz Beresford wrote: > > >> > > >> Did anyone notice the changes about SSE optimization > > >> in the 1.17.3 viewer? I have not looked at them yet, > > >> but I've seen comments on my blog (and Linden blog also) > > >> that 1.17.3 was slow (e.g. with flexi prims) and that > > >> stuff is the only I've seen in the source diff that could > > >> account for that. > > >> > > >> > > >> Nick > > >> > > >> -- > > >> Second Life from the inside out: > > >> http://nicholaz-beresford.blogspot.com/ > > >> _______________________________________________ > > >> Click here to unsubscribe or manage your list subscription: > > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > >> > > > From dzonatas at dzonux.net Sat Jul 7 10:43:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 10:42:45 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> Message-ID: <468FD0B9.3060800@dzonux.net> Dirk Moerenhout wrote: > Strange thing is that as far as I know LL is still building using VS > 2003 and VS 2003 does not have the _M_IX86_FP macro so even if you > compile with /arch:SSE2 in VS2003 you'll not get SSE2 support. ... Your right! It does say that here: http://msdn2.microsoft.com/en-us/library/e54ke6de(vs.80).aspx Thanks for pointing that out! I use VS2005 Express which of course the only thing I can afford at the time, so my docs defaulted to that version. My bad? Yep, I guess I deserve the street for that one...? Since it will auto-detect under VS2005, the workaround is to detect the compiler version (being VS2003) in the _sse and _sse2 files and set _M_IX86_FP accordingly before it includes any of the LLV4 headers. That should explain why some of the benchmarks came up negative even when it should be positive despite cache pollution. -- Power to Change the Void From dzonatas at dzonux.net Sat Jul 7 10:51:30 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 10:50:54 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <468FC7F0.3080409@gmail.com> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FC7F0.3080409@gmail.com> Message-ID: <468FD2A2.8020807@dzonux.net> Tateru Nino wrote: >> I don't think BitTorrent, or nearly any other P2P system for that matter >> will work well for files that small. You'll probably have more protocol >> overhead than data transferred. >> > Several dozen times at least, and startup costs potentially exceeding > one minute for many existing p2p systems. Even a well spread tiny file > can take many minutes just to contact peers, send requests, find a > peer/seed with the data that isn't already backlogged with requests, and > actually get data back. P2P systems become increasingly efficient as > file-sizes increase, with your sweet spot being about 15 peers/seeds per > requester, and a file size that is about 10 blocks per peer/seed. > Roughly. That's a bit back-of-the-envelope. > > That is an assumption that only bittorrent networks are being used for P2P. A simple http redirect could speed up web textures greatly while it reduces lag on the sim network. Besides a change to prevent greater costs on the sim-side, I still don't see a reason given why it can't be all viewer-side and/or on an external site, like Amazon S3 or Squids. I believe the proof itself is not just with the difference of image quality alone, but it is with the difference in cost. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070707/a66f162e/attachment.htm From simon.nolan at gaylifesl.com Sat Jul 7 14:42:33 2007 From: simon.nolan at gaylifesl.com (Simon Nolan) Date: Sat Jul 7 14:42:38 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <468FD2A2.8020807@dzonux.net> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FC7F0.3080409@gmail.com> <468FD2A2.8020807@dzonux.net> Message-ID: All this talk of Squids and Amazon S3 stores and Torrents is nice, but why? Each viewer instance already has a texture cache. Instead of mucking around with external services, can't our viewers just talk to each other and share the textures in our caches? Why do we need a tracker? If you're in a sim, you already have a list of others who have the textures that you need -- though I'm not sure about how to go about resolving that list of residents in a sim into P2P connections. The only use for external services/caches would be for when you're the only person in a sim, and that's usually when I *don't* have a problem with textures. Why are we talking about Torrents? It appears to be suboptimal for small files, particularly sculptie textures. Should we consider our own p2p protocol, or basing it on something that avoids the ramp-up issues (and avoiding "tit for tat") in BitTorrent? (And I think part of the reason Torrent keeps coming up is that's what was in Dzonatas' original post.) Since DSL and other internet services are asymmetric, if I go to a busy, complex sim, what's to prevent my uplink from becoming saturated with texture sharing, lagging my client because it can't squeeze in a message to the sim? Why do we need lossless textures for anything except sculpties? Not to sound like I'm saying, "Textures are good enough for me, and dog- gone it, they're good enough for you," but really, the textures I upload look fine. The only problem I have is not that they're lossy- compressed, but that they're not big enough. I can easily see pixels on low-resolution textures on large objects, and even some not-so- large objects. It has nothing at all to do with compression. Honestly, though, I'm not crazy bout lagging my viewer client-side with huge textures, regardless of where they're downloaded from. Dzonatas said that artists want lossless compression for their work, but I wonder if they're double-compressing their images on upload. Do they save them as JPEG from their image editor, then upload them which compresses them again? I only ever upload Targas so that there's only one round of lossy compression, and I get excellent results. In all honesty, I'm not sure that P2P and larger/lossless images need be tied together. In fact, if we could just get web textures, then people would be free to host their own Squid caches with Dijjer enabled and off we go. Of course, if someone stops paying their hosting fees, their stuff goes buh-bye. LL-hosted textures would then benefit from a custom client-side P2P that shares textures between residents visiting the same sim. From dzonatas at dzonux.net Sat Jul 7 15:12:36 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 7 15:12:00 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FC7F0.3080409@gmail.com> <468FD2A2.8020807@dzonux.net> Message-ID: <46900FD4.6090703@dzonux.net> I originally jotted down the ideas based on a collection full of talk and data. I thought I was pretty darn clear about "subject to change." Yes, torrents are mentioned but it does not have to be BitTorrent; however, it would be easier to use something that already exists just to get the proof-of-concept done before we roll our own. BitTorrent uses connectionless transfers and peer discovery. That by itself is the main reason why it is slow to initiate transfers. If it kept active connections of peers, it would be much quicker without initial transfer time slowdown. There should be an option who stays active and who doesn't gets treated like normal BitTorrent client. Everybody else without a client uses the http method to get files. This can all be combine into a Squid cache. It would be nice to have one viewer connect directly to another. It would be easier to allow these viewers to talk to a Squid to find out who has just seen certain textures recently in order to get the textures from them, if it is enabled on those viewers. That way, even if a ton of people aren't in the same sim can still access the tracker to find the texture. Remember, we can make these things optional. Why don't we just put an apache server into the viewer, then we can just simply http redirect viewers that don't have a texture to viewers that do have a texture. =p I can think of a few websites that would love to host these textures. Again, if all external hosts go down for some odd reason, I believe I did mention about a "fallback" option for the worst-case. Of course, the sim needs a copy of the texture, especially for sculpties and its physics even if it never sends it to a viewer. -- Power to Change the Void From seg at haxxed.com Sat Jul 7 15:40:38 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jul 7 15:40:12 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <20070707143358.GF3868@bruno.sbruno> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> Message-ID: <1183848038.16828.15.camel@localhost> On Sat, 2007-07-07 at 16:33 +0200, dale@daleglass.net wrote: > But scuplties use really tiny textures. You could simply get LL to make > an exception for 64x64 textures. At 16 bit color, uncompressed, that's > just 8K. You could not compress it at all. With lossless compression you should only need 32x32. I made a lossless 32x32 cube that looks perfect, once I get Maya installed I can try some better tests... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/61a01917/attachment.pgp From beth.osuch at gmail.com Sat Jul 7 16:12:43 2007 From: beth.osuch at gmail.com (Beth Osuch) Date: Sat Jul 7 16:12:51 2007 Subject: [sldev] Very newbie question Message-ID: Hello there, Today is my 3rd day on SL. I had experience with other graphic chats, not 3d but for years I owned some of them. Now I am interested, as my free time allows, in Second Life. As graphic lover and developper I would like start with basics: build objects. At this moment I am interested how can I change the material. I went to SL archive and I confess I got a bit afraid because most of posts were about scripts and software. So, forgive me if I am at wrong list. In the past mail lists were very helpful to me, teaching me everything about the chat I owned, The Palace. I made a search on web but was not lucky, I couldn?t find nothing to help me with how build objects. Could someone please, give me a light? a Source link? Tutorial links? Thank you very much! Forgive my english, is not my primary language. regards Beth aka Aniela Szondi -- Eu sei em quem votei. Eles tamb?m. Mas s? eles sabem quem recebeu meu voto. Cuidado, seu voto n?o ? secreto e pode ser roubado. http://voto-e.blogspot.com http://brasilacimadetudo.lpchat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070707/cc27a74d/attachment.htm From blakar at gmail.com Sat Jul 7 16:14:45 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jul 7 16:14:49 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <1183848038.16828.15.camel@localhost> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> Message-ID: <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> Sort of. By design you can actually do more in a 64x64. In a 64x64 you get 2 lines for poles and 31 lines for vertices. In a 32x32 you don't get a seperate 33rd line for the pole, your pole is picked from your 31st line of vertices. Not a huge difference but it's there. Personally I'm not fond of the current way poles are done. I'd rather see 32 lines of vertices plus poles that are calculated by taking the middle point between vertex 0 and 16 of top and bottom line. Dirk aka Blakar Ogre On 7/8/07, Callum Lerwick wrote: > On Sat, 2007-07-07 at 16:33 +0200, dale@daleglass.net wrote: > > But scuplties use really tiny textures. You could simply get LL to make > > an exception for 64x64 textures. At 16 bit color, uncompressed, that's > > just 8K. You could not compress it at all. > > With lossless compression you should only need 32x32. > > I made a lossless 32x32 cube that looks perfect, once I get Maya > installed I can try some better tests... > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From dale at daleglass.net Sat Jul 7 16:34:09 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sat Jul 7 16:34:14 2007 Subject: [sldev] Very newbie question In-Reply-To: References: Message-ID: <20070707233409.GA408@bruno.sbruno> On Sat, Jul 07, 2007 at 08:12:43PM -0300, Beth Osuch wrote: > Hello there, > > Today is my 3rd day on SL. I had experience with other graphic chats, not 3d > but for years I owned some of them. > Now I am interested, as my free time allows, in Second Life. As graphic > lover and developper I would like start with basics: build objects. At this > moment I am interested how can I change the material. I went to SL archive > and I confess I got a bit afraid because most of posts were about scripts > and software. So, forgive me if I am at wrong list. In the past mail lists > were very helpful to me, teaching me everything about the chat I owned, The > Palace. This is a list about the development of the SL viewer itself, that is, the thing that lets you access SL. Here we'd talk about the design/improvements to the tools you use to build objects, not how to use them, to put it in some way. > Could someone please, give me a light? a Source link? Tutorial links? I'd recommend visiting the Ivory Tower Library of Primitive, located at Noyo(211,183,38). To go there, open your map, type "Noyo" in the box that's left of the "Search" button, the coordinates where it says "Location", and click "Teleport". It has a very complete tutorial of how to build things, with examples of various stages. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070708/0456d74f/attachment.pgp From blakar at gmail.com Sat Jul 7 18:30:40 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jul 7 18:30:43 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <468FD0B9.3060800@dzonux.net> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> Message-ID: <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> Missing that _M_IX86_FP doesn't exist for VS2003 would happen to most of us. I just got lucky that I spotted it while browsing the info. I turned of my vertex shaders and let the program do a full run of tests. The SSE2 code was notably faster and got picked correctly. Seems to work fine when compiled with VS2005. For VS2003 you'll just have to assume people compile with correct arch cause I don't see a good way to detect arch during the compile. In the end if they don't set the correct arch it simply will not compile at all in such a case as it'll error out on the intrinsics. Dirk aka Blakar Ogre On 7/7/07, Dzonatas wrote: > Dirk Moerenhout wrote: > > Strange thing is that as far as I know LL is still building using VS > > 2003 and VS 2003 does not have the _M_IX86_FP macro so even if you > > compile with /arch:SSE2 in VS2003 you'll not get SSE2 support. > ... > Your right! It does say that here: > http://msdn2.microsoft.com/en-us/library/e54ke6de(vs.80).aspx Thanks > for pointing that out! > > I use VS2005 Express which of course the only thing I can afford at the > time, so my docs defaulted to that version. My bad? Yep, I guess I > deserve the street for that one...? > > Since it will auto-detect under VS2005, the workaround is to detect the > compiler version (being VS2003) in the _sse and _sse2 files and set > _M_IX86_FP accordingly before it includes any of the LLV4 headers. > > That should explain why some of the benchmarks came up negative even > when it should be positive despite cache pollution. > > > -- > Power to Change the Void > From jacek.antonelli at gmail.com Sat Jul 7 22:40:06 2007 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sat Jul 7 22:40:09 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <20070707130209.GD3868@bruno.sbruno> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> <20070707130209.GD3868@bruno.sbruno> Message-ID: <105c09f0707072240s3702c275lb72d2dbf24900a52@mail.gmail.com> On 7/7/07, dale@daleglass.net wrote: > Like I repeatedly said already (and you seem to insist on ignoring), > there's one big difference: > > I can choose not to click random website links, or not use streaming > if I want to. I have absolutely no problem with things that are > *optional* for me to use. > > Audio streams can only be set if you control the parcel, too. You can't > simply show up anywhere on the grid and do something that lets you have > everybody's IP address. > > I can't however realistically choose not to load textures. You could realistically choose not to load textures _from the web_. Assuming that such a feature could be disabled in preferences, of course. Audio and video streams on parcels only play if: 1) The appropriate preference checkboxes are enabled, and 2) You press Play on the media control tab. If web and/or P2P textures could likewise be disabled by unchecking a preference box, paranoid people could spend less time worrying about this issue, and more time browsing the SLDEV archives to realize that this same privacy debate happened back in January: https://lists.secondlife.com/pipermail/sldev/2007-January/000182.html Show me the patch to add the web/P2P texture downloading feature, and I'll take the necessary 10 minutes out of my day to add a preference checkbox to toggle it. - Jacek From gigstaggart at gmail.com Sat Jul 7 23:46:01 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jul 7 23:46:26 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <105c09f0707072240s3702c275lb72d2dbf24900a52@mail.gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> <20070707130209.GD3868@bruno.sbruno> <105c09f0707072240s3702c275lb72d2dbf24900a52@mail.gmail.com> Message-ID: <46908829.4070003@gmail.com> Jacek Antonelli wrote: > Show me the patch to add the web/P2P texture downloading feature, and > I'll take the necessary 10 minutes out of my day to add a preference > checkbox to toggle it. Show me a way to put a few hundred bytes of metadata on a prim face that the client will get, and I'll do web textures. :) https://jira.secondlife.com/browse/SVC-350 -Jason From labrat.hb at gmail.com Sun Jul 8 01:53:25 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sun Jul 8 01:53:28 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <105c09f0707072240s3702c275lb72d2dbf24900a52@mail.gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> <20070707130209.GD3868@bruno.sbruno> <105c09f0707072240s3702c275lb72d2dbf24900a52@mail.gmail.com> Message-ID: On 7/7/07, Jacek Antonelli wrote: > > > Audio and video streams on parcels only play if: > 1) The appropriate preference checkboxes are enabled, and > 2) You press Play on the media control tab. That is only true for Audio Streams. If someone allows MediaStreams (aka movies) in their client, they can be force started by LSL Scripts. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070708/43cb55c1/attachment.htm From kamilion at gmail.com Sun Jul 8 03:01:11 2007 From: kamilion at gmail.com (Kamilion) Date: Sun Jul 8 03:01:14 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <46900FD4.6090703@dzonux.net> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FC7F0.3080409@gmail.com> <468FD2A2.8020807@dzonux.net> <46900FD4.6090703@dzonux.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, here's another idea -- Squid currently supports Store Digests; Which is a bitmap that lossilly represents the contents of an entire squid cache, biased to hits. It also supports Client Streams; which allow other applications to access the squid cache. It also runs natively on windows built with mingw32. Technically, it shouldn't be too hard to build a control program that pulls the store digest from squid, and integrates a torrent tracker, torrent client, and some form of SuperTracker client that keeps track of the various "SLSquid" servers. This solves most of the problem with 'revealed' IP addresses. We would end up with a meshed network of SLSquids that could transfer textures between each other in the background. At that point, the SuperTracker is managing a round robin DNS containing all of the known SLSquids, which the SL client could be pointed at. This same sort of DNS management is commonly used in some larger IRC networks, where you connect to irc.network.com and you're redirected to a server appropriate for your geographical region. This also keeps a central point of authority which would be useful to block abusive users and/or servers. - From here, we have a meshed network of interconnected aggregate caches that serve content between each other on demand with the slower torrent protocol, while serving content to SL clients via fast HTTP from the cache. It would also allow later addition of the SL clients directly downloading full 'packs' of data from the caches, containing an entire object's worth of data: Say you have a linked object with 163 prims, each prim displaying 5 independent textures, all of them completely different. That's 815 textures of various sizes; not including sculpt textures. Add those in to get say, an even 900 textures. Plus this particular object has 20 sounds, and 80 animations, for an even 1000 assets. Let's say it's a dancefloor. This entire objectmass can be placed into a single .torrent, with all 1000 of those assets referenced. SLSquids or SLClients could pull down an entire object relatively quickly. One of the slowest parts of the torrent protocol is the fact that is has to discover peers; which we're 'solving' by making the torrent tracker a peer also, which has the benefit of quickly connecting to other peers that are also connecting to the torrent tracker's client. In this way, DHT networks can be formed quickly, and blocks can begin transferring immediately. Also, since bittorrent supports variable block sizes, faster block completion can be achived by using small blocks, since we rely on the fact that we're not transferring massive amounts of data in each load -- even a object with many assets would likely be under 10MB, and BT excels at packs of small files. Object-level torrents would be a huge advantage over single asset methods, mainly due to the fact that I havn't really seen the viewer load a partial object; only octree a full object's visible prims away. Torrent clients also have quite good bandwidth limiting, and a forced limit in the SL client could easily be chosen by default, such as 3KB/sec upload. Since the SLSquids take care of 90% of the block transfers, client to client transfers are pretty much just icing on the cake at that point, and don't really matter either way. This is a perfect little 3rd party community project that requires minimal serverside changes, uses mostly unmodified existing applications (Squid, ctorrent/libtorrent/torrentflux, bttrack.py/bnbteasytracker/phpbttrkplus/bytemonsoon), and is mostly glue code sticking the ragtag little group together; in fact, I wouldn't be surprised it if could be done easily in a dynamic language like perl, python, php, or ruby. I'm not sure if we've gone over to asset transfer over HTTP yet, but I do know it's in the roadmap already, and the sooner we get a handle on a decent way to pull this off, the more we can gear right into that roadmap. It also decreases what I would assume to be a fairly massive bandwidth and database load on the LL grid which translates to improved quality of experiance for all; allowing their transactions to deal with assets less and other systems like search, presence, messaging and scripts to be more reliable and concurrent, hopefully allowing far more people to be on the grid at once. It allows one more thing that could be quite useful; the ability to use SL texture assets outside of SL by requesting them from a cache. This would be handy for sites like SLExchange to display images of products directly from SL, using the images most item creators already use for vendors and primbox storefronts. Once again, this is a third party program that *supplements* SL -- it doesn't need to be part of the client. Everything necessary is already win32 compatible so we could provide a simple installer package for windows for "private home network" caches, and linux/bsd/solaris packages for larger (public?) servers. - -- Kamilion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://firegpg.tuxfamily.org iD8DBQFGkLXA+Hm92PVlrtQRAoGmAKC7jj6vB1/WpCn2uTsUvpS3bNGZCgCg9Umh czvF42CXSKs2vGiJ0FK9M3A= =+w5H -----END PGP SIGNATURE----- On 7/7/07, Simon Nolan wrote: > All this talk of Squids and Amazon S3 stores and Torrents is nice, > but why? Each viewer instance already has a texture cache. Instead of > mucking around with external services, can't our viewers just talk to > each other and share the textures in our caches? > > Why do we need a tracker? If you're in a sim, you already have a list > of others who have the textures that you need -- though I'm not sure > about how to go about resolving that list of residents in a sim into > P2P connections. The only use for external services/caches would be > for when you're the only person in a sim, and that's usually when I > *don't* have a problem with textures. > > Why are we talking about Torrents? It appears to be suboptimal for > small files, particularly sculptie textures. Should we consider our > own p2p protocol, or basing it on something that avoids the ramp-up > issues (and avoiding "tit for tat") in BitTorrent? (And I think part > of the reason Torrent keeps coming up is that's what was in Dzonatas' > original post.) > > Since DSL and other internet services are asymmetric, if I go to a > busy, complex sim, what's to prevent my uplink from becoming > saturated with texture sharing, lagging my client because it can't > squeeze in a message to the sim? > > Why do we need lossless textures for anything except sculpties? Not > to sound like I'm saying, "Textures are good enough for me, and dog- > gone it, they're good enough for you," but really, the textures I > upload look fine. The only problem I have is not that they're lossy- > compressed, but that they're not big enough. I can easily see pixels > on low-resolution textures on large objects, and even some not-so- > large objects. It has nothing at all to do with compression. > Honestly, though, I'm not crazy bout lagging my viewer client-side > with huge textures, regardless of where they're downloaded from. > > Dzonatas said that artists want lossless compression for their work, > but I wonder if they're double-compressing their images on upload. Do > they save them as JPEG from their image editor, then upload them > which compresses them again? I only ever upload Targas so that > there's only one round of lossy compression, and I get excellent > results. > > In all honesty, I'm not sure that P2P and larger/lossless images need > be tied together. In fact, if we could just get web textures, then > people would be free to host their own Squid caches with Dijjer > enabled and off we go. Of course, if someone stops paying their > hosting fees, their stuff goes buh-bye. LL-hosted textures would then > benefit from a custom client-side P2P that shares textures between > residents visiting the same sim. On 7/7/07, Dzonatas wrote: > I originally jotted down the ideas based on a collection full of talk > and data. I thought I was pretty darn clear about "subject to change." > > Yes, torrents are mentioned but it does not have to be BitTorrent; > however, it would be easier to use something that already exists just to > get the proof-of-concept done before we roll our own. > > BitTorrent uses connectionless transfers and peer discovery. That by > itself is the main reason why it is slow to initiate transfers. If it > kept active connections of peers, it would be much quicker without > initial transfer time slowdown. There should be an option who stays > active and who doesn't gets treated like normal BitTorrent client. > Everybody else without a client uses the http method to get files. This > can all be combine into a Squid cache. > > It would be nice to have one viewer connect directly to another. It > would be easier to allow these viewers to talk to a Squid to find out > who has just seen certain textures recently in order to get the textures > from them, if it is enabled on those viewers. That way, even if a ton of > people aren't in the same sim can still access the tracker to find the > texture. > > Remember, we can make these things optional. > > Why don't we just put an apache server into the viewer, then we can just > simply http redirect viewers that don't have a texture to viewers that > do have a texture. =p > > I can think of a few websites that would love to host these textures. > > Again, if all external hosts go down for some odd reason, I believe I > did mention about a "fallback" option for the worst-case. > > Of course, the sim needs a copy of the texture, especially for sculpties > and its physics even if it never sends it to a viewer. > > -- > Power to Change the Void From nicholaz at blueflash.cc Sun Jul 8 03:17:29 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 8 03:17:38 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> Message-ID: <4690B9B9.4050409@blueflash.cc> Dirk Moerenhout wrote: > Missing that _M_IX86_FP doesn't exist for VS2003 would happen to most > of us. I just got lucky that I spotted it while browsing the info. > > I turned of my vertex shaders and let the program do a full run of > tests. The SSE2 code was notably faster and got picked correctly. > Seems to work fine when compiled with VS2005. > > For VS2003 you'll just have to assume people compile with correct arch > cause I don't see a good way to detect arch during the compile. In the > end if they don't set the correct arch it simply will not compile at > all in such a case as it'll error out on the intrinsics. Well, I have VS2003. If anyone tells me what exactly I need to do and where to look, I'll try and see what results it will have. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From jhurliman at wsu.edu Sun Jul 8 05:30:10 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Jul 8 05:31:51 2007 Subject: [sldev] Lossless image uploading Message-ID: <4690D8D2.5000706@wsu.edu> Some people on this list have requested a way to upload lossless textures for sculpt maps, and my two latest libsecondlife utilities allow you to do that: https://wiki.secondlife.com/wiki/Importprimscript https://wiki.secondlife.com/wiki/SLImageUpload Not to mention the GPL viewer using OpenJPEG will also upload single layer, lossless images (this can create huge files, over 1MB). Patch for that is here: https://jira.secondlife.com/browse/VWR-1475 John Hurliman From blakar at gmail.com Sun Jul 8 07:10:54 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jul 8 07:10:56 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <4690B9B9.4050409@blueflash.cc> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> Message-ID: <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> In llv4math.h remove the "&& _M_IX86_FP" Make sure you have SSE enabled for llviewerjointmesh_sse.cpp and SSE2 for llviewerjointmesh_sse2.cpp. Compile and then run with the vertex shaders turned off. In your log files you'll see the result of the benchmarks. It switches between normal and SSE and makes 10 comparisons. After that it'll record the best one as default. If you'd turn vertex shaders off without removing the dependency on the _M_IX86_FP macro you should see that it doesn't find a real benefit in using SSE. Dirk aka Blakar Ogre On 7/8/07, Nicholaz Beresford wrote: > > Dirk Moerenhout wrote: > > Missing that _M_IX86_FP doesn't exist for VS2003 would happen to most > > of us. I just got lucky that I spotted it while browsing the info. > > > > I turned of my vertex shaders and let the program do a full run of > > tests. The SSE2 code was notably faster and got picked correctly. > > Seems to work fine when compiled with VS2005. > > > > For VS2003 you'll just have to assume people compile with correct arch > > cause I don't see a good way to detect arch during the compile. In the > > end if they don't set the correct arch it simply will not compile at > > all in such a case as it'll error out on the intrinsics. > > Well, I have VS2003. If anyone tells me what exactly I need to do and > where to look, I'll try and see what results it will have. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > From beth.osuch at gmail.com Sun Jul 8 07:14:41 2007 From: beth.osuch at gmail.com (Beth Osuch) Date: Sun Jul 8 07:14:43 2007 Subject: [sldev] Backups Message-ID: Please, which SL files do I need have backups? Where things are stored? I mean things I buy. It should be great have a link with these info. Can someone help me, please? thank you very much in advance, Beth aka Aniela Szondi -- Eu sei em quem votei. Eles tamb?m. Mas s? eles sabem quem recebeu meu voto. Cuidado, seu voto n?o ? secreto e pode ser roubado. http://voto-e.blogspot.com http://brasilacimadetudo.lpchat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070708/3b7d5d60/attachment-0001.htm From dzonatas at dzonux.net Sun Jul 8 08:12:49 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 08:12:09 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <468FC7F0.3080409@gmail.com> <468FD2A2.8020807@dzonux.net> <46900FD4.6090703@dzonux.net> Message-ID: <4690FEF1.9030303@dzonux.net> Kamilion wrote: > We would end up with a meshed network of SLSquids that could transfer > textures between each other in the background. > ... Kamilion, you just became my new best bud! That is the entire vision put into your message is perfect! I like to use what you wrote as a start for a wiki-page on this resident (community) project. As for what can be cached (asset-wise), I suggest to stay with static data. This is where I like to see that extra "prim-parameter" mark prim/asset as "archive"-able. The dance floor is a great example. Part of it is known to be static and another part of it is known to be non-static. The archive bit would tell the slcaches to go ahead and cache the non-static portions. The archive bit is lower-priority for now. -- Power to Change the Void From dzonatas at dzonux.net Sun Jul 8 08:16:03 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 08:15:25 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <46908829.4070003@gmail.com> References: <468EF56A.9000400@dzonux.net> <20070707022756.GA3868@bruno.sbruno> <468F5E8F.3040406@gmail.com> <20070707130209.GD3868@bruno.sbruno> <105c09f0707072240s3702c275lb72d2dbf24900a52@mail.gmail.com> <46908829.4070003@gmail.com> Message-ID: <4690FFB3.7070403@dzonux.net> Jason Giglio wrote: > Jacek Antonelli wrote: >> Show me the patch to add the web/P2P texture downloading feature, and >> I'll take the necessary 10 minutes out of my day to add a preference >> checkbox to toggle it. > > Show me a way to put a few hundred bytes of metadata on a prim face > that the client will get, and I'll do web textures. :) > > https://jira.secondlife.com/browse/SVC-350 > ... Create a LSL script to query, with xml-rpc, one of the slsquid caches that can store the meta-data. That is if the client doesn't do the query to the slsquid cache -- Power to Change the Void From dzonatas at dzonux.net Sun Jul 8 08:22:47 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 08:22:08 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> Message-ID: <46910147.6030201@dzonux.net> Probably easier just to define _M_IX86_FP in the VS2003 project files and only for the llviewerjointmesh_sse.cpp and llviewerjointmesh_sse2.cpp files. That would avoid any extra changes to the source and remain easily portable. Dirk Moerenhout wrote: > In llv4math.h remove the "&& _M_IX86_FP" > Make sure you have SSE enabled for llviewerjointmesh_sse.cpp and SSE2 > for llviewerjointmesh_sse2.cpp. Compile and then run with the vertex > shaders turned off. In your log files you'll see the result of the > benchmarks. It switches between normal and SSE and makes 10 > comparisons. After that it'll record the best one as default. > > If you'd turn vertex shaders off without removing the dependency on > the _M_IX86_FP macro you should see that it doesn't find a real > benefit in using SSE. > > Dirk aka Blakar Ogre > > On 7/8/07, Nicholaz Beresford wrote: >> >> Dirk Moerenhout wrote: >> > Missing that _M_IX86_FP doesn't exist for VS2003 would happen to most >> > of us. I just got lucky that I spotted it while browsing the info. >> > >> > I turned of my vertex shaders and let the program do a full run of >> > tests. The SSE2 code was notably faster and got picked correctly. >> > Seems to work fine when compiled with VS2005. >> > >> > For VS2003 you'll just have to assume people compile with correct arch >> > cause I don't see a good way to detect arch during the compile. In the >> > end if they don't set the correct arch it simply will not compile at >> > all in such a case as it'll error out on the intrinsics. >> >> Well, I have VS2003. If anyone tells me what exactly I need to do and >> where to look, I'll try and see what results it will have. >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From tateru.nino at gmail.com Sun Jul 8 08:51:58 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jul 8 08:52:05 2007 Subject: [sldev] Backups In-Reply-To: References: Message-ID: <4691081E.9020704@gmail.com> Everything you purchase or have in Second Life is stored on the Second Life grid servers. None of it is stored on your machine. There are no local files that you need to back up. Beth Osuch wrote: > Please, which SL files do I need have backups? Where things are > stored? I mean things I buy. > > It should be great have a link with these info. Can someone help me, > please? > > thank you very much in advance, > Beth aka Aniela Szondi > > -- > Eu sei em quem votei. Eles tamb?m. > Mas s? eles sabem quem recebeu meu voto. > Cuidado, seu voto n?o ? secreto e pode ser roubado. > http://voto-e.blogspot.com > http://brasilacimadetudo.lpchat.com > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From sl at phoca.com Sun Jul 8 09:46:10 2007 From: sl at phoca.com (Second Life) Date: Sun Jul 8 09:46:20 2007 Subject: [sldev] Lossless image uploading In-Reply-To: <4690D8D2.5000706@wsu.edu> References: <4690D8D2.5000706@wsu.edu> Message-ID: <266C893376814D8795B0AB05A576E7E6@SanMiguel> While uploading lossless prim sculpt maps is definitely a handy tool, (though I would like to see a feature to "Automatically flip Horizontal axis", of course that would require linking to an image library :/) I am not so sure that a tool to upload lossless textures larger than 64x64 is a good idea. :( It's just utterly not necessary, it'll fill up LL asset servers and severely stress bandwidth in every part of SL if people started using this tool en mass :( Were talking up to a 10x increase in LL asset server and sim server disk usage (thinking of the cashes on the server that are there/are coming) and bandwidth internal and external to the servers. Ungood *= 10; Farallon ----- Original Message ----- From: "John Hurliman" To: "Second Life Developer Mailing List" Sent: Sunday, July 08, 2007 5:30 AM Subject: [sldev] Lossless image uploading > Some people on this list have requested a way to upload lossless textures > for sculpt maps, and my two latest libsecondlife utilities allow you to do > that: > > https://wiki.secondlife.com/wiki/Importprimscript > https://wiki.secondlife.com/wiki/SLImageUpload > > Not to mention the GPL viewer using OpenJPEG will also upload single > layer, lossless images (this can create huge files, over 1MB). Patch for > that is here: https://jira.secondlife.com/browse/VWR-1475 > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From simon.nolan at gaylifesl.com Sun Jul 8 11:03:49 2007 From: simon.nolan at gaylifesl.com (Simon Nolan) Date: Sun Jul 8 11:03:54 2007 Subject: [sldev] Lossless image uploading In-Reply-To: <4690D8D2.5000706@wsu.edu> References: <4690D8D2.5000706@wsu.edu> Message-ID: For some reason, I just don't see this continuing to work for very long. ;-) On Jul 8, 2007, at 8:30A, John Hurliman wrote: > Some people on this list have requested a way to upload lossless > textures for sculpt maps, and my two latest libsecondlife utilities > allow you to do that: > > https://wiki.secondlife.com/wiki/Importprimscript > https://wiki.secondlife.com/wiki/SLImageUpload > > Not to mention the GPL viewer using OpenJPEG will also upload > single layer, lossless images (this can create huge files, over > 1MB). Patch for that is here: https://jira.secondlife.com/browse/ > VWR-1475 > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Sun Jul 8 11:34:09 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 8 11:34:23 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <46910147.6030201@dzonux.net> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> <46910147.6030201@dzonux.net> Message-ID: <46912E21.6010100@blueflash.cc> Dirk, Dzon, thanks for the info. I'll probably opt for a source change in those to files, because it is easier to patch them again for later releases, but now at least I know what I have to look for. Is this change intended long term for something else? I mean, most people are probably running with VBO's right? Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dzonatas wrote: > Probably easier just to define _M_IX86_FP in the VS2003 project files > and only for the llviewerjointmesh_sse.cpp and > llviewerjointmesh_sse2.cpp files. That would avoid any extra changes to > the source and remain easily portable. > > Dirk Moerenhout wrote: >> In llv4math.h remove the "&& _M_IX86_FP" >> Make sure you have SSE enabled for llviewerjointmesh_sse.cpp and SSE2 >> for llviewerjointmesh_sse2.cpp. Compile and then run with the vertex >> shaders turned off. In your log files you'll see the result of the >> benchmarks. It switches between normal and SSE and makes 10 >> comparisons. After that it'll record the best one as default. >> >> If you'd turn vertex shaders off without removing the dependency on >> the _M_IX86_FP macro you should see that it doesn't find a real >> benefit in using SSE. >> >> Dirk aka Blakar Ogre >> >> On 7/8/07, Nicholaz Beresford wrote: >>> >>> Dirk Moerenhout wrote: >>> > Missing that _M_IX86_FP doesn't exist for VS2003 would happen to most >>> > of us. I just got lucky that I spotted it while browsing the info. >>> > >>> > I turned of my vertex shaders and let the program do a full run of >>> > tests. The SSE2 code was notably faster and got picked correctly. >>> > Seems to work fine when compiled with VS2005. >>> > >>> > For VS2003 you'll just have to assume people compile with correct arch >>> > cause I don't see a good way to detect arch during the compile. In the >>> > end if they don't set the correct arch it simply will not compile at >>> > all in such a case as it'll error out on the intrinsics. >>> >>> Well, I have VS2003. If anyone tells me what exactly I need to do and >>> where to look, I'll try and see what results it will have. >>> >>> >>> Nick >>> >>> >>> Second Life from the inside out: >>> http://nicholaz-beresford.blogspot.com/ >>> >>> >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > From dzonatas at dzonux.net Sun Jul 8 11:52:07 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 11:51:27 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <46912E21.6010100@blueflash.cc> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> <46910147.6030201@dzonux.net> <46912E21.6010100@blueflash.cc> Message-ID: <46913257.2070307@dzonux.net> The reason you really don't want to patch the source files is for portability and that there may be more _vec, _sse, and _sse2 type files for other optimizations. Really, it is that portion of the filename, the "_vec", "_sse", and "_sse2" that determines what compiler options should be on and what headers should not be included. Those particular implementations can not be mixed with pre-compiled headers, for example. If you look in the SConstruct, you'll see it specifically checking for the filenames in order to determine to turn on the optimizations. I used VS2005 Express with a version of the SConstruct files that compiles with VS2005, which makes all these little options on each file very transparent. Obviously, I could not change the VS2003 project files with VS2005. As for VBOs, not everybody leaves them on. If you are thinking of trying to align that data, it has been tried. There is a bug LL's gl indices implementation that didn't allow align data, even though gl supports it. I still have the patch for the VBO alignment if you want to figure it out. Nicholaz Beresford wrote: > > Dirk, > Dzon, > > thanks for the info. I'll probably opt for a > source change in those to files, because it is > easier to patch them again for later releases, > but now at least I know what I have to look for. > > Is this change intended long term for something > else? I mean, most people are probably running > with VBO's right? -- Power to Change the Void From jhurliman at wsu.edu Sun Jul 8 12:47:24 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Jul 8 12:49:04 2007 Subject: [sldev] Lossless image uploading In-Reply-To: <266C893376814D8795B0AB05A576E7E6@SanMiguel> References: <4690D8D2.5000706@wsu.edu> <266C893376814D8795B0AB05A576E7E6@SanMiguel> Message-ID: <46913F4C.40502@wsu.edu> Second Life wrote: > While uploading lossless prim sculpt maps is definitely a handy tool, > (though I would like to see a feature to "Automatically flip > Horizontal axis", of course that would require linking to an image > library :/) I am not so sure that a tool to upload lossless textures > larger than 64x64 is a good idea. :( > GDI+ is used for all of the image manipulation prior to encoding, so I can add this. > It's just utterly not necessary, it'll fill up LL asset servers and > severely stress bandwidth in every part of SL if people started using > this tool en mass :( Were talking up to a 10x increase in LL asset > server and sim server disk usage (thinking of the cashes on the server > that are there/are coming) and bandwidth internal and external to the > servers. > > Ungood *= 10; > > Farallon You mean like the GPL viewer? I could get in to a discussion about the shortcomings of client-side security, but LL has already preempted me in creating this tool of mass destruction you speak of. John From hawk.carter at unix-dev.de Sun Jul 8 13:02:05 2007 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Sun Jul 8 13:02:18 2007 Subject: [sldev] SSE/Vector stuff References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc><7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com><46910147.6030201@dzonux.net> <46912E21.6010100@blueflash.cc> <46913257.2070307@dzonux.net> Message-ID: <003f01c7c19a$db8d1890$0301a8c0@main1> As i know, most Graphics people as well normal people with newer cards have VBO on..as well all other Vertex Switches, as long Sl is more using the CPU as the GPU for Rendering. Greetings hawk ----- Original Message ----- From: "Dzonatas" To: "Nicholaz Beresford" Cc: "Second Life Developer Mailing List" Sent: Sunday, July 08, 2007 8:52 PM Subject: Re: [sldev] SSE/Vector stuff > The reason you really don't want to patch the source files is for > portability and that there may be more _vec, _sse, and _sse2 type files > for other optimizations. Really, it is that portion of the filename, the > "_vec", "_sse", and "_sse2" that determines what compiler options should > be on and what headers should not be included. Those particular > implementations can not be mixed with pre-compiled headers, for example. > > If you look in the SConstruct, you'll see it specifically checking for the > filenames in order to determine to turn on the optimizations. > > I used VS2005 Express with a version of the SConstruct files that compiles > with VS2005, which makes all these little options on each file very > transparent. Obviously, I could not change the VS2003 project files with > VS2005. > > As for VBOs, not everybody leaves them on. If you are thinking of trying > to align that data, it has been tried. There is a bug LL's gl indices > implementation that didn't allow align data, even though gl supports it. I > still have the patch for the VBO alignment if you want to figure it out. > > Nicholaz Beresford wrote: >> >> Dirk, >> Dzon, >> >> thanks for the info. I'll probably opt for a >> source change in those to files, because it is >> easier to patch them again for later releases, >> but now at least I know what I have to look for. >> >> Is this change intended long term for something >> else? I mean, most people are probably running >> with VBO's right? > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From beth.osuch at gmail.com Sun Jul 8 13:46:48 2007 From: beth.osuch at gmail.com (Beth Osuch) Date: Sun Jul 8 13:46:51 2007 Subject: [sldev] Thank you! Message-ID: To all nice people here, thank you very much to accept me in this list. Since I am not software developer dont make sense I stay here. Thank you very much for all help I got from you Dale, Tateru and Simon. Thank you also for others who were patient with me. I am leaving this list. my best regards to you all Beth aka Aniela Szondi p.s. Please feel free to reach me if needed.:-) -- Eu sei em quem votei. Eles tamb?m. Mas s? eles sabem quem recebeu meu voto. Cuidado, seu voto n?o ? secreto e pode ser roubado. http://voto-e.blogspot.com http://brasilacimadetudo.lpchat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070708/23fe6ba3/attachment.htm From dereck at gmail.com Sun Jul 8 14:17:18 2007 From: dereck at gmail.com (Dereck Wonnacott) Date: Sun Jul 8 14:17:20 2007 Subject: [sldev] Linux IDE for starters~ Message-ID: <2d8148cd0707081417k3153973bhcfe1a051afd67ab5@mail.gmail.com> Hi all! Slightly inspired by the Mad Patcher, I'm going to try to start being an active member of SLdev. I've not had too much 'real' experience in programming though, my largest program was a mere 20k lines in C. I've till now managed to just use vim as my code editor of choice... SL is a turns out to be little bit bigger.... I'll miss my poor grep/vim/gdb family, but what IDE(s)/debuger(s)/Other-misc-tool(s) might I look into learning? I'm running Ubuntu 7.10 AMD64 as my desktop. THANKS! ~Dereck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070708/8a686907/attachment.htm From nicholaz at blueflash.cc Sun Jul 8 14:30:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 8 14:30:26 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <46913257.2070307@dzonux.net> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> <46910147.6030201@dzonux.net> <46912E21.6010100@blueflash.cc> <46913257.2070307@dzonux.net> Message-ID: <46915763.9050103@blueflash.cc> Dzonatas wrote: > The reason you really don't want to patch the source files is for > portability and that there may be more _vec, _sse, and _sse2 type files > for other optimizations. Really, it is that portion of the filename, the > "_vec", "_sse", and "_sse2" that determines what compiler options should > be on and what headers should not be included. Those particular > implementations can not be mixed with pre-compiled headers, for example. Understood, but it was for a test compile anyway. I'm skipping 1.17.3 at the moment, with 1.18 imminent, just wanted to see how that stuff works. But I'm not so much into performance anyway. With the patch sematary already overflowing again, I'm concentrating on making a decent build. And I expect the Lindens to put in those predefines in the projects (and/or put some #ifndef #error #endif combinations in place to make sure the options are set correctly. I guess it's good that I mentioned it though, so that it's clear that currently the code does nothing for the compile (and it would have been a terrible waste of effort if it had gone undetected, so Kudos to Dirk). Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Sun Jul 8 14:34:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 14:33:40 2007 Subject: [sldev] SLSquid Proxy -- P2P/Squid Web Textures draft 3 Message-ID: <4691585D.1010306@dzonux.net> Here is where the third draft has been put: https://wiki.secondlife.com/wiki/SLSquid_Proxy I started the page with Kamilion's awesome description of what we talked about. I hope we can get a basic how-to going before any code changes are made. -- Power to Change the Void From seg at haxxed.com Sun Jul 8 14:34:45 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Jul 8 14:34:14 2007 Subject: [sldev] Linux IDE for starters~ In-Reply-To: <2d8148cd0707081417k3153973bhcfe1a051afd67ab5@mail.gmail.com> References: <2d8148cd0707081417k3153973bhcfe1a051afd67ab5@mail.gmail.com> Message-ID: <1183930485.19854.0.camel@localhost> On Sun, 2007-07-08 at 17:17 -0400, Dereck Wonnacott wrote: > Hi all! > > Slightly inspired by the Mad Patcher, I'm going to try to start being > an active member of SLdev. I've not had too much 'real' experience in > programming though, my largest program was a mere 20k lines in C. I've > till now managed to just use vim as my code editor of choice... > > SL is a turns out to be little bit bigger.... I'll miss my poor > grep/vim/gdb family, but what IDE(s)/debuger(s)/Other-misc-tool(s) > might I look into learning? VIM works for me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070708/d3c3e1ff/attachment.pgp From dzonatas at dzonux.net Sun Jul 8 15:15:25 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 15:15:29 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <46915763.9050103@blueflash.cc> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> <46910147.6030201@dzonux.net> <46912E21.6010100@blueflash.cc> <46913257.2070307@dzonux.net> <46915763.9050103@blueflash.cc> Message-ID: <469161FD.3040300@dzonux.net> Nicholaz Beresford wrote: > And I expect the Lindens to put in those predefines in the projects > (and/or put some #ifndef #error #endif combinations in place to make sure > the options are set correctly. Heh... I originally had those kinds of predefines in there in source (not in the project files, of course). Hmm. There was some reason why they were taken out and defaulted back to the _vec version. > > I guess it's good that I mentioned it though, so that it's clear that > currently the code does nothing for the compile (and it would have been > a terrible waste of effort if it had gone undetected, so Kudos to Dirk). > Right. Even though I completed what was asked the first time around and, as further asked a second and third time around, did more then the original desire, it was all considered a waste of time in the end. For what was asked for in the second and third time around, it sure would have helped if I had a proper orientation like any other Linden Lab employee. Then I wouldn't have to waste contract time that is suppose to spent on this project to learn how internal build method works and other procedures. I've seen how LL employees are formally introduced and orientated to the business. I didn't get the same treatment but was required work at least at the same level. It didn't make sense they didn't just formally hire me to get the job done the right way in be a position to easily work together with other employees. I really could not afford a daily commute to the closest Linden office. Ugh, I code... I poor. In the end, well... I still have a uncashed check they sent back to me after I gave it back. I went totally unpaid for the last bit to help finish the job. I didn't feel accomplished for what was asked even though it appeared completed. It was like it was not enough. Customer is always right.. they can keep the money! Hmm. There must be a reason why I'm on a hunger strike now (-9lbs today). The LLV4 headers are free now to help optimize Second Life. Kudos to Dirk... send me your street address and I'll send you this uncashed check from LL where you can cash it. -- Power to Change the Void From blakar at gmail.com Sun Jul 8 15:16:20 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jul 8 15:16:25 2007 Subject: [sldev] Code cleanup / performance patches Message-ID: <7992d0d60707081516x2fd110a7xc89a373189baa4df@mail.gmail.com> VWR-1612 and VWR-1613 The performance impact of these combined shouldn't exceed 2 to 3% at best but it does also help keeping code clean and logical. The addTextureStats (VWR-1612) optimises towards how the function is called in over 90% of the cases. The lltree/lloctree (VWR-1613) stuff is just cleaning up the overuse of virtual as this currently stops the compiler (at least in VS2005) from inlining. Dirk aka Blakar Ogre From blakar at gmail.com Sun Jul 8 15:23:07 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jul 8 15:23:10 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <469161FD.3040300@dzonux.net> References: <468FAE83.6060505@blueflash.cc> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> <46910147.6030201@dzonux.net> <46912E21.6010100@blueflash.cc> <46913257.2070307@dzonux.net> <46915763.9050103@blueflash.cc> <469161FD.3040300@dzonux.net> Message-ID: <7992d0d60707081523x73389368o7df666255408d67c@mail.gmail.com> > Kudos to Dirk... send me your street address and I'll send you this > uncashed check from LL where you can cash it. No need for that. The only thing I did was making sure the benefits of your code could be seen by all. Would've been a waste if it remained unused just because LL compiled with VS2003. I doubt I'd be able to cash it here in Belgium anyway :) Dirk aka Blakar Ogre From dale at daleglass.net Sun Jul 8 15:48:12 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sun Jul 8 15:48:18 2007 Subject: [sldev] Linux IDE for starters~ In-Reply-To: <2d8148cd0707081417k3153973bhcfe1a051afd67ab5@mail.gmail.com> References: <2d8148cd0707081417k3153973bhcfe1a051afd67ab5@mail.gmail.com> Message-ID: <20070708224812.GA23822@bruno.sbruno> On Sun, Jul 08, 2007 at 05:17:18PM -0400, Dereck Wonnacott wrote: > Hi all! > > Slightly inspired by the Mad Patcher, I'm going to try to start being an > active member of SLdev. I've not had too much 'real' experience in > programming though, my largest program was a mere 20k lines in C. I've till > now managed to just use vim as my code editor of choice... More people is always a good thing :-) > > SL is a turns out to be little bit bigger.... I'll miss my poor > grep/vim/gdb family, but what IDE(s)/debuger(s)/Other-misc-tool(s) might I > look into learning? I use kdevelop here, it's pretty nice. I also recommend trying doxygen, it's REALLY good for getting around the source. I have the results of it online: http://doc.daleglass.net/ Mind, this is quite ancient, as I changed things here and haven't got around updating it yet, but it works as a demo of what it does. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070709/a3e4fcda/attachment.pgp From seg at haxxed.com Sun Jul 8 16:45:29 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Jul 8 16:44:58 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> Message-ID: <1183938329.19854.4.camel@localhost> On Sun, 2007-07-08 at 01:14 +0200, Dirk Moerenhout wrote: > Sort of. By design you can actually do more in a 64x64. In a 64x64 you > get 2 lines for poles and 31 lines for vertices. In a 32x32 you don't > get a seperate 33rd line for the pole, your pole is picked from your > 31st line of vertices. > > Not a huge difference but it's there. Personally I'm not fond of the > current way poles are done. I'd rather see 32 lines of vertices plus > poles that are calculated by taking the middle point between vertex 0 > and 16 of top and bottom line. You know, this isn't actually being used as an OpenGL texture, there's really no reason a sculpt map has to be power of two dimentioned. Why not just use a 32x33 map? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070708/5204db2b/attachment.pgp From dale at daleglass.net Sun Jul 8 16:47:11 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Sun Jul 8 16:47:14 2007 Subject: [sldev] Working on an installer, anybody figured out licensing yet_ Message-ID: <20070708234710.GB23822@bruno.sbruno> Hiya :-) I've been working on an installer again. Previous approach was ugly and required .NET, so I got rid of that. Instead I decided to tackle two problems at once: Redistribution restrictions, and updates. Both are solved in the same way: Installer just carries a file list with it, with filename and MD5 sum. When you install, it checks whether the file is already there. If not, or the md5sum is wrong, it checks all SL installs and tries to find it there. If not, it downloads. The files that can't be redistributed aren't on my server, so if they're needed and can't be found locally, the install fails. All this is coded in NSIS with a MD5 and a file decompression plugin. This way, even the first install of my version of the viewer will grab already installed files, and further updates will be just what changed. No more 25MB downloads. Now, I'd like to make my installer include as many files as possible to make sure it doesn't need very specific official SL versions to be installed. So, anybody figured out what can be redistributed yet? If so, a wiki page on it would be very helpful. A number of DLLs in the package don't come with the source, but I think that some of them must be redistributable. These are the files in the main directory: dbghelp.dll, msvcp71.dll, msvcr71.dll: Microsoft runtime stuff, I assume redistributable. fmod.dll: Not sure, might be. Could be specifically downloaded from the fmod website, I suppose. freebl3.dll, js3250.dll, nspr4.dll, nss3.dll, nssckbi.dll, plc4.dll, plds4.dll, smime3.dll, softokn3.dll, ssl3.dll, xul.dll: Mozilla stuff, given the Mozilla license I assume they're redistributable. app_settings/mozilla: I assume redistributable xpcom.dll, gksvggdiplus.dll: Definitely redistributable, license stated as "License: MPL 1.1/GPL 2.0/LGPL 2.1". llkdu.dll: Apparently not redistributable. So, at first glance, except llkdu.dll and perhaps fmod.dll, everything else should be fine to redistribute? Questions for LL: Other than library redistibution restrictions, what other things are there to have in mind when releasing a custom viewer? Can I just package the results of the complication as-is, or do I need to do something more? For example, can I leave the SL icon as it is, or I'd have to have my own branding? Should my viewer identify itself as a third party viewer to the grid? Do I need to remove or disable anything (crash reporter, for example)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070709/2bc8d27a/attachment.pgp From blakar at gmail.com Sun Jul 8 16:57:33 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jul 8 16:57:36 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <1183938329.19854.4.camel@localhost> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> <1183938329.19854.4.camel@localhost> Message-ID: <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> Current subsampling and LOD routines expect it to be a power of 2. I hate the current LOD handling too as it considers the texture no different than an image and hence LOD downscales the image and interpolates the vertices. I'd change the LOD handling but there's little point before we have an agreement with LL on losslessly compressed sculpt textures. Dirk aka Blakar Ogre On 7/9/07, Callum Lerwick wrote: > On Sun, 2007-07-08 at 01:14 +0200, Dirk Moerenhout wrote: > > Sort of. By design you can actually do more in a 64x64. In a 64x64 you > > get 2 lines for poles and 31 lines for vertices. In a 32x32 you don't > > get a seperate 33rd line for the pole, your pole is picked from your > > 31st line of vertices. > > > > Not a huge difference but it's there. Personally I'm not fond of the > > current way poles are done. I'd rather see 32 lines of vertices plus > > poles that are calculated by taking the middle point between vertex 0 > > and 16 of top and bottom line. > > You know, this isn't actually being used as an OpenGL texture, there's > really no reason a sculpt map has to be power of two dimentioned. Why > not just use a 32x33 map? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From nicholaz at blueflash.cc Sun Jul 8 17:52:07 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 8 17:52:18 2007 Subject: [sldev] Code cleanup / performance patches In-Reply-To: <7992d0d60707081516x2fd110a7xc89a373189baa4df@mail.gmail.com> References: <7992d0d60707081516x2fd110a7xc89a373189baa4df@mail.gmail.com> Message-ID: <469186B7.7090302@blueflash.cc> Ahh coool ... will look at them ... thanks for posting. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dirk Moerenhout wrote: > VWR-1612 and VWR-1613 > > The performance impact of these combined shouldn't exceed 2 to 3% at > best but it does also help keeping code clean and logical. > > The addTextureStats (VWR-1612) optimises towards how the function is > called in over 90% of the cases. > > The lltree/lloctree (VWR-1613) stuff is just cleaning up the overuse > of virtual as this currently stops the compiler (at least in VS2005) > from inlining. > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Sun Jul 8 18:03:00 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 8 18:03:09 2007 Subject: [sldev] SSE/Vector stuff In-Reply-To: <469161FD.3040300@dzonux.net> References: <468FAE83.6060505@blueflash.cc> <7992d0d60707070825k1d02891cg7d2c082e5f4811c3@mail.gmail.com> <468FB947.8060908@blueflash.cc> <7992d0d60707070949v7d24f0f1n90565bef79007cf3@mail.gmail.com> <7992d0d60707071013n26d722e7m95869d1faa6ea1f6@mail.gmail.com> <468FD0B9.3060800@dzonux.net> <7992d0d60707071830h36c58d0cpaa0294131e1eb3a0@mail.gmail.com> <4690B9B9.4050409@blueflash.cc> <7992d0d60707080710i292b73c8ve8283044306f30be@mail.gmail.com> <46910147.6030201@dzonux.net> <46912E21.6010100@blueflash.cc> <46913257.2070307@dzonux.net> <46915763.9050103@blueflash.cc> <469161FD.3040300@dzonux.net> Message-ID: <46918944.7080608@blueflash.cc> Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ > Right. Even though I completed what was asked the first time around and, > as further asked a second and third time around, did more then the > original desire, it was all considered a waste of time in the end. Oh, didn't know it was a contract job. > In the end, well... I still have a uncashed check they sent back to me > after I gave it back. I went totally unpaid for the last bit to help > finish the job. I didn't feel accomplished for what was asked even > though it appeared completed. Oh ohh ... guess I know why I've given up contracting a long time ago. But honestly, I wouldn't leave the cheque uncashed (or well, maybe there would be situations where I would, but these would be jobs gone really really wrong), cause it's payment for your time also, not just the result (and the result seems to be doing something, even if it's not doing it now). Nick From dzonatas at dzonux.net Sun Jul 8 19:17:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 8 19:17:12 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> <1183938329.19854.4.camel@localhost> <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> Message-ID: <46919AA5.5030904@dzonux.net> I just backed-out of thinking-out the "patched" sculpties with a specialized tile method on the DWT. Right now the alpha layer is not being used, and it could easily be used to create arbitrary sized sculpt patches. It may be hard to compute on the physics side, but it occurred to me that the SLSquid idea allows sculpties of even 1024x1024 detail.... or greater! No server side changes needed. Just drop the UUID that a SLSquid server returns, when you upload it to the SLSquid-mesh, into the prim (set it by LSL). Highly detailed sculpties. Laggy? Nah... not with the OpenJPEG and LLV4 changes. Well... its just a dream for now. =) Dirk Moerenhout wrote: > Current subsampling and LOD routines expect it to be a power of 2. > > I hate the current LOD handling too as it considers the texture no > different than an image and hence LOD downscales the image and > interpolates the vertices. > > I'd change the LOD handling but there's little point before we have an > agreement with LL on losslessly compressed sculpt textures. > > Dirk aka Blakar Ogre > > On 7/9/07, Callum Lerwick wrote: >> On Sun, 2007-07-08 at 01:14 +0200, Dirk Moerenhout wrote: >> > Sort of. By design you can actually do more in a 64x64. In a 64x64 you >> > get 2 lines for poles and 31 lines for vertices. In a 32x32 you don't >> > get a seperate 33rd line for the pole, your pole is picked from your >> > 31st line of vertices. >> > >> > Not a huge difference but it's there. Personally I'm not fond of the >> > current way poles are done. I'd rather see 32 lines of vertices plus >> > poles that are calculated by taking the middle point between vertex 0 >> > and 16 of top and bottom line. >> >> You know, this isn't actually being used as an OpenGL texture, there's >> really no reason a sculpt map has to be power of two dimentioned. Why >> not just use a 32x33 map? >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From jhurliman at wsu.edu Sun Jul 8 19:25:58 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Jul 8 19:27:37 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <46919AA5.5030904@dzonux.net> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> <1183938329.19854.4.camel@localhost> <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> <46919AA5.5030904@dzonux.net> Message-ID: <46919CB6.1020205@wsu.edu> Dzonatas wrote: > I just backed-out of thinking-out the "patched" sculpties with a > specialized tile method on the DWT. Right now the alpha layer is not > being used, and it could easily be used to create arbitrary sized > sculpt patches. It may be hard to compute on the physics side, but it > occurred to me that the SLSquid idea allows sculpties of even > 1024x1024 detail.... or greater! > > No server side changes needed. Just drop the UUID that a SLSquid > server returns, when you upload it to the SLSquid-mesh, into the prim > (set it by LSL). > > Highly detailed sculpties. Laggy? Nah... not with the OpenJPEG and > LLV4 changes. > > Well... its just a dream for now. =) How will a proxy or P2P layer speed up client rendering of objects with over a million vertices each (1024x1024 sculpt map)? While we battle the fight to get more FPS out of the client and a smoother overall experience it seems contradictory to have up to 256x larger vertex buffers being passed around. John Hurliman From kerdezixe at gmail.com Sun Jul 8 21:05:51 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sun Jul 8 21:05:53 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <46919AA5.5030904@dzonux.net> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> <1183938329.19854.4.camel@localhost> <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> <46919AA5.5030904@dzonux.net> Message-ID: <8a1bfe660707082105o836a84bm32db9a14c1bbac38@mail.gmail.com> On 7/9/07, Dzonatas wrote: >sculpties of even 1024x1024 detail.... or greater! Insane. -- kerunix Flan From huse at gmx.org Mon Jul 9 02:06:35 2007 From: huse at gmx.org (Friederike Huse) Date: Mon Jul 9 02:06:37 2007 Subject: [sldev] Loggin in Message-ID: <20070709090635.76820@gmx.net> Hello, I just created an account, chose a password and downloaded and installed the software. However, I still cannot log in. Any ideas what is wrong? Thanks a lot, Babahule From tateru.nino at gmail.com Mon Jul 9 02:28:57 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jul 9 02:29:04 2007 Subject: [sldev] Loggin in In-Reply-To: <20070709090635.76820@gmx.net> References: <20070709090635.76820@gmx.net> Message-ID: <4691FFD9.2090901@gmail.com> This isn't actually the right list for that, but I assume you followed the instructions in the confirmation email that was sent to your email address? (If you didn't see it, check your junk folder, in case your local spam filters ate it) Friederike Huse wrote: > Hello, > > I just created an account, chose a password and downloaded and installed the software. However, I still cannot log in. Any ideas what is wrong? > > Thanks a lot, > > Babahule > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Tateru Nino http://dwellonit.blogspot.com/ From nicholaz at blueflash.cc Mon Jul 9 05:17:47 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 05:17:55 2007 Subject: [sldev] SSE2 / Ouch Message-ID: <4692276B.8000501@blueflash.cc> Dunno if it's true, but if it is (and this guy sounds like he knows what he's talking about), it's a definite "OUCH!" and explains a lot of reports about crashing on startup. https://jira.secondlife.com/browse/VWR-1610 Nick From blakar at gmail.com Mon Jul 9 06:23:38 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 9 06:23:41 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <4692276B.8000501@blueflash.cc> References: <4692276B.8000501@blueflash.cc> Message-ID: <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> Well I already noted in a previous mail I wasn't convinced that it would be safe to do it this way as everything you include gets handled with the same architecture. So you really need to go over all your includes in there and look what exactly you are doing and what the global impact will be. I guess the issue is that we have this: static LLV4Matrix4 sJointMat[32]; That initialisation will probably use SSE. You can't just move that elsewhere because then no SSE code would be generated (as there's #if LL_VECTORIZE in there). Tricky :) I suppose you can drop the static but it'll likely have performance impact and I'm not sure it's enough to stop MSVC from bleeding SSE instructions over to unexpected areas. Dirk aka Blakar Ogre On 7/9/07, Nicholaz Beresford wrote: > > Dunno if it's true, but if it is (and this guy sounds like > he knows what he's talking about), it's a definite "OUCH!" > and explains a lot of reports about crashing on startup. > > https://jira.secondlife.com/browse/VWR-1610 > > > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blakar at gmail.com Mon Jul 9 07:00:21 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 9 07:00:25 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> Message-ID: <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> I just thought of the fact that static there isn't the point. It's outside scope of a class so it's there to limit the var to the file. I should really polish up my C++ :-) It doesn't make things easier as I still don't see how a simple change can solve the issue. You need the correct arch to be enabled or the class will not be compiled with the correct code. What if you make descendant classes and overload the functions instead? I'm starting to remember why I'm not fond of OO :) Dirk aka Blakar Ogre On 7/9/07, Dirk Moerenhout wrote: > Well I already noted in a previous mail I wasn't convinced that it > would be safe to do it this way as everything you include gets handled > with the same architecture. So you really need to go over all your > includes in there and look what exactly you are doing and what the > global impact will be. > > I guess the issue is that we have this: > static LLV4Matrix4 sJointMat[32]; > > That initialisation will probably use SSE. > > You can't just move that elsewhere because then no SSE code would be > generated (as there's #if LL_VECTORIZE in there). > > Tricky :) I suppose you can drop the static but it'll likely have > performance impact and I'm not sure it's enough to stop MSVC from > bleeding SSE instructions over to unexpected areas. > > Dirk aka Blakar Ogre > > > On 7/9/07, Nicholaz Beresford wrote: > > > > Dunno if it's true, but if it is (and this guy sounds like > > he knows what he's talking about), it's a definite "OUCH!" > > and explains a lot of reports about crashing on startup. > > > > https://jira.secondlife.com/browse/VWR-1610 > > > > > > > > > > Nick > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From babbage at lindenlab.com Mon Jul 9 07:20:21 2007 From: babbage at lindenlab.com (Jim Purbrick (Babbage)) Date: Mon Jul 9 07:21:35 2007 Subject: [sldev] Opening the server source? In-Reply-To: <70E20202-C37C-4C7F-9D4D-B0C6E8335BD7@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <4689B9FD.2020307@gwala.net> <468A5524.7080307@dzonux.net> <2925011a0707030938m41101897od63b1e85244e508e@mail.gmail.com> <468A80F4.2050509@dzonux.net> <2925011a0707031021p81879aapf271adbfdabeae57@mail.gmail.com> <468A8C83.3080309@dzonux.net> <70E20202-C37C-4C7F-9D4D-B0C6E8335BD7@gmail.com> Message-ID: On 3 Jul 2007, at 20:30, Argent Stonecutter wrote: >> The only reason why you really want to keep these executables pre- >> compiled is to hide the source. > > The executable isn't just "not recompiled", it's also "not halted > and restarted". The internal state (the virtual machine equivalent > of the registers, program counter, variables, and so on) has to be > retained on sim border crossings. This is the tricky bit. You need to be able to serialize the CLI stack to send over the new machine so that you can restore local variables before restarting the script. Projects like JavaGoX do it for Java, we implemented a similar scheme for Mono. Cheers, Jim/Babbage From babbage at lindenlab.com Mon Jul 9 07:24:05 2007 From: babbage at lindenlab.com (Jim Purbrick (Babbage)) Date: Mon Jul 9 07:25:06 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468AEC3E.3000208@gwala.net> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> <468AEC3E.3000208@gwala.net> Message-ID: <28B2E923-31D8-41E7-8F34-3DA087B0624C@lindenlab.com> Actually, the first C# scripts ran on SL simulators about 18 months ago, but that's because they were scripts I wrote and so trusted. As Adam says, being able to securely run untrusted scripts written in arbitrary languages is the tricky bit. Our microthreading injector can whitelist method calls to avoid dangerous library calls, but we're probably going to have to wait until the Moonlight project implements the Silverlight security model before we can allow arbitrary CIL assemblies to run on the main grid. Cheers, Jim/Babbage On 4 Jul 2007, at 01:39, Adam Frisby wrote: > There's been whispers of it occasionally. Technically it shouldnt > be hard to do, the key is in making sure you dont support language > features linking to the system class library (since that makes for > a nice security risk). > > Adam > > Argent Stonecutter wrote: > >> On 03-Jul-2007, at 08:46, Chance Unknown wrote: >>> Mono is a programming lauguage. >> Mono is not a programming language. C# is a programming language, >> J# is a programming language. VB.Net is a programming language. >> All these programming languages compile to CIL code which is run >> in the Mono virtual machine. >> Linden Labs was not, so far as I know, planning on supporting any >> language but LSL even after converting to Mono. From sldev at catznip.com Mon Jul 9 07:32:30 2007 From: sldev at catznip.com (sldev@catznip.com) Date: Mon Jul 9 07:29:11 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <468EF56A.9000400@dzonux.net> References: <468EF56A.9000400@dzonux.net> Message-ID: <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> I thought of a few problem points right when I read the proposal, but no one else seemed to raise them thus far so here goes: * it doesn't take into account that not everyone has unmetered data transfer. If it's enabled by default, those people are going to unknowingly waste a rather limited resource that has the potential to either get them in trouble with their ISP, or to receive a higher ISP bill due to increased transfer. There's no way to detect this, and you can't reasonably expect everyone to know or even understand, so the default for any peer should be that it *won't* participate in uploads. * there's no reliable way to determine available upstream bandwidth, nor is it really a constant depending on what other applications someone has running while they're on SL; if the P2P saturates the upstream, their SL experience is going to degrade immensely. No matter how small a number get picked by default, the bandwidth isn't guaranteed to be available. * there's no guarantee that downloading from peers is going to be any faster than downloading through the sim (someone suggested that downloading should go entirely through peers). Given that the average peer will be most likely be a low-bandwidth (for upstream) connection, chances are it will be slower, especially if the route from peer to peer is congested or suddenly unavailable and it has to time-out * are there any legal issues? What happens if a texture is being infringed upon and someone overzealous decides to subpoena everyone who is distributing the texture, or worse, if the textures are highly illegal pictures. The liability doesn't just have to be remote or theoretical, it has to be non-existent since no one but LL can claim a common carrier status * clueless on this one, but what happens to the low, medium and full detail texture "streaming" we currently have? Torrents download pieces randomly as far as I know. I don't mean to be critical, but it doesn't seem like any of the above is taken into consideration and it's being debated without there being any actual need or practical purpose. Kitty From tateru.nino at gmail.com Mon Jul 9 07:32:32 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jul 9 07:32:41 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> Message-ID: <46924700.9000307@gmail.com> You could overload the class methods, but it still might not play well in the preconstruction phase or destruction. You can try abstracting it all through a pointer or a reference off into 'untainted' portions of the text segment. Dirk Moerenhout wrote: > I just thought of the fact that static there isn't the point. It's > outside scope of a class so it's there to limit the var to the file. I > should really polish up my C++ :-) > > It doesn't make things easier as I still don't see how a simple change > can solve the issue. You need the correct arch to be enabled or the > class will not be compiled with the correct code. What if you make > descendant classes and overload the functions instead? > > I'm starting to remember why I'm not fond of OO :) > > Dirk aka Blakar Ogre > > On 7/9/07, Dirk Moerenhout wrote: >> Well I already noted in a previous mail I wasn't convinced that it >> would be safe to do it this way as everything you include gets handled >> with the same architecture. So you really need to go over all your >> includes in there and look what exactly you are doing and what the >> global impact will be. >> >> I guess the issue is that we have this: >> static LLV4Matrix4 sJointMat[32]; >> >> That initialisation will probably use SSE. >> >> You can't just move that elsewhere because then no SSE code would be >> generated (as there's #if LL_VECTORIZE in there). >> >> Tricky :) I suppose you can drop the static but it'll likely have >> performance impact and I'm not sure it's enough to stop MSVC from >> bleeding SSE instructions over to unexpected areas. >> >> Dirk aka Blakar Ogre >> >> >> On 7/9/07, Nicholaz Beresford wrote: >> > >> > Dunno if it's true, but if it is (and this guy sounds like >> > he knows what he's talking about), it's a definite "OUCH!" >> > and explains a lot of reports about crashing on startup. >> > >> > https://jira.secondlife.com/browse/VWR-1610 >> > >> > >> > >> > >> > Nick >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From tateru.nino at gmail.com Mon Jul 9 07:38:56 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jul 9 07:39:03 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> References: <468EF56A.9000400@dzonux.net> <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> Message-ID: <46924880.6090502@gmail.com> sldev@catznip.com wrote: > I thought of a few problem points right when I read the proposal, but no one > else seemed to raise them thus far so here goes: > > * it doesn't take into account that not everyone has unmetered data > transfer. If it's enabled by default, those people are going to unknowingly > waste a rather limited resource that has the potential to either get them in > trouble with their ISP, or to receive a higher ISP bill due to increased > transfer. > There's no way to detect this, and you can't reasonably expect everyone to > know or even understand, so the default for any peer should be that it > *won't* participate in uploads. > I'm on metered bandwidth - that said, there's another SLer in the house whose cache it would be nice to share, which is why I originally proposed an ICP-style optional cache interconnect system. > * there's no reliable way to determine available upstream bandwidth, nor is > it really a constant depending on what other applications someone has > running while they're on SL; if the P2P saturates the upstream, their SL > experience is going to degrade immensely. No matter how small a number get > picked by default, the bandwidth isn't guaranteed to be available. > My outbound bandwith is 4% of my inbound bandwidth. I've got 10Mbps coming in, but a little under 512Kbps going out, and yes, filling that up degrades things _severely_. > * there's no guarantee that downloading from peers is going to be any faster > than downloading through the sim (someone suggested that downloading should > go entirely through peers). Given that the average peer will be most likely > be a low-bandwidth (for upstream) connection, chances are it will be slower, > especially if the route from peer to peer is congested or suddenly > unavailable and it has to time-out > Although it _would_ reduce the time/memory consumption on simulators, even if it's no faster. > * are there any legal issues? What happens if a texture is being infringed > upon and someone overzealous decides to subpoena everyone who is > distributing the texture, or worse, if the textures are highly illegal > pictures. The liability doesn't just have to be remote or theoretical, it > has to be non-existent since no one but LL can claim a common carrier status > Whew. This has happened before - I believe the case is still in court after nearly 8 years. > * clueless on this one, but what happens to the low, medium and full detail > texture "streaming" we currently have? Torrents download pieces randomly as > far as I know. > It doesn't have to be torrent style, it can be straight HTTP or packeted llsd or any other arbitrary entity encapsulation. > I don't mean to be critical, but it doesn't seem like any of the above is > taken into consideration and it's being debated without there being any > actual need or practical purpose. > > Kitty > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Tateru Nino http://dwellonit.blogspot.com/ From robin.cornelius at gmail.com Mon Jul 9 07:42:13 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jul 9 07:42:16 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <46924700.9000307@gmail.com> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> Message-ID: On 7/9/07, Tateru Nino wrote: > You could overload the class methods, but it still might not play well > in the preconstruction phase or destruction. > You can try abstracting it all through a pointer or a reference off into > 'untainted' portions of the text segment. Hi everyone, Sorry to jump in on the discussion, i have not made my self know before. Hello If we go down this type of route do we not end up with effectivly twice the binary after compile one lot with SSE enabled one lot without and some bootstrap code (non SSE) either runs the SSE or non SSE versions much in the same way the mac executables can contain two different versions of executables for different processor architectures. What worries me here is unless the split is very clean it may be uncertain where the code is jumping to and you could easily end up in a situation where you are hitting a mix of the SSE and non SSE functions due to simple mistakes or omissions. Would it be easier rather than making complex auto detection code, to simply distribute two versions with and without SSE enabled? It should be trival to batch build different versions in visual studio with different build options. May be if we want to be clever the/an installer can detect the SSE capability and then download the correct file. -- Robin Cornelius http://www.byteme.org.uk From gigstaggart at gmail.com Mon Jul 9 07:46:55 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 9 07:47:16 2007 Subject: [sldev] Opening the server source? In-Reply-To: <28B2E923-31D8-41E7-8F34-3DA087B0624C@lindenlab.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> <468AEC3E.3000208@gwala.net> <28B2E923-31D8-41E7-8F34-3DA087B0624C@lindenlab.com> Message-ID: <46924A5F.7090800@gmail.com> Jim Purbrick (Babbage) wrote: > Actually, the first C# scripts ran on SL simulators about 18 months ago, > but that's because they were scripts I wrote and so trusted. As Adam > says, being able to securely run untrusted scripts written in arbitrary > languages is the tricky bit. Our microthreading injector can whitelist Why do you need to set the target that high? Just put compiling onto the server side for now, and only compile LSL. The client can just run a very basic syntactic check before uploading the source code. I think most people would have very happy to see "fast LSL" sooner, rather than "arbitrary assemblies from arbitrary languages" much much (much) later. Taking this step doesn't preclude allowing arbitrary languages in the future, and would go a very long way to help the situation in the shorter term. Not to mention, it would be a good way to get the bugs worked out of the basic system, prior to introducing the complexities of code compiled in outside environments. -Jason From adam at gwala.net Mon Jul 9 07:53:39 2007 From: adam at gwala.net (Adam Frisby) Date: Mon Jul 9 07:54:07 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46924A5F.7090800@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> <468AEC3E.3000208@gwala.net> <28B2E923-31D8-41E7-8F34-3DA087B0624C@lindenlab.com> <46924A5F.7090800@gmail.com> Message-ID: <46924BF3.4040406@gwala.net> AFAIK the problem is still with migrating the data efficiently across regions and a few other things like that. Adam Jason Giglio wrote: > Jim Purbrick (Babbage) wrote: > >> Actually, the first C# scripts ran on SL simulators about 18 months >> ago, but that's because they were scripts I wrote and so trusted. As >> Adam says, being able to securely run untrusted scripts written in >> arbitrary languages is the tricky bit. Our microthreading injector can >> whitelist > > > Why do you need to set the target that high? Just put compiling onto > the server side for now, and only compile LSL. The client can just run > a very basic syntactic check before uploading the source code. > > I think most people would have very happy to see "fast LSL" sooner, > rather than "arbitrary assemblies from arbitrary languages" much much > (much) later. > > Taking this step doesn't preclude allowing arbitrary languages in the > future, and would go a very long way to help the situation in the > shorter term. > > Not to mention, it would be a good way to get the bugs worked out of the > basic system, prior to introducing the complexities of code compiled in > outside environments. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blakar at gmail.com Mon Jul 9 07:54:49 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 9 07:54:52 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> Message-ID: <7992d0d60707090754naf954e1k1da8d453d9c288aa@mail.gmail.com> Well apparently in this case the goal is also to test, on the run, whether SSE is really faster. In that way CPU's with lousy SSE can still revert to a faster simple version. So even for SSE CPU's we need the non-SSE code. Off course splitting the binaries is easiest once we start to have many CPU specific optimisations. But I had the impression during a previous discussion that this was not wanted. Given the size of an exe and how big a bootstrap exe would be I think it would actually be not such a bad idea to distribute a single download that detects CPU and starts the correct client. Or off course an installer that downloads the correct version from the net. Dirk aka Blakar Ogre > Would it be easier rather than making complex auto detection code, to > simply distribute two versions with and without SSE enabled? It should > be trival to batch build different versions in visual studio with > different build options. May be if we want to be clever the/an > installer can detect the SSE capability and then download the correct > file. > > -- > Robin Cornelius > http://www.byteme.org.uk > From simon.nolan at gaylifesl.com Mon Jul 9 07:56:56 2007 From: simon.nolan at gaylifesl.com (Simon Nolan) Date: Mon Jul 9 07:57:00 2007 Subject: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <17CD14B1-8C2A-402C-99C1-90227E244372@gaylifesl.com> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> <1183938329.19854.4.camel@localhost> <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> <46919AA5.5030904@dzonux.net> <17CD14B1-8C2A-402C-99C1-90227E244372@gaylifesl.com> Message-ID: <2C618157-02CE-4391-A117-500AF3319F88@gaylifesl.com> On Jul 8, 2007, at 10:17P, Dzonatas wrote: > I just backed-out of thinking-out the "patched" sculpties with a > specialized tile method on the DWT. Right now the alpha layer is > not being used, and it could easily be used to create arbitrary > sized sculpt patches. It may be hard to compute on the physics > side, but it occurred to me that the SLSquid idea allows sculpties > of even 1024x1024 detail.... or greater! > > Hasn't Qarl mentioned before that one possible use for the alpha channel is for flexi-sculpties? I'd be hesitant about rushing to implement a different use without checking to see if it conflicts with something LL may (or may not) already have planned. [gak! resending because if forgot to cc the list.] From dzonatas at dzonux.net Mon Jul 9 08:00:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 08:00:24 2007 Subject: 1024x1024 sculpties Re: [sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <8a1bfe660707082105o836a84bm32db9a14c1bbac38@mail.gmail.com> References: <468F9F39.4060707@dzonux.net> <20070707143358.GF3868@bruno.sbruno> <1183848038.16828.15.camel@localhost> <7992d0d60707071614n7171729ap74b9ba13cfab5d8@mail.gmail.com> <1183938329.19854.4.camel@localhost> <7992d0d60707081657v50404455t77d4731d0d6bae18@mail.gmail.com> <46919AA5.5030904@dzonux.net> <8a1bfe660707082105o836a84bm32db9a14c1bbac38@mail.gmail.com> Message-ID: <46924D85.6000500@dzonux.net> heh... not when you look at the detail like on: http://www.mudbox3d.com/ Implemented right this moment for everybody... no... Allow for it so that it can be done.... yes... Laurent Laborde wrote: > On 7/9/07, Dzonatas wrote: >> sculpties of even 1024x1024 detail.... or greater! > > Insane. > -- Power to Change the Void From nicholaz at blueflash.cc Mon Jul 9 08:04:44 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 08:04:53 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> Message-ID: <46924E8C.9050009@blueflash.cc> Robin Cornelius wrote: > architectures. What worries me here is unless the split is very clean > it may be uncertain where the code is jumping to and you could easily > end up in a situation where you are hitting a mix of the SSE and non > SSE functions due to simple mistakes or omissions. Yes, "worry" was exactly the word to describe my feelings when I first saw the code to auto-sample, store the results in a persistent config, having three files with essentially the same code ... and that was even before I noticed the intricacies of the VWR-1610 problem. Don't get me wrong, I'm not trying to be smart here. I would have run into exactly the same error as VWR-1610, I would not have thought of the implications. And since, as it seems, nobody at LL noticed it either, and Dzon also didn't notice it, it's clear for me that this type of solution is far outside the scope of a manageable solution. Again, I'm not pointing fingers, nor saying that people should have noticed. I would have run headlong into this crash (and I know C++ inside out), except for the fact that I would not have tried this, because have a gut feeling about where my limits are and what kinds of constructs are calling for trouble (especially with a user base as big as Linden Lab's). I have already seen a few samples of code in the viewer already, where pushing the limits of OO has resulted in problems of the whole variety (from inconsequential to disastrous). What worries me most is that a change like this is rolled out without mention in the changes, not with a note like "well, we're trying something daring which might cause speed benefit long term, but also trouble, but you can roll back and please let us know about any problems". Either nobody was aware that it might cause trouble, or it slipped into 1.17.3 accidentally or it was just performed as a silent experient ... and I'm not sure which of those alternatives is worse. Nick From babbage at lindenlab.com Mon Jul 9 08:12:30 2007 From: babbage at lindenlab.com (Jim Purbrick (Babbage)) Date: Mon Jul 9 08:13:27 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46924A5F.7090800@gmail.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> <468AEC3E.3000208@gwala.net> <28B2E923-31D8-41E7-8F34-3DA087B0624C@lindenlab.com> <46924A5F.7090800@gmail.com> Message-ID: <337981E7-F33F-4823-B5BB-970B5BFE0A12@lindenlab.com> > Why do you need to set the target that high? Just put compiling > onto the server side for now, and only compile LSL. The client can > just run a very basic syntactic check before uploading the source > code. That is exactly the plan. > I think most people would have very happy to see "fast LSL" sooner, > rather than "arbitrary assemblies from arbitrary languages" much > much (much) later. Yes. > Taking this step doesn't preclude allowing arbitrary languages in > the future, and would go a very long way to help the situation in > the shorter term. Correct. > Not to mention, it would be a good way to get the bugs worked out > of the basic system, prior to introducing the complexities of code > compiled in outside environments. Indeed. Cheers, Jim/Babbage From simon.nolan at gaylifesl.com Mon Jul 9 08:19:26 2007 From: simon.nolan at gaylifesl.com (Simon Nolan) Date: Mon Jul 9 08:19:31 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <46924880.6090502@gmail.com> References: <468EF56A.9000400@dzonux.net> <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> <46924880.6090502@gmail.com> Message-ID: On Jul 9, 2007, at 10:38A, Tateru Nino wrote: > sldev@catznip.com wrote: >> I thought of a few problem points right when I read the proposal, >> but no one >> else seemed to raise them thus far so here goes: >> >> * it doesn't take into account that not everyone has unmetered data >> transfer. If it's enabled by default, those people are going to >> unknowingly >> waste a rather limited resource that has the potential to either >> get them in >> trouble with their ISP, or to receive a higher ISP bill due to >> increased >> transfer. >> There's no way to detect this, and you can't reasonably expect >> everyone to >> know or even understand, so the default for any peer should be >> that it >> *won't* participate in uploads. >> > I'm on metered bandwidth - that said, there's another SLer in the > house > whose cache it would be nice to share, which is why I originally > proposed an ICP-style optional cache interconnect system. >> * there's no reliable way to determine available upstream >> bandwidth, nor is >> it really a constant depending on what other applications someone has >> running while they're on SL; if the P2P saturates the upstream, >> their SL >> experience is going to degrade immensely. No matter how small a >> number get >> picked by default, the bandwidth isn't guaranteed to be available. >> > My outbound bandwith is 4% of my inbound bandwidth. I've got 10Mbps > coming in, but a little under 512Kbps going out, and yes, filling that > up degrades things _severely_. I made a similar observation in the first thread Dzonatas created. The only thing I can think of is an upload bandwidth slider in preferences. Some other P2P systems let the user set uploads per peer and an overall bandwidth. I'm not crazy about stuffing Yet Another Control(TM) in Preferences, though. >> * there's no guarantee that downloading from peers is going to be >> any faster >> than downloading through the sim (someone suggested that >> downloading should >> go entirely through peers). Given that the average peer will be >> most likely >> be a low-bandwidth (for upstream) connection, chances are it will >> be slower, >> especially if the route from peer to peer is congested or suddenly >> unavailable and it has to time-out >> > Although it _would_ reduce the time/memory consumption on simulators, > even if it's no faster. Just in my limited understanding, it seems like the only time it could be faster is if there were a lot of peers sharing. That's what I was thinking in my post in the other thread about using the list of avatars in the sim as your peer list. It seems like, bandwidth aside, that would be a pretty straightforward way to do it, and at the same time maybe help resolve one lag issue in busy sims. If you're the only avatar in a sim, then you get your textures from the asset server as usual -- and that's when you don't need P2P nearly as bad. >> * are there any legal issues? What happens if a texture is being >> infringed >> upon and someone overzealous decides to subpoena everyone who is >> distributing the texture, or worse, if the textures are highly >> illegal >> pictures. The liability doesn't just have to be remote or >> theoretical, it >> has to be non-existent since no one but LL can claim a common >> carrier status >> > Whew. This has happened before - I believe the case is still in court > after nearly 8 years. Oh my! That could be very sticky, especially if my client peers with someone in a country where certain content is illegal, but isn't here. >> * clueless on this one, but what happens to the low, medium and >> full detail >> texture "streaming" we currently have? Torrents download pieces >> randomly as >> far as I know. >> > It doesn't have to be torrent style, it can be straight HTTP or > packeted > llsd or any other arbitrary entity encapsulation. I'm thinking torrent-style is seeming less and less like the best way to share textures. >> I don't mean to be critical, but it doesn't seem like any of the >> above is >> taken into consideration and it's being debated without there >> being any >> actual need or practical purpose. >> >> Kitty >> > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > Simon From dzonatas at dzonux.net Mon Jul 9 08:21:38 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 08:21:44 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <46924E8C.9050009@blueflash.cc> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> <46924E8C.9050009@blueflash.cc> Message-ID: <46925282.3060405@dzonux.net> From what I read on the jira issue and in these mails, it sounds like the gSysCPU.hasSSE() doesn't return the correct result for AMD processors. Nicholaz Beresford wrote: > > Robin Cornelius wrote: >> architectures. What worries me here is unless the split is very clean >> it may be uncertain where the code is jumping to and you could easily >> end up in a situation where you are hitting a mix of the SSE and non >> SSE functions due to simple mistakes or omissions. > > Yes, "worry" was exactly the word to describe my feelings when I first > saw the code to auto-sample, store the results in a persistent config, > having three files with essentially the same code ... and that was even > before I noticed the intricacies of the VWR-1610 problem. > > Don't get me wrong, I'm not trying to be smart here. I would have run > into exactly the same error as VWR-1610, I would not have thought of > the implications. And since, as it seems, nobody at LL noticed it > either, and Dzon also didn't notice it, it's clear for me that this > type of solution is far outside the scope of a manageable solution. > > Again, I'm not pointing fingers, nor saying that people should have > noticed. I would have run headlong into this crash (and I know C++ > inside out), except for the fact that I would not have tried this, > because have a gut feeling about where my limits are and what kinds > of constructs are calling for trouble (especially with a user base > as big as Linden Lab's). > > I have already seen a few samples of code in the viewer already, where > pushing the limits of OO has resulted in problems of the whole variety > (from inconsequential to disastrous). > > > What worries me most is that a change like this is rolled out without > mention in the changes, not with a note like "well, we're trying > something daring which might cause speed benefit long term, but also > trouble, but you can roll back and please let us know about any > problems". > > Either nobody was aware that it might cause trouble, or it slipped > into 1.17.3 accidentally or it was just performed as a silent > experient ... and I'm not sure which of those alternatives is worse. > > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From nicholaz at blueflash.cc Mon Jul 9 08:27:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 08:27:40 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <7992d0d60707090754naf954e1k1da8d453d9c288aa@mail.gmail.com> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> <7992d0d60707090754naf954e1k1da8d453d9c288aa@mail.gmail.com> Message-ID: <469253E2.4060708@blueflash.cc> Dirk Moerenhout wrote: > Off course splitting the binaries is easiest once we start > to have many CPU specific optimisations. Well, I don't want to rain on the parade of the optimizers, but in my opinion the state of the viewer source is nowhere near a point where CPU specific optimization like this make any sense. There are hundreths of GUI glitches. I am receiving (from a mere 1000 users, who even have to ZIP and mail them by hand) more crash reports every day than what I get from my own whole line of software within a years. I am so royally flabbergasted about this particular issues, probably because it highlights so dramatically what is wrong with managing this piece of software, that I can't even begin to describe it ... Nick From nicholaz at blueflash.cc Mon Jul 9 08:32:00 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 08:32:07 2007 Subject: [Fwd: Re: [sldev] SSE2 / Ouch] Message-ID: <469254F0.70607@blueflash.cc> Dzon says: > From what I read on the jira issue and in these mails, it sounds like > the gSysCPU.hasSSE() doesn't return the correct result for AMD > processors. From the way I read it (the JIRA and what Dirk says), there's code executed through constructors of global objects, long before the crt startup code even thinks about calling main()/WinMain(). Either that, or you rely on gSysCPU being istantiated globally before those other global or static objects ... Nick From robin.cornelius at gmail.com Mon Jul 9 08:41:04 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jul 9 08:41:06 2007 Subject: [Fwd: Re: [sldev] SSE2 / Ouch] In-Reply-To: <469254F0.70607@blueflash.cc> References: <469254F0.70607@blueflash.cc> Message-ID: On 7/9/07, Nicholaz Beresford wrote: > > Dzon says: > > From what I read on the jira issue and in these mails, it sounds like > > the gSysCPU.hasSSE() doesn't return the correct result for AMD > > processors. > > From the way I read it (the JIRA and what Dirk says), there's code > executed through constructors of global objects, long before the > crt startup code even thinks about calling main()/WinMain(). > > Either that, or you rely on gSysCPU being istantiated globally > before those other global or static objects ... > In this case could somthing like the following be done (note I'm just digging in so I suspect practacly this is hard due to what i hear about the code base). Don't have global objects per say, have a CGlobal for example that contains everything else then you can build two versions of CGlobal as well with and without SSE and simply have one global pointer CGlobal * plobal; You shouldn;t get any early initalisation cause no global stuff will exist untill a new GGlobal or a new CGlobal_sse is created (i hope). As for your previous comment, yes I too would have fallen for this trap and it *seemed* like the right thing to do at the time -- Robin Cornelius http://www.byteme.org.uk From jef at pleiades.ca Mon Jul 9 09:04:42 2007 From: jef at pleiades.ca (Jonathan Freedman) Date: Mon Jul 9 09:04:51 2007 Subject: [sldev] Opening the server source? In-Reply-To: <337981E7-F33F-4823-B5BB-970B5BFE0A12@lindenlab.com> References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> <46899C82.1000404@dzonux.net> <2925011a0707030646h29102077g41ae7dff983a9f19@mail.gmail.com> <468AEC3E.3000208@gwala.net> <28B2E923-31D8-41E7-8F34-3DA087B0624C@lindenlab.com> <46924A5F.7090800@gmail.com> <337981E7-F33F-4823-B5BB-970B5BFE0A12@lindenlab.com> Message-ID: <46925C9A.5030202@pleiades.ca> Hey Babbage, When do we get the sacrificial mono island where we can drop our current LSL-enabled objects into a volcano (or other such symbolism) and see how they run? I sense the 1.18 changes ( and the ensuing step towards het grid) makes this a little more practical. Cheers Jonathan Freedman / otakup0pe Neumann VP Operations Pleiades Consulting Jim Purbrick (Babbage) wrote: >> Why do you need to set the target that high? Just put compiling onto >> the server side for now, and only compile LSL. The client can just >> run a very basic syntactic check before uploading the source code. > > That is exactly the plan. > >> I think most people would have very happy to see "fast LSL" sooner, >> rather than "arbitrary assemblies from arbitrary languages" much much >> (much) later. > > Yes. > >> Taking this step doesn't preclude allowing arbitrary languages in the >> future, and would go a very long way to help the situation in the >> shorter term. > > Correct. > >> Not to mention, it would be a good way to get the bugs worked out of >> the basic system, prior to introducing the complexities of code >> compiled in outside environments. > > Indeed. > > Cheers, > > Jim/Babbage > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Mon Jul 9 09:11:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 09:11:54 2007 Subject: [Fwd: Re: [sldev] SSE2 / Ouch] In-Reply-To: <469254F0.70607@blueflash.cc> References: <469254F0.70607@blueflash.cc> Message-ID: <46925E49.9000002@dzonux.net> Actually, I'm not fond of the C++ auto-initialized global constructors. There is no way to tell in source code when they are executed and in what order. (See: VWR-225 and https://wiki.secondlife.com/wiki/Bug_triage/2007-06-11 where such movement to fix it went stale) They are good for debug code, but that is about it. All intentional globals should be constructed explicitly within main() or likewise; otherwise, it is a chaotic startup. Even so, I still doubt there actually is stray SSE code unless someone enabled "whole program optimization", which was off. Most of this is beyond what the original contract wanted me to do. We did research it to find out what other changes need to be made. The heuristic step added in made it so we could avoid a lot of other changes. SO..... What's left is that there is the possibility that LLV4Matrix4 globals being initialized with SSE code on non-SSE CPUs. It looks like VWR-225 would have helped avoid this, but I was being told that I wasted their time. (...hunger strike continues) Nicholaz Beresford wrote: > > Dzon says: > > From what I read on the jira issue and in these mails, it sounds like > > the gSysCPU.hasSSE() doesn't return the correct result for AMD > > processors. > > From the way I read it (the JIRA and what Dirk says), there's code > executed through constructors of global objects, long before the > crt startup code even thinks about calling main()/WinMain(). > > Either that, or you rely on gSysCPU being istantiated globally > before those other global or static objects ... > > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From dzonatas at dzonux.net Mon Jul 9 09:34:47 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 09:34:49 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: References: <468EF56A.9000400@dzonux.net> <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> <46924880.6090502@gmail.com> Message-ID: <469263A7.5020008@dzonux.net> Simon Nolan wrote: > > On Jul 9, 2007, at 10:38A, Tateru Nino wrote: > >> sldev@catznip.com wrote: > [...] >>> * are there any legal issues? What happens if a texture is being >>> infringed >>> upon and someone overzealous decides to subpoena everyone who is >>> distributing the texture, or worse, if the textures are highly illegal >>> pictures. The liability doesn't just have to be remote or >>> theoretical, it >>> has to be non-existent since no one but LL can claim a common >>> carrier status >>> >> Whew. This has happened before - I believe the case is still in court >> after nearly 8 years. > > Oh my! That could be very sticky, especially if my client peers with > someone in a country where certain content is illegal, but isn't here. ... As the licenses and term of service currently are, there really is no reason to hold it up in court. What is uploaded to LL is sharable. That doesn't state that you can just use the shared textures in any publication, but being that a service that extends the original functionality of LL is not illegal. That type of extension in service has been done since day one of the Internet. > >>> * clueless on this one, but what happens to the low, medium and full >>> detail >>> texture "streaming" we currently have? Torrents download pieces >>> randomly as >>> far as I know. >>> >> It doesn't have to be torrent style, it can be straight HTTP or packeted >> llsd or any other arbitrary entity encapsulation. > > I'm thinking torrent-style is seeming less and less like the best way > to share textures. > ... The overall idea is a bit more clear I hope. If it is easy as just an extra install for the squid setup and an extra button in SL's preferences to enable "reverse proxy," we'll see what we can do to keep it that simple. If you don't enable "reverse proxy" in the SL viewer (or likewise), then SLSquid would just act like a forward proxy... an extra cache... without all the other features spoken about. These are still "would" type statements. I want a proof-of-concept and go from there. -- Power to Change the Void From matthew.dowd at hotmail.co.uk Mon Jul 9 09:40:56 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jul 9 09:40:59 2007 Subject: [Fwd: Re: [sldev] SSE2 / Ouch] Message-ID: > As for your previous comment, yes I too would have fallen for this > trap and it *seemed* like the right thing to do at the time Ditto, but it does call into question LL's QA procedures which should have caught this? (and that purple object say text ;-) Matthew _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From bos at lindenlab.com Mon Jul 9 09:41:10 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jul 9 09:41:13 2007 Subject: [sldev] Collection of JIRAs suitable for open source In-Reply-To: <468E67C7.4040008@blueflash.cc> References: <468E67C7.4040008@blueflash.cc> Message-ID: <46926526.60103@lindenlab.com> Nicholaz Beresford wrote: > > I just created a JIRA to serve as a link list to issues that > lend themselves to be solved by open sourcers. Great idea, thanks! References: Message-ID: <46926DC0.6010505@blueflash.cc> Matthew Dowd wrote: >> As for your previous comment, yes I too would have fallen for this >> trap and it *seemed* like the right thing to do at the time > > Ditto, but it does call into question LL's QA procedures which should > have caught this? (and that purple object say text ;-) Btw, I just think I glimpsed in 1.18 that the "say" was fixed but the purple was not (unless the purple was fixed in a different way, I just saw that the patch file still went through for the "yellow" hunk ... didn't look into it any deeper). Nick From josh at lindenlab.com Mon Jul 9 10:41:42 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jul 9 10:39:44 2007 Subject: [Fwd: Re: [sldev] SSE2 / Ouch] In-Reply-To: <46926DC0.6010505@blueflash.cc> References: <46926DC0.6010505@blueflash.cc> Message-ID: <46927356.80008@lindenlab.com> Nicholaz Beresford wrote: > Matthew Dowd wrote: >>> As for your previous comment, yes I too would have fallen for this >>> trap and it *seemed* like the right thing to do at the time >> >> Ditto, but it does call into question LL's QA procedures which should > > have caught this? (and that purple object say text ;-) > > Btw, I just think I glimpsed in 1.18 that the "say" was fixed > but the purple was not (unless the purple was fixed in a different > way, I just saw that the patch file still went through for the > "yellow" hunk ... didn't look into it any deeper). A fix for the "say, " infix on messages went into 1.17.3.0 and 1.18.0.4. A change to the default color for llOwnerSay messages is in internal testing now. SVC-371 (should be a VWR one) covers both issues, although the first was found/fixed before that issue was filed. From dale at daleglass.net Mon Jul 9 10:55:33 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Mon Jul 9 10:55:39 2007 Subject: [sldev] Created wiki page on redistribution Message-ID: <20070709175533.GA11981@bruno.sbruno> I made a wiki page for listing various files that need to be shipped with SL, and their redistribution status: https://wiki.secondlife.com/wiki/Redistribution I've done some checking and this seems to be correct to me, but I'd like to have a second opinion on that. Also, has LL made any statement on the redistribution of modified viewers? Such as, is there any artwork that can't be shipped, should anything be changed, etc? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070709/85d74b38/attachment.pgp From dzonatas at dzonux.net Mon Jul 9 10:59:10 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 10:59:11 2007 Subject: [sldev] llviewerjointmesh_sse2.cpp Message-ID: <4692776E.1010406@dzonux.net> I've had this file in my repository for awhile. It's been tested under conditions without cache pollution and has shown to be 10x faster under such conditions. It exploits the cache pollution problem, however. Under the many threads that run under Second Life that create the cache pollution, the speed of this code becomes really limited. (back to the version found in 1.18 release) It doesn't use globals. [See VWR-1610] Note, this was tested with the older version of the viewer, may need to adjust something. (then again...may not.) =) -- Power to Change the Void -------------- next part -------------- /** * @file llviewerjointmesh_sse2.cpp * @brief LLV4 class implementation with LLViewerJointMesh class * * Copyright (c) 2007, Linden Research, Inc. * License: GPLv3 -- http://www.gnu.org/copyleft/gpl.html */ //----------------------------------------------------------------------------- // Header Files //----------------------------------------------------------------------------- // Do not use precompiled headers, because we need to build this file with // SSE support, but not the precompiled header file. JC #include "linden_common.h" #include "llviewerjointmesh.h" // project includes #include "llface.h" #include "llpolymesh.h" // library includes #include "lldarray.h" #include "llstrider.h" #include "llv4matrix4.h" #include "m4math.h" #include "v3math.h" // *NOTE: SSE2 must be enabled for this module #if LL_VECTORIZE #include "emmintrin.h" #if LL_MSVC #pragma warning( disable : 4701 ) // "potentially uninitialized local variable" -- disabled #endif inline V4F32 llv4lerp(V4F32 a, V4F32 b, V4F32 w) { return _mm_add_ps(a, _mm_mul_ps(_mm_sub_ps(b, a), w)); // a + ( b - a ) * w } //----------------------------------------------------------------------- //----------------------------------------------------------------------- // LLV4Matrix3dx4 //----------------------------------------------------------------------- //----------------------------------------------------------------------- U32 lerp_comps = 0; U32 vert_comps = 0; U32 lerp_bits = 0; // NOTE: LLV4Matrix3dx4 is specially designed to swizzle XYZ data streams. LL_LLV4MATH_ALIGN_PREFIX class LLV4Matrix3dx4 { public: union { F32 mArray[4*4*4]; F32 mRow[4][4*4]; __m64 mRow_i64[4][4*2]; __m128i mRow_i128[4][4]; struct { V4F32 xx, xy, xz, xw; V4F32 yx, yy, yz, yw; V4F32 zx, zy, zz, zw; V4F32 wx, wy, wz, ww; }; }; void load4VectorsAndTranspose(const LLVector3* a); void packRowX(); void packRowY(); void packRowZ(); void packRowW(); void packRows(); void unpackRowW(); } LL_LLV4MATH_ALIGN_POSTFIX; #define mmShuffle(d,s,d1,d2,s3,s4) _mm_shuffle_ps(d,s,_MM_SHUFFLE(s4,s3,d2,d1)) inline void LLV4Matrix3dx4::load4VectorsAndTranspose(const LLVector3* a) { const V4F32 sx = _mm_loadu_ps((float*)a+0); const V4F32 sy = _mm_loadu_ps((float*)a+4); const V4F32 sz = _mm_loadu_ps((float*)a+8); // {sx,sy,sz} = { x1 y1 z1 x2, y2 z2 x3 y3, z3 x4 y4 z4 } xx = mmShuffle(sx,sx,0,0,0,3); // xx = { x1 x1 x1 x2 } xy = mmShuffle(xx,sy,3,3,2,2); // xy = { x2 x2 x3 x3 } xz = mmShuffle(xy,sz,2,2,1,1); // xz = { x3 x4 x4 x4 } xz = mmShuffle(xz,xz,0,2,2,3); yx = mmShuffle(sx,sy,1,1,0,0); // yx = { y1 y1 y1 y2 } yx = mmShuffle(yx,yx,0,1,1,3); yy = mmShuffle(yx,sy,3,3,3,3); // yy = { y2 y2 y3 y3 } yz = mmShuffle(yy,sz,3,3,2,2); // yz = { y3 y4 y4 y4 } yz = mmShuffle(yz,yz,0,2,2,3); zx = mmShuffle(sx,sy,2,2,1,1); // zx = { z1 z1 z1 z2 } zx = mmShuffle(zx,zx,0,1,1,3); zy = mmShuffle(zx,sz,3,3,0,0); // zy = { z2 z2 z3 z3 } zz = mmShuffle(sz,sz,0,3,3,3); // zz = { z3 z4 z4 z4 } } inline void LLV4Matrix3dx4::packRowX() { V4F32 vt; vt = mmShuffle(xy,xx,0,1,2,3); xx = mmShuffle(xx,vt,0,1,2,0); xy = mmShuffle(xy,xz,1,2,0,1); vt = mmShuffle(xw,xz,0,3,2,2); xz = mmShuffle(vt,xw,2,0,1,2); } inline void LLV4Matrix3dx4::packRowY() { V4F32 vt; vt = mmShuffle(yy,yx,0,1,2,3); yx = mmShuffle(yx,vt,0,1,2,0); yy = mmShuffle(yy,yz,1,2,0,1); vt = mmShuffle(yw,yz,0,3,2,2); yz = mmShuffle(vt,yw,2,0,1,2); } inline void LLV4Matrix3dx4::packRowZ() { V4F32 vt; vt = mmShuffle(zy,zx,0,1,2,3); zx = mmShuffle(zx,vt,0,1,2,0); zy = mmShuffle(zy,zz,1,2,0,1); vt = mmShuffle(zw,zz,0,3,2,2); zz = mmShuffle(vt,zw,2,0,1,2); } inline void LLV4Matrix3dx4::packRowW() { V4F32 vt; vt = mmShuffle(wy,wx,0,1,2,3); wx = mmShuffle(wx,vt,0,1,2,0); wy = mmShuffle(wy,wz,1,2,0,1); vt = mmShuffle(ww,wz,0,3,2,2); wz = mmShuffle(vt,ww,2,0,1,2); } inline void LLV4Matrix3dx4::packRows() { packRowX(); packRowY(); packRowZ(); packRowW(); } inline void LLV4Matrix3dx4::unpackRowW() { ww = mmShuffle(wz,wz,1,2,3,0); wz = mmShuffle(wy,wz,2,3,0,0); wy = mmShuffle(wy,wx,0,1,3,0); wy = mmShuffle(wy,wy,2,0,1,0); } //----------------------------------------------------------------------- //----------------------------------------------------------------------- // LLV4Matrix3dx4 //----------------------------------------------------------------------- //----------------------------------------------------------------------- //--- //----------------------------------------------------------------------- //----------------------------------------------------------------------- // LLViewerJointMesh::updateGeometry() //----------------------------------------------------------------------- //----------------------------------------------------------------------- void update_geometry_sse2(LLFace *face, LLPolyMesh *mesh) { LLV4Matrix4 sJointMat[32]; //upload joint pivots/matrices { LLDynamicArray& joint_data = mesh->getReferenceMesh()->mJointRenderData; LLDynamicArray::const_iterator i = joint_data.begin(), iend = joint_data.end(); LLV4Matrix4* mat = &sJointMat[0]; LLJointRenderData* jd = *i; register V4F32 vw; const LLMatrix4* w; const LLVector3* v; for(; jd; ++mat) { w = jd->mWorldMatrix; if(jd->mSkinJoint) { v = &jd->mSkinJoint->mRootToJointSkinOffset; jd = ++i < iend ? *i : NULL; } else { v = &(jd = *++i)->mSkinJoint->mRootToParentJointSkinOffset; } if((unsigned)w & 0xF) { vw = _mm_loadu_ps(w->mMatrix[VW]); vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VX]), mat->mV[VX] = _mm_loadu_ps(w->mMatrix[VX]))); vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VY]), mat->mV[VY] = _mm_loadu_ps(w->mMatrix[VY]))); mat->mV[VW] = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VZ]), mat->mV[VZ] = _mm_loadu_ps(w->mMatrix[VZ]))); } else { vw = _mm_load_ps(w->mMatrix[VW]); vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VX]), mat->mV[VX] = _mm_load_ps(w->mMatrix[VX]))); vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VY]), mat->mV[VY] = _mm_load_ps(w->mMatrix[VY]))); mat->mV[VW] = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VZ]), mat->mV[VZ] = _mm_load_ps(w->mMatrix[VZ]))); } } } //update geometry { LLV4Matrix3dx4 m_verts; LLV4Matrix3dx4 m_norms; LLV4Matrix3dx4 m_lerps; struct vertex_buffer // *NOTE: relies on a specific vertex buffer structure { LLVector3 vertex; LLVector3 normal; }; LL_LLV4MATH_ALIGN_PREFIX union // aligned stack for manual loop vectorization { __m128i vp; struct { vertex_buffer* vb; const F32* weights; const LLVector3* coords; const LLVector3* normals; }; } LL_LLV4MATH_ALIGN_POSTFIX; U32 stride = (U32)face->mVertexBuffer->getStride(); vb = (vertex_buffer*)((U8*)face->mVertexBuffer->getMappedData() + stride * mesh->mFaceVertexOffset); weights = mesh->getWeights(); coords = mesh->getCoords(); normals = mesh->getNormals(); LLV4Vector3 vweights; LLV4Vector3 xweights; xweights.v = _mm_set1_ps(F32_MAX); vert_comps += mesh->getNumVertices(); U32 index = 0, index_end = mesh->getNumVertices(); __m128i vsz = _mm_setr_epi32(stride, sizeof(F32), sizeof(LLVector3), sizeof(LLVector3)); vsz = _mm_add_epi32(vsz,vsz); vsz = _mm_add_epi32(vsz,vsz); for(index = index_end/4+1; --index; vp = _mm_add_epi32(vp, vsz)) // index_end -= 4; // for(; index < index_end; index+=4, coords+=4, normals+=4, weights+=4, vb = (vertex_buffer*)((U8*)vb+stride*4)) { m_verts.load4VectorsAndTranspose(coords); m_norms.load4VectorsAndTranspose(normals); vweights.v = _mm_loadu_ps(weights); _mm_prefetch((char*)(coords+4),_MM_HINT_NTA); _mm_prefetch((char*)(coords+5),_MM_HINT_NTA); _mm_prefetch((char*)(coords+6),_MM_HINT_NTA); _mm_prefetch((char*)(normals+4),_MM_HINT_NTA); _mm_prefetch((char*)(normals+5),_MM_HINT_NTA); _mm_prefetch((char*)(normals+6),_MM_HINT_NTA); _mm_prefetch((char*)(weights+4),_MM_HINT_NTA); int r = _mm_movemask_ps(_mm_cmpeq_ps(vweights.v, xweights.v)); if(r!=0xF) { lerp_comps+=4; if(!(r&1)) { lerp_bits++; V4F32 vi = vweights.v; S32 joint = _mm_cvttss_si32(vi); vi = _mm_cvtsi32_ss(vi, joint); vi = _mm_sub_ps(vweights.v, vi); vi = mmShuffle(vi,vi,0,0,0,0); LLV4Matrix4* mat = &sJointMat[joint]; m_lerps.xx = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); m_lerps.yx = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); m_lerps.zx = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); m_lerps.wx = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); } if(vweights.mV[VY] == vweights.mV[VX]) { m_lerps.xy = m_lerps.xx; m_lerps.yy = m_lerps.yx; m_lerps.zy = m_lerps.zx; m_lerps.wy = m_lerps.wx; } else { lerp_bits++; V4F32 vi = vweights.v; vi = mmShuffle(vi,vi,1,1,1,1); S32 joint = _mm_cvttss_si32(vi); vi = _mm_cvtsi32_ss(vi, joint); vi = mmShuffle(vi,vi,0,0,0,0); vi = _mm_sub_ps(vweights.v, vi); vi = mmShuffle(vi,vi,1,1,1,1); LLV4Matrix4* mat = &sJointMat[joint]; m_lerps.xy = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); m_lerps.yy = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); m_lerps.zy = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); m_lerps.wy = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); } if(vweights.mV[VZ] == vweights.mV[VX]) { m_lerps.xz = m_lerps.xx; m_lerps.yz = m_lerps.yx; m_lerps.zz = m_lerps.zx; m_lerps.wz = m_lerps.wx; } else if(vweights.mV[VZ] == vweights.mV[VY]) { m_lerps.xz = m_lerps.xy; m_lerps.yz = m_lerps.yy; m_lerps.zz = m_lerps.zy; m_lerps.wz = m_lerps.wy; } else { lerp_bits++; V4F32 vi = vweights.v; vi = mmShuffle(vi,vi,2,2,2,2); S32 joint = _mm_cvttss_si32(vi); vi = _mm_cvtsi32_ss(vi, joint); vi = mmShuffle(vi,vi,0,0,0,0); vi = _mm_sub_ps(vweights.v, vi); vi = mmShuffle(vi,vi,2,2,2,2); LLV4Matrix4* mat = &sJointMat[joint]; m_lerps.xz = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); m_lerps.yz = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); m_lerps.zz = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); m_lerps.wz = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); } if(vweights.mV[VW] == vweights.mV[VX]) { m_lerps.xw = m_lerps.xx; m_lerps.yw = m_lerps.yx; m_lerps.zw = m_lerps.zx; m_lerps.ww = m_lerps.wx; } else if(vweights.mV[VW] == vweights.mV[VY]) { m_lerps.xw = m_lerps.xy; m_lerps.yw = m_lerps.yy; m_lerps.zw = m_lerps.zy; m_lerps.ww = m_lerps.wy; } else if(vweights.mV[VW] == vweights.mV[VZ]) { m_lerps.xw = m_lerps.xz; m_lerps.yw = m_lerps.yz; m_lerps.zw = m_lerps.zz; m_lerps.ww = m_lerps.wz; } else { lerp_bits++; V4F32 vi = vweights.v; vi = mmShuffle(vi,vi,3,3,3,3); S32 joint = _mm_cvttss_si32(vi); vi = _mm_cvtsi32_ss(vi, joint); vi = mmShuffle(vi,vi,0,0,0,0); vi = _mm_sub_ps(vweights.v, vi); vi = mmShuffle(vi,vi,3,3,3,3); LLV4Matrix4* mat = &sJointMat[joint]; m_lerps.xw = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); m_lerps.yw = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); m_lerps.zw = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); m_lerps.ww = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); } m_lerps.packRows(); xweights.v = vweights.v; } m_verts.wx = _mm_add_ps(_mm_add_ps(_mm_add_ps(_mm_mul_ps(m_verts.xx, m_lerps.xx), _mm_mul_ps(m_verts.yx, m_lerps.yx)), _mm_mul_ps(m_verts.zx, m_lerps.zx)),m_lerps.wx); m_verts.wy = _mm_add_ps(_mm_add_ps(_mm_add_ps(_mm_mul_ps(m_verts.xy, m_lerps.xy), _mm_mul_ps(m_verts.yy, m_lerps.yy)), _mm_mul_ps(m_verts.zy, m_lerps.zy)),m_lerps.wy); m_verts.wz = _mm_add_ps(_mm_add_ps(_mm_add_ps(_mm_mul_ps(m_verts.xz, m_lerps.xz), _mm_mul_ps(m_verts.yz, m_lerps.yz)), _mm_mul_ps(m_verts.zz, m_lerps.zz)),m_lerps.wz); m_norms.wx = _mm_add_ps(_mm_add_ps(_mm_mul_ps(m_norms.xx, m_lerps.xx), _mm_mul_ps(m_norms.yx, m_lerps.yx)), _mm_mul_ps(m_norms.zx, m_lerps.zx)); m_norms.wy = _mm_add_ps(_mm_add_ps(_mm_mul_ps(m_norms.xy, m_lerps.xy), _mm_mul_ps(m_norms.yy, m_lerps.yy)), _mm_mul_ps(m_norms.zy, m_lerps.zy)); m_norms.wz = _mm_add_ps(_mm_add_ps(_mm_mul_ps(m_norms.xz, m_lerps.xz), _mm_mul_ps(m_norms.yz, m_lerps.yz)), _mm_mul_ps(m_norms.zz, m_lerps.zz)); /* ((vertex_buffer*)((U8*)vb+stride*0))->vertex.setVec(&m_verts.mRow[VW][0]); ((vertex_buffer*)((U8*)vb+stride*1))->vertex.setVec(&m_verts.mRow[VW][3]); ((vertex_buffer*)((U8*)vb+stride*2))->vertex.setVec(&m_verts.mRow[VW][6]); ((vertex_buffer*)((U8*)vb+stride*3))->vertex.setVec(&m_verts.mRow[VW][9]); ((vertex_buffer*)((U8*)vb+stride*0))->normal.setVec(&m_norms.mRow[VW][0]); ((vertex_buffer*)((U8*)vb+stride*1))->normal.setVec(&m_norms.mRow[VW][3]); ((vertex_buffer*)((U8*)vb+stride*2))->normal.setVec(&m_norms.mRow[VW][6]); ((vertex_buffer*)((U8*)vb+stride*3))->normal.setVec(&m_norms.mRow[VW][9]); */ // interleave { V4F32 s; // v1 v2 v3 v4 m_verts.unpackRowW(); // n1 n2 n3 n4 m_norms.unpackRowW(); // :: s = m_verts.wy; // v1 n1 v3 n3 m_verts.wy = m_norms.wx; // v2 n2 v4 n4 m_norms.wx = s; s = m_verts.ww; m_verts.ww = m_norms.wz; m_norms.wz = s; m_verts.packRowW(); m_norms.packRowW(); } _mm_storeu_ps( ((float*)((U8*)vb+stride*0)+0), m_verts.wx); // v1x v1y v1z n1x _mm_storel_pi((__m64*)((float*)((U8*)vb+stride*0)+4), m_verts.wy); // n1y n1z _mm_storeu_ps( ((float*)((U8*)vb+stride*1)+0), m_norms.wx); // v2x v2y v2z n2x _mm_storel_pi((__m64*)((float*)((U8*)vb+stride*1)+4), m_norms.wy); // n2y n2z _mm_storeh_pi((__m64*)((float*)((U8*)vb+stride*2)+0), m_verts.wy); // v3x v3y _mm_storeu_ps( ((float*)((U8*)vb+stride*2)+2), m_verts.wz); // v3z n3x n3y n3x _mm_storeh_pi((__m64*)((float*)((U8*)vb+stride*3)+0), m_norms.wy); // v4x v4y _mm_storeu_ps( ((float*)((U8*)vb+stride*3)+2), m_norms.wz); // v4z n4x n4y n4z /* _mm_stream_pi(((__m64*)((U8*)vb+stride*0))+0, m_verts.m64Row[VW][0]); _mm_stream_pi(((__m64*)((U8*)vb+stride*0))+1, m_verts.m64Row[VW][1]); _mm_stream_pi(((__m64*)((U8*)vb+stride*0))+2, m_verts.m64Row[VW][2]); _mm_stream_pi(((__m64*)((U8*)vb+stride*1))+0, m_norms.m64Row[VW][0]); _mm_stream_pi(((__m64*)((U8*)vb+stride*1))+1, m_norms.m64Row[VW][1]); _mm_stream_pi(((__m64*)((U8*)vb+stride*1))+2, m_norms.m64Row[VW][2]); _mm_stream_pi(((__m64*)((U8*)vb+stride*2))+0, m_verts.m64Row[VW][3]); _mm_stream_pi(((__m64*)((U8*)vb+stride*2))+1, m_verts.m64Row[VW][4]); _mm_stream_pi(((__m64*)((U8*)vb+stride*2))+2, m_verts.m64Row[VW][5]); _mm_stream_pi(((__m64*)((U8*)vb+stride*3))+0, m_norms.m64Row[VW][3]); _mm_stream_pi(((__m64*)((U8*)vb+stride*3))+1, m_norms.m64Row[VW][4]); _mm_stream_pi(((__m64*)((U8*)vb+stride*3))+2, m_norms.m64Row[VW][5]); */ } index = (index_end/4)*4; LLV4Matrix4 blend_mat; F32 weight = F32_MAX; index_end = mesh->getNumVertices(); for (; index < index_end; ++index, ++coords, ++normals, ++weights, vb = (vertex_buffer*)((U8*)vb+stride)) { if( weight != *weights) { S32 joint = S32(weight = *weights); blend_mat.lerp(sJointMat[joint], sJointMat[joint+1], weight - joint); } blend_mat.multiply(*coords, vb->vertex); ((LLV4Matrix3)blend_mat).multiply(*normals, vb->normal); } } //_mm_sfence(); //_mm_empty(); } #else void update_geometry_sse2(LLFace *face, LLPolyMesh *mesh) { update_geometry_vec(face, mesh); return; } #endif From josh at lindenlab.com Mon Jul 9 11:16:25 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jul 9 11:14:27 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <46924E8C.9050009@blueflash.cc> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> <46924E8C.9050009@blueflash.cc> Message-ID: <46927B79.8070705@lindenlab.com> Nicholaz Beresford wrote: > What worries me most is that a change like this is rolled out without > mention in the changes, not with a note like "well, we're trying > something daring which might cause speed benefit long term, but also > trouble, but you can roll back and please let us know about any > problems". My fault. It should have been listed in the notes. Here's a post-mortem: Internally, we have multiple (poorly named) mainline branches, "release" and "release-candidate" (you'll see these names on http://wiki.secondlife.com/wiki/Source_downloads). Changes that have passed QA merge into one of those branches, per the following rules: "release" is compatible with the main grid; at any point, a viewer built from "release" can connect with the main grid, and simulators could be built from "release" that could be deployed in a rolling-restart to the main grid. "release-candidate" is maintained as a superset of release (so all changes to release are merged up into r-c), including all of the compatibility breakers (if any). It is deployed to the Beta grid, and on a "big deploy" to the main grid. (At which point, the changes are merged down into release) Here's what happened specifically: Several bug fixes were made, passed QA, and merged into "release". Following post-merge testing, we released the 1.17.1 optional viewer (and later on, picking up one more fix, 1.17.2). The SSE changes passed QA (mistake #1 - we apparently didn't test as comprehensively as we should have), and merged into "release". Subsequently, several more bug fixes were made and merged into "release". Following post-merge testing (of both those fixes and the SSE changes), we released 1.17.3 built out of "release". If you read between the lines, you'll note that at any point have potentially two release codelines up in the air - 1.18.0 and 1.17.3. In our internal Jira we tag changes with what version they'll go out with. Prior to deciding to release 1.17.3, all of the changes (including the SSE changes) were marked as being included in 1.18.0. When we decided to also release 1.17.3, I went back and marked the included changes (viewer-side only) as being in 1.17.3 (and implicitly as 1.18.0, although they shouldn't show in the 1.18.0 notes since they're not "new"). Mistake #2 - I missed marking the SSE changes in Jira as being in 1.17.3. So they weren't included in the release notes. (In my limited defense, I was just back from a fun vacation so my head wasn't screwed on straight. *sigh*) > Either nobody was aware that it might cause trouble, or it slipped > into 1.17.3 accidentally or it was just performed as a silent > experient ... and I'm not sure which of those alternatives is worse. Nothing so nefarious as the latter two. Exclusion from the release notes was an oversight - I simply missed tagging those changes as "also in 1.17.3" in our internal JIRA. However, the belief was that the code was sufficient quality to release - it was re-tested at various stages. Unfortunately, it appears that those tests were not as comprehensive as they should have been. As a total aside: a big part of why us Lindens are psyched up about the "message liberation" project is that it moves us out of the realm of monolithic, lock-step client/server upgrades being the norm (and hence, the focus of most of our process), and will force us to revamp our processes to focus more on asynchronous updates. Joshua From blakar at gmail.com Mon Jul 9 11:16:23 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 9 11:16:28 2007 Subject: [sldev] llviewerjointmesh_sse2.cpp In-Reply-To: <4692776E.1010406@dzonux.net> References: <4692776E.1010406@dzonux.net> Message-ID: <7992d0d60707091116hcd9194fu7e18f70544f57108@mail.gmail.com> > It doesn't use globals. [See VWR-1610] What do you call these? U32 lerp_comps = 0; U32 vert_comps = 0; U32 lerp_bits = 0; I fear what was reported means that the compiler will use SSE to initialise faster. E.g. by using SSE moves. So any global may be a danger. Off course it could be that it is limited to class constructors and then it's no issue. Dirk aka Blakar Ogre > > Note, this was tested with the older version of the viewer, may need to > adjust something. (then again...may not.) > > =) > > -- > Power to Change the Void > > /** > * @file llviewerjointmesh_sse2.cpp > * @brief LLV4 class implementation with LLViewerJointMesh class > * > * Copyright (c) 2007, Linden Research, Inc. > * License: GPLv3 -- http://www.gnu.org/copyleft/gpl.html > */ > > //----------------------------------------------------------------------------- > // Header Files > //----------------------------------------------------------------------------- > > // Do not use precompiled headers, because we need to build this file with > // SSE support, but not the precompiled header file. JC > #include "linden_common.h" > > #include "llviewerjointmesh.h" > > // project includes > #include "llface.h" > #include "llpolymesh.h" > > // library includes > #include "lldarray.h" > #include "llstrider.h" > #include "llv4matrix4.h" > #include "m4math.h" > #include "v3math.h" > > // *NOTE: SSE2 must be enabled for this module > > #if LL_VECTORIZE > > #include "emmintrin.h" > > > #if LL_MSVC > #pragma warning( disable : 4701 ) // "potentially uninitialized local variable" -- disabled > #endif > > inline V4F32 llv4lerp(V4F32 a, V4F32 b, V4F32 w) > { > return _mm_add_ps(a, _mm_mul_ps(_mm_sub_ps(b, a), w)); // a + ( b - a ) * w > } > > //----------------------------------------------------------------------- > //----------------------------------------------------------------------- > // LLV4Matrix3dx4 > //----------------------------------------------------------------------- > //----------------------------------------------------------------------- > > > U32 lerp_comps = 0; > U32 vert_comps = 0; > U32 lerp_bits = 0; > > > // NOTE: LLV4Matrix3dx4 is specially designed to swizzle XYZ data streams. > > LL_LLV4MATH_ALIGN_PREFIX > > class LLV4Matrix3dx4 > { > public: > union > { > F32 mArray[4*4*4]; > F32 mRow[4][4*4]; > __m64 mRow_i64[4][4*2]; > __m128i mRow_i128[4][4]; > struct > { > V4F32 xx, xy, xz, xw; > V4F32 yx, yy, yz, yw; > V4F32 zx, zy, zz, zw; > V4F32 wx, wy, wz, ww; > }; > }; > > void load4VectorsAndTranspose(const LLVector3* a); > void packRowX(); > void packRowY(); > void packRowZ(); > void packRowW(); > void packRows(); > void unpackRowW(); > } > > LL_LLV4MATH_ALIGN_POSTFIX; > > > #define mmShuffle(d,s,d1,d2,s3,s4) _mm_shuffle_ps(d,s,_MM_SHUFFLE(s4,s3,d2,d1)) > > inline void LLV4Matrix3dx4::load4VectorsAndTranspose(const LLVector3* a) > { > const V4F32 sx = _mm_loadu_ps((float*)a+0); > const V4F32 sy = _mm_loadu_ps((float*)a+4); > const V4F32 sz = _mm_loadu_ps((float*)a+8); > // {sx,sy,sz} = { x1 y1 z1 x2, y2 z2 x3 y3, z3 x4 y4 z4 } > xx = mmShuffle(sx,sx,0,0,0,3); // xx = { x1 x1 x1 x2 } > xy = mmShuffle(xx,sy,3,3,2,2); // xy = { x2 x2 x3 x3 } > xz = mmShuffle(xy,sz,2,2,1,1); // xz = { x3 x4 x4 x4 } > xz = mmShuffle(xz,xz,0,2,2,3); > > yx = mmShuffle(sx,sy,1,1,0,0); // yx = { y1 y1 y1 y2 } > yx = mmShuffle(yx,yx,0,1,1,3); > yy = mmShuffle(yx,sy,3,3,3,3); // yy = { y2 y2 y3 y3 } > yz = mmShuffle(yy,sz,3,3,2,2); // yz = { y3 y4 y4 y4 } > yz = mmShuffle(yz,yz,0,2,2,3); > > zx = mmShuffle(sx,sy,2,2,1,1); // zx = { z1 z1 z1 z2 } > zx = mmShuffle(zx,zx,0,1,1,3); > zy = mmShuffle(zx,sz,3,3,0,0); // zy = { z2 z2 z3 z3 } > zz = mmShuffle(sz,sz,0,3,3,3); // zz = { z3 z4 z4 z4 } > } > > inline void LLV4Matrix3dx4::packRowX() > { > V4F32 vt; > vt = mmShuffle(xy,xx,0,1,2,3); > xx = mmShuffle(xx,vt,0,1,2,0); > xy = mmShuffle(xy,xz,1,2,0,1); > vt = mmShuffle(xw,xz,0,3,2,2); > xz = mmShuffle(vt,xw,2,0,1,2); > } > > inline void LLV4Matrix3dx4::packRowY() > { > V4F32 vt; > vt = mmShuffle(yy,yx,0,1,2,3); > yx = mmShuffle(yx,vt,0,1,2,0); > yy = mmShuffle(yy,yz,1,2,0,1); > vt = mmShuffle(yw,yz,0,3,2,2); > yz = mmShuffle(vt,yw,2,0,1,2); > } > > inline void LLV4Matrix3dx4::packRowZ() > { > V4F32 vt; > vt = mmShuffle(zy,zx,0,1,2,3); > zx = mmShuffle(zx,vt,0,1,2,0); > zy = mmShuffle(zy,zz,1,2,0,1); > vt = mmShuffle(zw,zz,0,3,2,2); > zz = mmShuffle(vt,zw,2,0,1,2); > } > > inline void LLV4Matrix3dx4::packRowW() > { > V4F32 vt; > vt = mmShuffle(wy,wx,0,1,2,3); > wx = mmShuffle(wx,vt,0,1,2,0); > wy = mmShuffle(wy,wz,1,2,0,1); > vt = mmShuffle(ww,wz,0,3,2,2); > wz = mmShuffle(vt,ww,2,0,1,2); > } > > inline void LLV4Matrix3dx4::packRows() > { > packRowX(); > packRowY(); > packRowZ(); > packRowW(); > } > > inline void LLV4Matrix3dx4::unpackRowW() > { > ww = mmShuffle(wz,wz,1,2,3,0); > wz = mmShuffle(wy,wz,2,3,0,0); > wy = mmShuffle(wy,wx,0,1,3,0); > wy = mmShuffle(wy,wy,2,0,1,0); > } > > > //----------------------------------------------------------------------- > //----------------------------------------------------------------------- > // LLV4Matrix3dx4 > //----------------------------------------------------------------------- > //----------------------------------------------------------------------- > > //--- > > //----------------------------------------------------------------------- > //----------------------------------------------------------------------- > // LLViewerJointMesh::updateGeometry() > //----------------------------------------------------------------------- > //----------------------------------------------------------------------- > > void update_geometry_sse2(LLFace *face, LLPolyMesh *mesh) > { > LLV4Matrix4 sJointMat[32]; > > //upload joint pivots/matrices > { > LLDynamicArray& joint_data = mesh->getReferenceMesh()->mJointRenderData; > LLDynamicArray::const_iterator i = joint_data.begin(), iend = joint_data.end(); > LLV4Matrix4* mat = &sJointMat[0]; > LLJointRenderData* jd = *i; > register V4F32 vw; > const LLMatrix4* w; > const LLVector3* v; > for(; jd; ++mat) > { > w = jd->mWorldMatrix; > if(jd->mSkinJoint) > { > v = &jd->mSkinJoint->mRootToJointSkinOffset; > jd = ++i < iend ? *i : NULL; > } > else > { > v = &(jd = *++i)->mSkinJoint->mRootToParentJointSkinOffset; > } > if((unsigned)w & 0xF) > { > vw = _mm_loadu_ps(w->mMatrix[VW]); > vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VX]), mat->mV[VX] = _mm_loadu_ps(w->mMatrix[VX]))); > vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VY]), mat->mV[VY] = _mm_loadu_ps(w->mMatrix[VY]))); > mat->mV[VW] = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VZ]), mat->mV[VZ] = _mm_loadu_ps(w->mMatrix[VZ]))); > } > else > { > vw = _mm_load_ps(w->mMatrix[VW]); > vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VX]), mat->mV[VX] = _mm_load_ps(w->mMatrix[VX]))); > vw = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VY]), mat->mV[VY] = _mm_load_ps(w->mMatrix[VY]))); > mat->mV[VW] = _mm_add_ps(vw, _mm_mul_ps(_mm_set1_ps(v->mV[VZ]), mat->mV[VZ] = _mm_load_ps(w->mMatrix[VZ]))); > } > } > } > > //update geometry > { > LLV4Matrix3dx4 m_verts; > LLV4Matrix3dx4 m_norms; > LLV4Matrix3dx4 m_lerps; > > struct vertex_buffer // *NOTE: relies on a specific vertex buffer structure > { > LLVector3 vertex; > LLVector3 normal; > }; > > LL_LLV4MATH_ALIGN_PREFIX > union // aligned stack for manual loop vectorization > { > __m128i vp; > struct > { > vertex_buffer* vb; > const F32* weights; > const LLVector3* coords; > const LLVector3* normals; > }; > } > LL_LLV4MATH_ALIGN_POSTFIX; > > U32 stride = (U32)face->mVertexBuffer->getStride(); > > vb = (vertex_buffer*)((U8*)face->mVertexBuffer->getMappedData() + stride * mesh->mFaceVertexOffset); > weights = mesh->getWeights(); > coords = mesh->getCoords(); > normals = mesh->getNormals(); > > LLV4Vector3 vweights; > LLV4Vector3 xweights; > xweights.v = _mm_set1_ps(F32_MAX); > > vert_comps += mesh->getNumVertices(); > > U32 index = 0, index_end = mesh->getNumVertices(); > > __m128i vsz = _mm_setr_epi32(stride, sizeof(F32), sizeof(LLVector3), sizeof(LLVector3)); > vsz = _mm_add_epi32(vsz,vsz); > vsz = _mm_add_epi32(vsz,vsz); > for(index = index_end/4+1; --index; vp = _mm_add_epi32(vp, vsz)) > > // index_end -= 4; > // for(; index < index_end; index+=4, coords+=4, normals+=4, weights+=4, vb = (vertex_buffer*)((U8*)vb+stride*4)) > { > m_verts.load4VectorsAndTranspose(coords); > m_norms.load4VectorsAndTranspose(normals); > vweights.v = _mm_loadu_ps(weights); > _mm_prefetch((char*)(coords+4),_MM_HINT_NTA); > _mm_prefetch((char*)(coords+5),_MM_HINT_NTA); > _mm_prefetch((char*)(coords+6),_MM_HINT_NTA); > _mm_prefetch((char*)(normals+4),_MM_HINT_NTA); > _mm_prefetch((char*)(normals+5),_MM_HINT_NTA); > _mm_prefetch((char*)(normals+6),_MM_HINT_NTA); > _mm_prefetch((char*)(weights+4),_MM_HINT_NTA); > int r = _mm_movemask_ps(_mm_cmpeq_ps(vweights.v, xweights.v)); > if(r!=0xF) > { > lerp_comps+=4; > if(!(r&1)) > { > lerp_bits++; > V4F32 vi = vweights.v; > S32 joint = _mm_cvttss_si32(vi); > vi = _mm_cvtsi32_ss(vi, joint); > vi = _mm_sub_ps(vweights.v, vi); > vi = mmShuffle(vi,vi,0,0,0,0); > LLV4Matrix4* mat = &sJointMat[joint]; > m_lerps.xx = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); > m_lerps.yx = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); > m_lerps.zx = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); > m_lerps.wx = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); > } > if(vweights.mV[VY] == vweights.mV[VX]) > { > m_lerps.xy = m_lerps.xx; > m_lerps.yy = m_lerps.yx; > m_lerps.zy = m_lerps.zx; > m_lerps.wy = m_lerps.wx; > } > else > { > lerp_bits++; > V4F32 vi = vweights.v; > vi = mmShuffle(vi,vi,1,1,1,1); > S32 joint = _mm_cvttss_si32(vi); > vi = _mm_cvtsi32_ss(vi, joint); > vi = mmShuffle(vi,vi,0,0,0,0); > vi = _mm_sub_ps(vweights.v, vi); > vi = mmShuffle(vi,vi,1,1,1,1); > LLV4Matrix4* mat = &sJointMat[joint]; > m_lerps.xy = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); > m_lerps.yy = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); > m_lerps.zy = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); > m_lerps.wy = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); > } > if(vweights.mV[VZ] == vweights.mV[VX]) > { > m_lerps.xz = m_lerps.xx; > m_lerps.yz = m_lerps.yx; > m_lerps.zz = m_lerps.zx; > m_lerps.wz = m_lerps.wx; > } > else > if(vweights.mV[VZ] == vweights.mV[VY]) > { > m_lerps.xz = m_lerps.xy; > m_lerps.yz = m_lerps.yy; > m_lerps.zz = m_lerps.zy; > m_lerps.wz = m_lerps.wy; > } > else > { > lerp_bits++; > V4F32 vi = vweights.v; > vi = mmShuffle(vi,vi,2,2,2,2); > S32 joint = _mm_cvttss_si32(vi); > vi = _mm_cvtsi32_ss(vi, joint); > vi = mmShuffle(vi,vi,0,0,0,0); > vi = _mm_sub_ps(vweights.v, vi); > vi = mmShuffle(vi,vi,2,2,2,2); > LLV4Matrix4* mat = &sJointMat[joint]; > m_lerps.xz = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); > m_lerps.yz = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); > m_lerps.zz = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); > m_lerps.wz = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); > } > if(vweights.mV[VW] == vweights.mV[VX]) > { > m_lerps.xw = m_lerps.xx; > m_lerps.yw = m_lerps.yx; > m_lerps.zw = m_lerps.zx; > m_lerps.ww = m_lerps.wx; > } > else > if(vweights.mV[VW] == vweights.mV[VY]) > { > m_lerps.xw = m_lerps.xy; > m_lerps.yw = m_lerps.yy; > m_lerps.zw = m_lerps.zy; > m_lerps.ww = m_lerps.wy; > } > else > if(vweights.mV[VW] == vweights.mV[VZ]) > { > m_lerps.xw = m_lerps.xz; > m_lerps.yw = m_lerps.yz; > m_lerps.zw = m_lerps.zz; > m_lerps.ww = m_lerps.wz; > } > else > { > lerp_bits++; > V4F32 vi = vweights.v; > vi = mmShuffle(vi,vi,3,3,3,3); > S32 joint = _mm_cvttss_si32(vi); > vi = _mm_cvtsi32_ss(vi, joint); > vi = mmShuffle(vi,vi,0,0,0,0); > vi = _mm_sub_ps(vweights.v, vi); > vi = mmShuffle(vi,vi,3,3,3,3); > LLV4Matrix4* mat = &sJointMat[joint]; > m_lerps.xw = llv4lerp(mat->mV[VX], (mat+1)->mV[VX], vi); > m_lerps.yw = llv4lerp(mat->mV[VY], (mat+1)->mV[VY], vi); > m_lerps.zw = llv4lerp(mat->mV[VZ], (mat+1)->mV[VZ], vi); > m_lerps.ww = llv4lerp(mat->mV[VW], (mat+1)->mV[VW], vi); > } > m_lerps.packRows(); > xweights.v = vweights.v; > } > > m_verts.wx = _mm_add_ps(_mm_add_ps(_mm_add_ps(_mm_mul_ps(m_verts.xx, m_lerps.xx), _mm_mul_ps(m_verts.yx, m_lerps.yx)), _mm_mul_ps(m_verts.zx, m_lerps.zx)),m_lerps.wx); > m_verts.wy = _mm_add_ps(_mm_add_ps(_mm_add_ps(_mm_mul_ps(m_verts.xy, m_lerps.xy), _mm_mul_ps(m_verts.yy, m_lerps.yy)), _mm_mul_ps(m_verts.zy, m_lerps.zy)),m_lerps.wy); > m_verts.wz = _mm_add_ps(_mm_add_ps(_mm_add_ps(_mm_mul_ps(m_verts.xz, m_lerps.xz), _mm_mul_ps(m_verts.yz, m_lerps.yz)), _mm_mul_ps(m_verts.zz, m_lerps.zz)),m_lerps.wz); > > m_norms.wx = _mm_add_ps(_mm_add_ps(_mm_mul_ps(m_norms.xx, m_lerps.xx), _mm_mul_ps(m_norms.yx, m_lerps.yx)), _mm_mul_ps(m_norms.zx, m_lerps.zx)); > m_norms.wy = _mm_add_ps(_mm_add_ps(_mm_mul_ps(m_norms.xy, m_lerps.xy), _mm_mul_ps(m_norms.yy, m_lerps.yy)), _mm_mul_ps(m_norms.zy, m_lerps.zy)); > m_norms.wz = _mm_add_ps(_mm_add_ps(_mm_mul_ps(m_norms.xz, m_lerps.xz), _mm_mul_ps(m_norms.yz, m_lerps.yz)), _mm_mul_ps(m_norms.zz, m_lerps.zz)); > > > /* > ((vertex_buffer*)((U8*)vb+stride*0))->vertex.setVec(&m_verts.mRow[VW][0]); > ((vertex_buffer*)((U8*)vb+stride*1))->vertex.setVec(&m_verts.mRow[VW][3]); > ((vertex_buffer*)((U8*)vb+stride*2))->vertex.setVec(&m_verts.mRow[VW][6]); > ((vertex_buffer*)((U8*)vb+stride*3))->vertex.setVec(&m_verts.mRow[VW][9]); > > ((vertex_buffer*)((U8*)vb+stride*0))->normal.setVec(&m_norms.mRow[VW][0]); > ((vertex_buffer*)((U8*)vb+stride*1))->normal.setVec(&m_norms.mRow[VW][3]); > ((vertex_buffer*)((U8*)vb+stride*2))->normal.setVec(&m_norms.mRow[VW][6]); > ((vertex_buffer*)((U8*)vb+stride*3))->normal.setVec(&m_norms.mRow[VW][9]); > */ > > > // interleave > { > V4F32 s; // v1 v2 v3 v4 > m_verts.unpackRowW(); // n1 n2 n3 n4 > m_norms.unpackRowW(); // :: > s = m_verts.wy; // v1 n1 v3 n3 > m_verts.wy = m_norms.wx; // v2 n2 v4 n4 > m_norms.wx = s; > s = m_verts.ww; > m_verts.ww = m_norms.wz; > m_norms.wz = s; > m_verts.packRowW(); > m_norms.packRowW(); > } > > _mm_storeu_ps( ((float*)((U8*)vb+stride*0)+0), m_verts.wx); // v1x v1y v1z n1x > _mm_storel_pi((__m64*)((float*)((U8*)vb+stride*0)+4), m_verts.wy); // n1y n1z > > _mm_storeu_ps( ((float*)((U8*)vb+stride*1)+0), m_norms.wx); // v2x v2y v2z n2x > _mm_storel_pi((__m64*)((float*)((U8*)vb+stride*1)+4), m_norms.wy); // n2y n2z > > _mm_storeh_pi((__m64*)((float*)((U8*)vb+stride*2)+0), m_verts.wy); // v3x v3y > _mm_storeu_ps( ((float*)((U8*)vb+stride*2)+2), m_verts.wz); // v3z n3x n3y n3x > > _mm_storeh_pi((__m64*)((float*)((U8*)vb+stride*3)+0), m_norms.wy); // v4x v4y > _mm_storeu_ps( ((float*)((U8*)vb+stride*3)+2), m_norms.wz); // v4z n4x n4y n4z > > > /* > _mm_stream_pi(((__m64*)((U8*)vb+stride*0))+0, m_verts.m64Row[VW][0]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*0))+1, m_verts.m64Row[VW][1]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*0))+2, m_verts.m64Row[VW][2]); > > _mm_stream_pi(((__m64*)((U8*)vb+stride*1))+0, m_norms.m64Row[VW][0]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*1))+1, m_norms.m64Row[VW][1]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*1))+2, m_norms.m64Row[VW][2]); > > _mm_stream_pi(((__m64*)((U8*)vb+stride*2))+0, m_verts.m64Row[VW][3]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*2))+1, m_verts.m64Row[VW][4]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*2))+2, m_verts.m64Row[VW][5]); > > _mm_stream_pi(((__m64*)((U8*)vb+stride*3))+0, m_norms.m64Row[VW][3]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*3))+1, m_norms.m64Row[VW][4]); > _mm_stream_pi(((__m64*)((U8*)vb+stride*3))+2, m_norms.m64Row[VW][5]); > */ > } > > index = (index_end/4)*4; > LLV4Matrix4 blend_mat; > F32 weight = F32_MAX; > index_end = mesh->getNumVertices(); > for (; index < index_end; ++index, ++coords, ++normals, ++weights, vb = (vertex_buffer*)((U8*)vb+stride)) > { > if( weight != *weights) > { > S32 joint = S32(weight = *weights); > blend_mat.lerp(sJointMat[joint], sJointMat[joint+1], weight - joint); > } > blend_mat.multiply(*coords, vb->vertex); > ((LLV4Matrix3)blend_mat).multiply(*normals, vb->normal); > } > } > //_mm_sfence(); > //_mm_empty(); > } > > #else > > void update_geometry_sse2(LLFace *face, LLPolyMesh *mesh) > { > update_geometry_vec(face, mesh); > return; > } > > #endif > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From dzonatas at dzonux.net Mon Jul 9 11:21:47 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 11:21:49 2007 Subject: [sldev] llviewerjointmesh_sse2.cpp In-Reply-To: <7992d0d60707091116hcd9194fu7e18f70544f57108@mail.gmail.com> References: <4692776E.1010406@dzonux.net> <7992d0d60707091116hcd9194fu7e18f70544f57108@mail.gmail.com> Message-ID: <46927CBB.9050509@dzonux.net> Dirk Moerenhout wrote: >> It doesn't use globals. [See VWR-1610] > > What do you call these? > > U32 lerp_comps = 0; > U32 vert_comps = 0; > U32 lerp_bits = 0; > Debug code. -- Power to Change the Void From cnd at knowprose.com Mon Jul 9 11:34:39 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Mon Jul 9 11:34:54 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <46924880.6090502@gmail.com> References: <468EF56A.9000400@dzonux.net> <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> <46924880.6090502@gmail.com> Message-ID: <46927FBF.4030302@knowprose.com> >> * are there any legal issues? What happens if a texture is being infringed >> upon and someone overzealous decides to subpoena everyone who is >> distributing the texture, or worse, if the textures are highly illegal >> pictures. The liability doesn't just have to be remote or theoretical, it >> has to be non-existent since no one but LL can claim a common carrier status >> >> > Whew. This has happened before - I believe the case is still in court > after nearly 8 years. > Which case? >> I don't mean to be critical, but it doesn't seem like any of the above is >> taken into consideration and it's being debated without there being any >> actual need or practical purpose. I'd go with 'not feasible at this time or in the near future'. The bandwidth usage would probably stay constant, and may even increase. -- Taran Rampersad 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 dzonatas at dzonux.net Mon Jul 9 11:55:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 11:55:35 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <46927B79.8070705@lindenlab.com> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> <46924E8C.9050009@blueflash.cc> <46927B79.8070705@lindenlab.com> Message-ID: <469284A4.3000804@dzonux.net> Joshua Bell wrote: > My fault. Not really. > Unfortunately, it appears that those tests were not as comprehensive > as they should have been. > > As a total aside: a big part of why us Lindens are psyched up about > the "message liberation" project is that it moves us out of the realm > of monolithic, lock-step client/server upgrades being the norm (and > hence, the focus of most of our process), and will force us to revamp > our processes to focus more on asynchronous updates. > > Face it... there is too much hardware out there for a one-shot-get-it-right-for-all. I believe this only proves that the "release early, release often" philosophy doesn't work as well as people have touted. I agree with the asynchronous updates. It be *extremely cool* that when you enter regions that you have to download a viewer plug-in update in order to access all the features of those regions. This could translate to something like many different versions of "viewer_region.dll" files being found on the resident's Second Life directory. (where "region" is replaced with the name of the region that they are at). [I know I'm going to hear it now... "but that makes border crossing slow!" heh... ] -- Power to Change the Void From kelly at lindenlab.com Mon Jul 9 12:16:52 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Mon Jul 9 12:16:56 2007 Subject: [sldev] SSE2 / Ouch In-Reply-To: <469284A4.3000804@dzonux.net> References: <4692276B.8000501@blueflash.cc> <7992d0d60707090623v2ec9ef08r572fc1e66735f383@mail.gmail.com> <7992d0d60707090700v1e89d026h357206006081da98@mail.gmail.com> <46924700.9000307@gmail.com> <46924E8C.9050009@blueflash.cc> <46927B79.8070705@lindenlab.com> <469284A4.3000804@dzonux.net> Message-ID: <469289A4.4040700@lindenlab.com> Dzonatas wrote: > Face it... there is too much hardware out there for a > one-shot-get-it-right-for-all. I believe this only proves that the > "release early, release often" philosophy doesn't work as well as > people have touted. > > I agree with the asynchronous updates. It be *extremely cool* that > when you enter regions that you have to download a viewer plug-in > update in order to access all the features of those regions. This > could translate to something like many different versions of > "viewer_region.dll" files being found on the resident's Second Life > directory. (where "region" is replaced with the name of the region > that they are at). > > [I know I'm going to hear it now... "but that makes border crossing > slow!" heh... ] I don't think this is ever the plan, really. Instead your client will just work on all versions of the server being used. Sort of like the web - it doesn't matter what version of apache or php etc. a server is running, your version of firefox just works (although maybe it won't support feature Foo). While 1.18 does a lot to remove the connection between viewer and server, it does not yet support running multiple server versions on the grid at once. That feature set is currently in heavy development with several milestones some of which should be making their way to Agni "Soon(tm)" after 1.18. Those features will really enable amazing things like testing new server code by rolling out to increasingly larger subsets of the main grid, allowing estate owners to decide when (and sometimes if!) to upgrade server versions etc. Exciting stuff, and please do pester Zero Linden at his office hours for more information. :) Dynamically loading plugins based on region is a path frought with peril. While it may be a good idea some day, there is a LOT of design work involved and many security issues. Especially after the sim is open sourced. Even then this will probably center around the currently non-existent plugin system and not offer dynamic loading of core modules, require confirmation dialogs etc. etc. etc. - Kelly From secret.argent at gmail.com Mon Jul 9 13:35:32 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 13:35:27 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> Message-ID: <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> > Mallory just uses the the Parcel Media Stream to set a specific URL > call for > Alice and gets her IP without any fuss or muss or any changes to > the current > SL codebase.... as long as Alice isn't on Linux. That only works if: a. Alice visits a parcel that Mallory owns, and b. Alice has media streaming on. The original scenario would only require that Mallory *or* a scripted object controlled by Mallory be able to get into draw distance of Alice. That scripted object could be an object on land owned by Mallory, an object Mallory leaves in land with build set and no autoreturn, an object on land owned by any group Mallory is in... including any malls he rents space on, OR an object that Mallory passes out as a transferrable freebie containing a no-mod script. This means that: a. The potential exposure is several decimal orders of magnitude greater unless Mallory is a Land Baron *and* is willing to devote the media streams of all Mallory's land to the search, and even then there's multiple decimal orders of magnitude greater exposure via web textures than media streams. b. Alice has no effective countermeasure within an unmodified client. "But your IP wouldn't be safe" is *not* a straw man argument. From bos at lindenlab.com Mon Jul 9 13:40:21 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jul 9 13:40:44 2007 Subject: [Fwd: Re: [sldev] SSE2 / Ouch] In-Reply-To: <46926DC0.6010505@blueflash.cc> References: <46926DC0.6010505@blueflash.cc> Message-ID: <46929D35.8010105@lindenlab.com> Nicholaz Beresford wrote: > Btw, I just think I glimpsed in 1.18 that the "say" was fixed > but the purple was not (unless the purple was fixed in a different > way, I just saw that the patch file still went through for the > "yellow" hunk ... didn't look into it any deeper). I believe they're both fixed. References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> Message-ID: > I agree 100%. This argument has already been used to stifle the > discussion of (non-P2P) web fetched textures with irrelevancies > about IP > address exposure. They're not irrelevancies. We're talking about the difference between the current situation, where an attacker would have to make a heroic effort to have a chance of identifying a specific avatar, and it would be all for naught if the victim simply didn't do streaming, and a situation where sparrowfart surveillance could trivially be set up over as much of the grid as the attacker was able to leave scanners on. And, yes, there are people concerned about this who don't use streaming at all, nor use third-party sites with their SL identities. From secret.argent at gmail.com Mon Jul 9 13:46:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 13:46:16 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer In-Reply-To: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> Message-ID: <65538E51-7141-421D-B7B3-CE99163332B0@gmail.com> > I'm not sure how many people still use Win2k or if support for > it will be knocked off eventually. I've seen nobody vote for the > issue, > so I gather it's not that important. I use Windows 2000, and I would like this NOT to be fixed, so I can tell people "Sorry, I can't use Voice, it's not supported in Windows 2000". :) From secret.argent at gmail.com Mon Jul 9 14:03:37 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 14:03:31 2007 Subject: [sldev] Re: P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2 In-Reply-To: <20070707160333.1979541B006@stupor.lindenlab.com> References: <20070707160333.1979541B006@stupor.lindenlab.com> Message-ID: > In order to improve the quality of textures without an increase in > cost > on the sims, we need to use P2P Web textures. I don't agree. There are a number of ways we can improve the quality of sculpted prims without a corresponding increase in cost to the sims. 1. Support PNG as well as JPEG2000 in hosted textures. 2. Create a new texture type for sculpt textures that is a lossless format (such as PNG) but limited to 64x64. 3. Support a non-texture format for sculpted prims, such as zlib- compressed obj or a more compact format than obj. 4. Support PNG as well as JPEG2000 in hosted textures, but only have the client use PNG for sculpt textures... have it display the lossless format as "MISSING IMAGE" when applied to a prim surface or particle texture, etcetera... Most of these would actually *reduce* the cost, since a 64x64 PNG is smaller than a 256x256 JPEG2000. 1 might lead to a few people uploading PNG where it's not needed, but the increase in size would be relatively small, and owuld be offset over time by the effect of smaller sculpt textures. 2 and 4 are equivalent, but 4 is easier to implement, and would reduce the total cost of textures to the sim due to the smaller sculpt textures. 3 has the potential of significantly decreasing the size of sculpted prim data, while increasing the quality of sculpted prims more than any image format could. Also: 5. With or without any of options 1, 2, and 4, use the high six bits from the Alpha channel as two additional bits each for X, Y, and Z, increasing the range of each coordinate from 8 to 10 bits (0..1024 instead of 0..256). From secret.argent at gmail.com Mon Jul 9 14:18:14 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 14:18:07 2007 Subject: [sldev] Lossless image uploading In-Reply-To: <20070708190008.E89BB41B03F@stupor.lindenlab.com> References: <20070708190008.E89BB41B03F@stupor.lindenlab.com> Message-ID: <87BC562D-20DD-4CE8-8B61-52457EA89517@gmail.com> > For some reason, I just don't see this continuing to work for very > long. ;-) If LL is smart, they will just block this for textures greater than 64x64, and everyone's a winner. :) From secret.argent at gmail.com Mon Jul 9 14:34:40 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 14:34:33 2007 Subject: [sldev] Re: 1024x1024 sculpties In-Reply-To: <20070709150455.8438641AF11@stupor.lindenlab.com> References: <20070709150455.8438641AF11@stupor.lindenlab.com> Message-ID: <9D9903D3-464B-45FB-AFE4-A5F50FC60A80@gmail.com> Dzonatas: they're not even doing 64x64 sculpies. Sculpies are 32x32 close up, 16x16 further away. Using the extra bits for higher *resolution* would be much more useful. How about this? Sculpt textures of 128x128 using the high 4 bits of each of 4 successive pixels as the values, giving us 16 bits per color per pixel, and using the bits that are less likely to be lost when compressed? Even without using Alpha that would MASSIVELY improve the quality of sculpies. From robin.cornelius at gmail.com Mon Jul 9 14:42:13 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Jul 9 14:42:23 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer In-Reply-To: <65538E51-7141-421D-B7B3-CE99163332B0@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <65538E51-7141-421D-B7B3-CE99163332B0@gmail.com> Message-ID: <4692ABB5.7080203@gmail.com> Argent Stonecutter wrote: >> I'm not sure how many people still use Win2k or if support for >> it will be knocked off eventually. I've seen nobody vote for the issue, >> so I gather it's not that important. > > I use Windows 2000, and I would like this NOT to be fixed, so I can tell > people "Sorry, I can't use Voice, it's not supported in Windows 2000". :) Your lucky you've got sound at all. Think of us poor Linux folks where sound is a lottery. Currently I have a libc incompatibility with fmod so i can't even start the viewer with sound enabled, i need try to chase this one down as it is a real grind for me now. -- Robin Cornelius http://www.byteme.org.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070709/31c43986/signature-0001.pgp From dzonatas at dzonux.net Mon Jul 9 14:48:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 14:48:20 2007 Subject: [sldev] Re: 1024x1024 sculpties In-Reply-To: <9D9903D3-464B-45FB-AFE4-A5F50FC60A80@gmail.com> References: <20070709150455.8438641AF11@stupor.lindenlab.com> <9D9903D3-464B-45FB-AFE4-A5F50FC60A80@gmail.com> Message-ID: <4692AD24.3070903@dzonux.net> Argent Stonecutter wrote: > Dzonatas: they're not even doing 64x64 sculpies. > From the tech talks, that is only statically limited on the client-side for now. I gather it wouldn't be to hard to add a slider right now to the preferences window to allow the viewer to increase the level of detail on the sculpties. If that slider was smart enough to adjust itself automatically through different scenes, that would be cool. Perhaps, adjust it on-the-fly, like by frame rate, based on some heuristic benchmarks. -- Power to Change the Void From soft at lindenlab.com Mon Jul 9 15:34:29 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jul 9 15:34:30 2007 Subject: [sldev] Viewer Crash Reports updated Message-ID: <9e6e5c9e0707091534we3908f3nf31acabf85b034f6@mail.gmail.com> Turns out the crash report processing had gotten kind of crufty. It's up to date now, and here are crashes from a pool of a few thousand of the most recent: https://wiki.secondlife.com/wiki/Crash_Reports I'm working to get Linux separated from the others in a coming version. I want to make these regular, going forward. Please ping me if I don't post the next batch 3-4 days after the next viewer release. On 7/2/07, Soft Linden wrote: > On 6/26/07, Able Whitman wrote: > > I have a couple of friends who have been experiencing regular crashes with > > the 1.17.1.0 viewer release. This led me to wonder: Are there any plans to > > make information from viewer crash reports accessible to open source > > contributors? > > > > The crash call stacks in the wiki > > (https://wiki.secondlife.com/wiki/Crash_Reports) are > > somewhat helpful, but are these top 10 lists still up-to-date? Some > > additional statistics about the frequency of the different crashes would > > also be useful, as well as more details about which environments (OS, video > > card, driver version, etc.) encounter which crashes most often. And, at > > least in the case of investigating crashes on a Windows system, minidump > > files would be tremendously useful. > > I'm pinging internally on this. > From able.whitman at gmail.com Mon Jul 9 15:53:50 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 9 15:53:53 2007 Subject: [sldev] Re: Viewer Crash Reports updated In-Reply-To: <9e6e5c9e0707091534we3908f3nf31acabf85b034f6@mail.gmail.com> References: <9e6e5c9e0707091534we3908f3nf31acabf85b034f6@mail.gmail.com> Message-ID: <7b3a84fb0707091553x77b125cage7c01ae70fd84764@mail.gmail.com> This is great information! Thanks, Soft! On 7/9/07, Soft Linden wrote: > > Turns out the crash report processing had gotten kind of crufty. It's > up to date now, and here are crashes from a pool of a few thousand of > the most recent: > https://wiki.secondlife.com/wiki/Crash_Reports > > I'm working to get Linux separated from the others in a coming version. > > I want to make these regular, going forward. Please ping me if I don't > post the next batch 3-4 days after the next viewer release. > > On 7/2/07, Soft Linden wrote: > > On 6/26/07, Able Whitman wrote: > > > I have a couple of friends who have been experiencing regular crashes > with > > > the 1.17.1.0 viewer release. This led me to wonder: Are there any > plans to > > > make information from viewer crash reports accessible to open source > > > contributors? > > > > > > The crash call stacks in the wiki > > > (https://wiki.secondlife.com/wiki/Crash_Reports) are > > > somewhat helpful, but are these top 10 lists still up-to-date? Some > > > additional statistics about the frequency of the different crashes > would > > > also be useful, as well as more details about which environments (OS, > video > > > card, driver version, etc.) encounter which crashes most often. And, > at > > > least in the case of investigating crashes on a Windows system, > minidump > > > files would be tremendously useful. > > > > I'm pinging internally on this. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070709/b1e19a9c/attachment.htm From nicholaz at blueflash.cc Mon Jul 9 16:26:36 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 16:26:46 2007 Subject: [sldev] Re: Viewer Crash Reports updated In-Reply-To: <7b3a84fb0707091553x77b125cage7c01ae70fd84764@mail.gmail.com> References: <9e6e5c9e0707091534we3908f3nf31acabf85b034f6@mail.gmail.com> <7b3a84fb0707091553x77b125cage7c01ae70fd84764@mail.gmail.com> Message-ID: <4692C42C.5080607@blueflash.cc> Able Whitman wrote: > This is great information! Thanks, Soft! I've seen most of them in real crash dumps (including what Lindens call Plus-dumps which they don't get from regular users). LLEventPoll/boost::intrusive ptr is fixed. LLImageBase::allocateData always (almost) has image allocation of images with at least one dimension of 2048 downstack. The two PushBatch are the same (just with ATI and NVIDIA boards) and crash in glDrawRangeElements with what looks like valid data (as far as the dumps let me see ... no glaring NULL pointers or junk on the stack). I've seen one so far with LLUserAuth::authenticate and also have a log for it, it seems to be related to the computer not being able to reach the login host. LLXMLRPCTransaction::Impl::init is probably related to authenticate, but I've never seen this one as a dump (but would like to). Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From sllists at boroon.dasgupta.ch Mon Jul 9 16:41:31 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Jul 9 16:41:44 2007 Subject: [sldev] Lossless image uploading Message-ID: <20070710014131.3t9x9c834s4g44ko@datendelphin.net> Skipped content of type multipart/alternative-------------- next part -------------- Skipped content of type multipart/alternative From nicholaz at blueflash.cc Mon Jul 9 17:18:35 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 17:18:42 2007 Subject: [sldev] IM Window Resizing / VWR-1626 Message-ID: <4692D05B.6000404@blueflash.cc> If someone is making their homebrew builds and is actually (unlike me) spending time in-world, it would be nice of you could try the jira below for adverse effects. (it's basically a one-liner, just add mAutoResize = FALSE to LLFloaterIM::LLFloaterIM()). https://jira.secondlife.com/browse/VWR-1626 Thanks! Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From gigstaggart at gmail.com Mon Jul 9 17:18:22 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 9 17:18:44 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> Message-ID: <4692D04E.2060806@gmail.com> Argent Stonecutter wrote: >> I agree 100%. This argument has already been used to stifle the >> discussion of (non-P2P) web fetched textures with irrelevancies about IP >> address exposure. > > They're not irrelevancies. > > We're talking about the difference between the current situation, where > an attacker would have to make a heroic effort to have a chance of > identifying a specific avatar, and it would be all for naught if the Since when is getting someone's IP address an "attack"? I guess that makes anyone running a DNS server a criminal. This entire discussion is ludicrous. IP addresses are *how computers talk to one another* on the net. It's *how the net works*. If you don't like it, go design your own fucking Internet. -Jason From able.whitman at gmail.com Mon Jul 9 17:50:54 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 9 17:50:56 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692D04E.2060806@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> Message-ID: <7b3a84fb0707091750m65bac57ex244190d17b934691@mail.gmail.com> Simply getting someone's IP address is not an attack. That's not what Argent was saying, and it doesn't help being unnecessarily flippant about it. The issue here is one of information disclosure. By connecting to the SL grid, the viewer exposes the client's IP address to the SL server, by necessity, in order to establish communications with the various sims in the grid. A subtle but important point is that the viewer discloses the client IP only to the servers that make up the grid, *not* to other users who are connected to the same grid. This is not an irrelevancy, it is a matter of trust. If a user is connecting to SL, she is implicitly trusting her IP address to the machines that comprise the grid. This is not an unreasonable trust decision, since LL runs the grid and their policies are, in the main, to protect the privacy of individual users' information--particularly personally-identifiable information that might make it possible for a 3rd party to establish a connection between an SL avatar and a RL person. A user's IP address is protected from other users because, for the most part, all interactions with other avatars takes place via the grid, so there are never direct connections between individual clients. If someone has malicious intents and wishes to directly attack the client of another user, the viewer does not provide the would-be attacker with enough information to do so. Currently, in order for someone other than LL to obtain a user's IP address, they must have a way of convincing the target user to have their viewer establish a direct connection to a system which the attacker has control over. This could be accomplished by having the target user use the embedded browser to visit a web server controlled by the attacker, or by listening to a music or video stream from a media server the attacker controls. In either case, these avenues of information disclosure require explicit permission from the target user. And importantly, both avenues can be disabled without serious loss of viewer functionality. In the case of P2P texture distribution, without explicit controls otherwise, a would-be attacker would need only to place a texture whose only source is their own machine within the draw distance of the target user. In order to retrieve this texture, the target's viewer would have to make a direct connection to the attacker's system, thus disclosing the target's IP address and making it possible for the attacker to attack the system directly. In addition, since the attacker could arrange it such that his client would know which avatars are within range of the textures he is providing, it would become much easier for him to associate an IP address with a particular avatar. Worse, the target user has little ability to opt-out of this avenue of information disclosure, since texture downloads happen automatically. Having the user disable P2P texture acquisition would prevent information disclosure but also prevent the user's viewer from being able to display all of the textures needed to render a scene. This is a significant loss of functionality. It might be possible for the viewer to maintain a blacklist of avatars to refuse P2P textures from, but with the ready availability of alts, this isn't an effective option. It also requires that the user know in advance whose textures not to trust, an impractical endeavor at best. Of course, not everyone is as sensitive to the disclosure of their IP address as others, but this does not make the issue of information disclosure any less important. Currently the viewer offers reasonable control over this kind of disclosure, and new features should not degrade this control, especially not by default, and especially not in a manner which is not practically reversible. --Able On 7/9/07, Jason Giglio wrote: > > Argent Stonecutter wrote: > >> I agree 100%. This argument has already been used to stifle the > >> discussion of (non-P2P) web fetched textures with irrelevancies about > IP > >> address exposure. > > > > They're not irrelevancies. > > > > We're talking about the difference between the current situation, where > > an attacker would have to make a heroic effort to have a chance of > > identifying a specific avatar, and it would be all for naught if the > > Since when is getting someone's IP address an "attack"? > > I guess that makes anyone running a DNS server a criminal. This entire > discussion is ludicrous. > > IP addresses are *how computers talk to one another* on the net. It's > *how the net works*. > > If you don't like it, go design your own fucking Internet. > > -Jason > _______________________________________________ > 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/20070709/ab5eb651/attachment-0001.htm From sllists at boroon.dasgupta.ch Mon Jul 9 17:57:57 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Jul 9 17:58:06 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692D04E.2060806@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> Message-ID: <20070710025757.o5r2avxe88kcoggg@datendelphin.net> > Since when is getting someone's IP address an "attack"? The IP itself won't be the problem for almost anyone, nor won't connecting the IP to an SL account. What scares (some) Residents is the possibility to tangle their SL account with their RL identity via their IP and third party web services that require RL data. Unless you either use tor or don't use any (untrusted) services requiring RL data at all, you have to assume your RL data and IP already can be connected, so if SL want's to provide anonymous use it shouldn't reveal them. That such will is existant can be seen from point four of the Community Standards[1]. Boroondas Links: ------ [1] http://secondlife.com/corporate/cs.php ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/aad5c8f1/attachment.htm From secret.argent at gmail.com Mon Jul 9 17:58:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 17:58:15 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692D04E.2060806@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> Message-ID: On 09-Jul-2007, at 19:18, Jason Giglio wrote: > Since when is getting someone's IP address an "attack"? I didn't say "getting someone's IP address" was an attack. I said that web textures make it practical for an attacker to get someone's IP address in a way that media streams don't. What makes them an attacker is that they are attempting to perform an attack... for example, to determine the identity of someone in SL (knowing their identity in RL) or in RL (knowing their identity in SL) who doesn't want them to. Their goals and intentions are what makes them an attacker, not every little detail of their actions in between... however, if an intermediate step helps them reach their goal, then that step is a component of their attack. > I guess that makes anyone running a DNS server a criminal. While someone who is running your DNS server has the ability to cause you considerable problems, it would be the act of following through on that capability to cause those problems that would be criminal, and would make their control of your DNS part of an attack. I suspect you wouldn't want to have someone with the intent of causing you harm running your DNS server. As we found out when Network Solutions had complete control over the "com" domain, and they hijacked the root. > IP addresses are *how computers talk to one another* on the net. > It's *how the net works*. Which is exactly why they're SO useful for someone who wants to determine someone else's identity. From gigstaggart at gmail.com Mon Jul 9 18:08:13 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 9 18:08:34 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <7b3a84fb0707091750m65bac57ex244190d17b934691@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <7b3a84fb0707091750m65bac57ex244190d17b934691@mail.gmail.com> Message-ID: <4692DBFD.2020505@gmail.com> Able Whitman wrote: > A subtle but important point is that the viewer discloses the client IP > only to the servers that make up the grid, *not* to other users who are People who provide web textures are no longer users, they are content providers. > A user's IP address is protected from other users because, for the most > part, all interactions with other avatars takes place via the grid, so > there are never direct connections between individual clients. If > someone has malicious intents and wishes to directly attack the client > of another user, the viewer does not provide the would-be attacker with > enough information to do so. This is a mere coincidence of the design, not a design goal. Back in 2001 or whenever, I seriously doubt the founders of Linden Lab said "Hey, lets make a huge, slow, anonymizing proxy service, where all the data flows through our central servers to protect people's IP addresses from being discovered." > And importantly, both avenues can be disabled without serious loss of > viewer functionality. If you expect to use the Internet without exposing your IP to content providers, you should expect serious loss of functionality. > In the case of P2P texture distribution, without explicit controls I don't support this silly P2P texture idea. I'm only talking about this in terms of web textures, HTML-on-a-prim, ... pretty much all the exciting future features that will prevent Second Life from becoming irrelevant. > Worse, the target user has little ability to opt-out of this avenue of > information disclosure, since texture downloads happen automatically. > Having the user disable P2P texture acquisition would prevent > information disclosure but also prevent the user's viewer from being > able to display all of the textures needed to render a scene. This is a > significant loss of functionality. If you expect to use the Internet without exposing your IP to content providers, you should expect serious loss of functionality. > Of course, not everyone is as sensitive to the disclosure of their IP > address as others, but this does not make the issue of information > disclosure any less important. Currently the viewer offers reasonable > control over this kind of disclosure, and new features should not > degrade this control, especially not by default, and especially not in a > manner which is not practically reversible. It should, by default, because there is no way Linden Lab can become some huge anonymizing proxy service. The future viability of Second Life as a platform for providing content rests on decentralization. Decentralization means third party content that does *not* flow through Linden Lab servers, in many cases. -Jason From nicholaz at blueflash.cc Mon Jul 9 18:08:44 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 18:08:52 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> Message-ID: <4692DC1C.9060108@blueflash.cc> Argent Stonecutter wrote: > I didn't say "getting someone's IP address" was an attack. > > I said that web textures make it practical for an attacker to get > someone's IP address in a way that media streams don't. Ummm, I'm probably missing the point of this discussion completely, but what exactly do you think is this attacker doing with your your IP address? I mean what is he doing different from that which about 20+ people per hour aren't trying already through IP scan. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From jianr3n at gmail.com Mon Jul 9 18:09:31 2007 From: jianr3n at gmail.com (jianren chua) Date: Mon Jul 9 18:09:34 2007 Subject: [sldev] capturing of msg Message-ID: <76d226120707091809p7e298910u26dbd16bf5e70dcf@mail.gmail.com> Hi all, is there anyway to capture the msg on the dialog box and put it into a variable inside the open source code? -- Jr Time aNd t|de waIt f0r No mAn, St0p t|me! ~Life is for now, work is for later~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/6b346466/attachment.htm From jhurliman at wsu.edu Mon Jul 9 18:12:12 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jul 9 18:14:01 2007 Subject: [sldev] capturing of msg In-Reply-To: <76d226120707091809p7e298910u26dbd16bf5e70dcf@mail.gmail.com> References: <76d226120707091809p7e298910u26dbd16bf5e70dcf@mail.gmail.com> Message-ID: <4692DCEC.7000804@wsu.edu> jianren chua wrote: > Hi all, > is there anyway to capture the msg on the dialog box and put it into a > variable inside the open source code? > > > -- > Jr > > Time aNd t|de waIt f0r No mAn, St0p t|me! > > ~Life is for now, work is for later~ The AlertMessage packet callback, if I understood your question correctly. John Hurliman From nicholaz at blueflash.cc Mon Jul 9 18:19:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 18:19:26 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070710025757.o5r2avxe88kcoggg@datendelphin.net> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <20070710025757.o5r2avxe88kcoggg@datendelphin.net> Message-ID: <4692DE96.5060003@blueflash.cc> Boroondas Gupte wrote: > > Since when is getting someone's IP address an "attack"? > > The IP itself won't be the problem for almost anyone, nor won't > connecting the IP to an SL account. What scares (some) Residents is the > possibility to tangle their SL account with their RL identity via their > IP and third party web services that require RL data. Well, the last time I checked (at least in the non 3rd world countries), it took a police search warrant (or similar legal construct) to connect an IP to real world person. And I can assure you, if someone does has a search warrant, LL will happily (and with sugar on top) hand out the IP from the connection a certain avatar was using at a certain time. For someone without a warrant the information will be pretty useless, and for someone with a warrant it will merely be one extra step. Nick ---- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Mon Jul 9 18:22:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 18:22:53 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692DBFD.2020505@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <7b3a84fb0707091750m65bac57ex244190d17b934691@mail.gmail.com> <4692DBFD.2020505@gmail.com> Message-ID: <4692DF6D.5070303@dzonux.net> Good points but remember... Jason Giglio wrote: > I don't support this silly P2P texture idea. ... The Internet is really just a P2P device itself even without all the further abstracted P2P methods. Somewhere along the line people associated P2P with the other silly ideas, but those are still good layman's term. People generally recognize what is being done by "Limewire," but not as many understand the use of IP addresses to share data. -- Power to Change the Void From able.whitman at gmail.com Mon Jul 9 18:35:55 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 9 18:35:57 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692DBFD.2020505@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <7b3a84fb0707091750m65bac57ex244190d17b934691@mail.gmail.com> <4692DBFD.2020505@gmail.com> Message-ID: <7b3a84fb0707091835h3edaa0e7j54b1dfb21a930f68@mail.gmail.com> On 7/9/07, Jason Giglio wrote: > > People who provide web textures are no longer users, they are content > providers. Only unwittingly so. Just because someone wants to put a big texture on an object they're selling doesn't mean they want to sign up to be the content distributor for that texture. And it's unreasonable to expect the majority of users to understand the subtleties of P2P texture distribution--the information disclosure runs both ways, after all. > A user's IP address is protected from other users because, for the most > > part, all interactions with other avatars takes place via the grid, so > > there are never direct connections between individual clients. If > > someone has malicious intents and wishes to directly attack the client > > of another user, the viewer does not provide the would-be attacker with > > enough information to do so. > > This is a mere coincidence of the design, not a design goal. Why the information disclosure is protected is irrelevant. The fact is that this information is protected now, and some users depend upon this fact to help ensure their anonymity. Changing this behavior would be introducing a security bug, and would be unacceptable. If you expect to use the Internet without exposing your IP to content > providers, you should expect serious loss of functionality. Of course. My point is that content providers should be clearly identifiable as such. If I don't want to disclose my IP to such and such a service or a web site, I don't visit it. The decision of whether to disclose such information to be left explicitly to the user. If I don't wish to disclose my IP to a site, then I am precluded from the functionality of that site. I don't support this silly P2P texture idea. I'm only talking about > this in terms of web textures, HTML-on-a-prim, ... pretty much all the > exciting future features that will prevent Second Life from becoming > irrelevant. In that case then, I believe we are in vigorous agreement. I am not arguing against *all* features that could possibly disclose IP addresses or other such information. In fact I think web textures and html-on-a-prim would be fantastic features. My only point is that such features *do* open up new avenues of information disclosure, and as such, the features should be disableable at the user's discretion. > ...and new features should not > > degrade this control, especially not by default, and especially not in a > > manner which is not practically reversible. > > It should, by default, because there is no way Linden Lab can become > some huge anonymizing proxy service. The future viability of Second > Life as a platform for providing content rests on decentralization. > Decentralization means third party content that does *not* flow through > Linden Lab servers, in many cases. I guess we will have to disagree on this point. I believe that security decisions, whether they be trust decisions, permissions decisions, information disclosure decisions, etc., should be enabled only at the explicit request of the users, not by default. I understand that this may degrade the functionality of the viewer by default, but I am not advocating huge barriers of entry to using those kinds of features. For example, the first time you walk into a parcel with streaming audio, the viewer prompts you whether you want to enable streaming media or not. This is basically the sort of consent I advocate with any similar feature: 1. it is off by default, 2. the user is informed of its presence when appropriate, 3. the user then has the option of turning the feature on or leaving it off, and 4. most importantly, the user's decision (either way) is reversible --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070709/bb42886f/attachment-0001.htm From nicholaz at blueflash.cc Mon Jul 9 18:36:10 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 9 18:36:17 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> Message-ID: <4692E28A.4020502@blueflash.cc> Oh, and btw ... did you know that every email to this list reveals your IP to a few hundred people whom you don't know? Mine at this time is 217.229.33.79 and you will find it somewhere in the header of this mail (like everybody else's in theirs). Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Mon Jul 9 18:55:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 9 18:55:13 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <7b3a84fb0707091835h3edaa0e7j54b1dfb21a930f68@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <7b3a84fb0707091750m65bac57ex244190d17b934691@mail.gmail.com> <4692DBFD.2020505@gmail.com> <7b3a84fb0707091835h3edaa0e7j54b1dfb21a930f68@mail.gmail.com> Message-ID: <4692E700.8060203@dzonux.net> Able Whitman wrote: > > Why the information disclosure is protected is irrelevant. The fact is > that this information is protected now, and some users depend upon > this fact to help ensure their anonymity. Changing this behavior > would be introducing a security bug, and would be unacceptable. Hmm. Dare to try that one with the WSE? I still wonder where the actual point of disclosure is at. Perhaps, there could be a preference option that the user can check if they prefer to be completely anonymous to anybody except LL along with the note that being completely anonymous may disabled the more powerful features of the Internet and their quality of experience in-world. > For example, the first time you walk into a parcel with streaming > audio, the viewer prompts you whether you want to enable streaming > media or not. This is basically the sort of consent I advocate with > any similar feature: > > 1. it is off by default, > 2. the user is informed of its presence when appropriate, > 3. the user then has the option of turning the feature on or leaving > it off, and > 4. most importantly, the user's decision (either way) is reversible > Excellent point the justify a viewer change -- to make sure those that use http addresses to gather their textures first understand these things. That being any content provider may serve the data to them and not just LL. -- Power to Change the Void From secret.argent at gmail.com Mon Jul 9 18:56:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 18:56:43 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692E28A.4020502@blueflash.cc> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692E28A.4020502@blueflash.cc> Message-ID: > did you know that every email to this list reveals your > IP to a few hundred people whom you don't know? I'm not someone who is being stalked in SL by an ex-friend, and who wants to get the hell away from him or her with a new account. I'm not someone who annoyed the wrong griefer, and is about to get smurfed every time they log in until they figure out what the heck is going on. I'm not the alt of someone who's achieved some kind of fame or notoriety in SL, who just wants to hang out without getting IMed all the time. I'm not logging in from a friend's computer, and setting them up for any of the above because I'm doing it at the wrong time. I'm not logging in from the IP address that happens to have been used by a griefer who's gotten tagged by someone running an over- aggressive ban list. I hope not, anyway. :) From secret.argent at gmail.com Mon Jul 9 19:01:12 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 9 19:01:04 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070710013600.8F29341AFEC@stupor.lindenlab.com> References: <20070710013600.8F29341AFEC@stupor.lindenlab.com> Message-ID: Nicholaz Beresford wrote: > Well, the last time I checked (at least in the non 3rd world > countries), it took a police search warrant (or similar legal > construct) to connect an IP to real world person. You just pointed out in another message that this is not actually the case. From gigstaggart at gmail.com Mon Jul 9 18:13:33 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 9 19:10:34 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070710025757.o5r2avxe88kcoggg@datendelphin.net> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <20070710025757.o5r2avxe88kcoggg@datendelphin.net> Message-ID: <4692DD3D.500@gmail.com> Boroondas Gupte wrote: > Unless you either use tor or don't use any (untrusted) services > requiring RL data at all, you have to assume your RL data and IP already > can be connected, so if SL want's to provide anonymous use it shouldn't > reveal them. That such will is existant can be seen from point four of > the Community Standards . The Community Standards are in the process of being phased out anyway: "Linden Lab is carefully planning the move to this federated model, and during the transition we'll continue to enforce the Community Standards. Note that after the transition, all of Second Life will still be required to abide by the Terms of Service, even though local community standards may vary." So apparently, once this undetermined "transition" is over, the community standards won't exist, replaced with various "local standards". I believe this is tied to ARs going directly to estate owners. To put this in context, someone could easily offer "anonymous" islands that forbid external content that would reveal IP. Those places would probably be kind of dull, however. -Jason From seg at haxxed.com Mon Jul 9 20:40:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jul 9 20:39:51 2007 Subject: [sldev] Audio Device Confusion w/Voice First Look Viewer In-Reply-To: <4692ABB5.7080203@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <65538E51-7141-421D-B7B3-CE99163332B0@gmail.com> <4692ABB5.7080203@gmail.com> Message-ID: <1184038820.5428.2.camel@localhost> On Mon, 2007-07-09 at 22:42 +0100, Robin Cornelius wrote: > Your lucky you've got sound at all. Think of us poor Linux folks where > sound is a lottery. Currently I have a libc incompatibility with fmod so > i can't even start the viewer with sound enabled, i need try to chase > this one down as it is a real grind for me now. Working on it: http://www.haxxed.com/code/slviewer-1.17.1.0-openal-20070703.patch And, if pre-built Fedora RPMs are any use to you: http://www.haxxed.com/rpms/secondlife/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070709/c5c3368a/attachment.pgp From chance at kalacia.com Mon Jul 9 21:15:22 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jul 9 21:15:24 2007 Subject: [sldev] Working on an installer, anybody figured out licensing yet_ In-Reply-To: <20070708234710.GB23822@bruno.sbruno> References: <20070708234710.GB23822@bruno.sbruno> Message-ID: <2925011a0707092115y89ab6a5n6beef0e4418a1915@mail.gmail.com> LL has a branding policy you need to follow for use of their images on other hosted media such as websites, assume that you would have to follow something to use their copyrighted images. in as far as it goes, you might just want to get your own mascot for installer branding and avoid their images. since you are forking and rebuilding from open source - erm sources - its worth considering how to differentiate your viewer. different versioning is confusing, and is the intent to identify to the grid, the user, or ___? since they havent identified how forks are to connect to their grid, this is a great question. if you rebuild using their sources without change, then you will identify just as the official viewer does. caveat emptor. what you are describing is a fork from the original baseline? are you going to track version numbers or use your own? are you adding only bug fixes (in which case, whats the problem with submission back to the original baseline)? the group or team that forks from the original baseline generally assumes the responsiblity for licensing compliance on the forked project, is it your intent to follow up on that as part of the fork? if you are just pissed at the installer, then open source yours and submit it to replace the one that resembles the nullsoft installer? On 7/8/07, dale@daleglass.net wrote: > > Hiya :-) > > I've been working on an installer again. Previous approach was ugly and > required .NET, so I got rid of that. > > Instead I decided to tackle two problems at once: Redistribution > restrictions, and updates. > > Both are solved in the same way: > > Installer just carries a file list with it, with filename and MD5 sum. > When you install, it checks whether the file is already there. If not, > or the md5sum is wrong, it checks all SL installs and tries to find it > there. If not, it downloads. > > The files that can't be redistributed aren't on my server, so if they're > needed and can't be found locally, the install fails. > > All this is coded in NSIS with a MD5 and a file decompression plugin. > > This way, even the first install of my version of the viewer will grab > already installed files, and further updates will be just what changed. > No more 25MB downloads. > > > Now, I'd like to make my installer include as many files as possible to > make sure it doesn't need very specific official SL versions to be > installed. > > So, anybody figured out what can be redistributed yet? If so, a wiki > page on it would be very helpful. > > A number of DLLs in the package don't come with the source, but I think > that some of them must be redistributable. > > These are the files in the main directory: > > dbghelp.dll, msvcp71.dll, msvcr71.dll: Microsoft runtime stuff, I assume > redistributable. > > fmod.dll: Not sure, might be. Could be specifically downloaded from the > fmod website, I suppose. > > freebl3.dll, js3250.dll, nspr4.dll, nss3.dll, nssckbi.dll, plc4.dll, > plds4.dll, smime3.dll, softokn3.dll, ssl3.dll, xul.dll: Mozilla stuff, > given the Mozilla license I assume they're redistributable. > > app_settings/mozilla: I assume redistributable > > xpcom.dll, gksvggdiplus.dll: Definitely redistributable, license stated > as "License: MPL 1.1/GPL 2.0/LGPL 2.1". > > llkdu.dll: Apparently not redistributable. > > So, at first glance, except llkdu.dll and perhaps fmod.dll, everything > else should be fine to redistribute? > > > Questions for LL: > > Other than library redistibution restrictions, what other things are > there to have in mind when releasing a custom viewer? > > Can I just package the results of the complication as-is, or do I need > to do something more? > > For example, can I leave the SL icon as it is, or I'd have to have my > own branding? > > Should my viewer identify itself as a third party viewer to the grid? > > Do I need to remove or disable anything (crash reporter, for example)? > > > > _______________________________________________ > 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/20070709/b8ddfe32/attachment.htm From chance at kalacia.com Mon Jul 9 21:21:33 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jul 9 21:21:35 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <46927FBF.4030302@knowprose.com> References: <468EF56A.9000400@dzonux.net> <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> <46924880.6090502@gmail.com> <46927FBF.4030302@knowprose.com> Message-ID: <2925011a0707092121p6e91a4fdn3184aead55a529e5@mail.gmail.com> at what point do i need to establish a torrent for textures when there are only 3 people there? this seems to be an overdesign to a problem that isnt present. torrents for 3 arent way cool. On 7/9/07, Taran Rampersad wrote: > > > >> * are there any legal issues? What happens if a texture is being > infringed > >> upon and someone overzealous decides to subpoena everyone who is > >> distributing the texture, or worse, if the textures are highly illegal > >> pictures. The liability doesn't just have to be remote or theoretical, > it > >> has to be non-existent since no one but LL can claim a common carrier > status > >> > >> > > Whew. This has happened before - I believe the case is still in court > > after nearly 8 years. > > > Which case? > >> I don't mean to be critical, but it doesn't seem like any of the above > is > >> taken into consideration and it's being debated without there being any > >> actual need or practical purpose. > I'd go with 'not feasible at this time or in the near future'. The > bandwidth usage would probably stay constant, and may even increase. > > -- > Taran Rampersad > 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 > > _______________________________________________ > 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/20070709/c5c21bd6/attachment-0001.htm From jhurliman at wsu.edu Mon Jul 9 21:26:26 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jul 9 21:28:06 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692E28A.4020502@blueflash.cc> Message-ID: <46930A72.5070302@wsu.edu> Argent Stonecutter wrote: >> did you know that every email to this list reveals your >> IP to a few hundred people whom you don't know? > > I'm not the alt of someone who's achieved some kind of fame or > notoriety in SL, who just wants to hang out without getting IMed all > the time. What does that have to do with revealing your IP address? John From chance at kalacia.com Mon Jul 9 21:30:44 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jul 9 21:30:46 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> Message-ID: <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> i got your IP the minute you visited my hosted website. so your issue with "privacy" is what? On 7/9/07, Argent Stonecutter wrote: > > > Mallory just uses the the Parcel Media Stream to set a specific URL > > call for > > Alice and gets her IP without any fuss or muss or any changes to > > the current > > SL codebase.... as long as Alice isn't on Linux. > > That only works if: > > a. Alice visits a parcel that Mallory owns, and > b. Alice has media streaming on. > > The original scenario would only require that Mallory *or* a scripted > object controlled by Mallory be able to get into draw distance of > Alice. That scripted object could be an object on land owned by > Mallory, an object Mallory leaves in land with build set and no > autoreturn, an object on land owned by any group Mallory is in... > including any malls he rents space on, OR an object that Mallory > passes out as a transferrable freebie containing a no-mod script. > > This means that: > > a. The potential exposure is several decimal orders of magnitude > greater unless Mallory is a Land Baron *and* is willing to devote the > media streams of all Mallory's land to the search, and even then > there's multiple decimal orders of magnitude greater exposure via web > textures than media streams. > b. Alice has no effective countermeasure within an unmodified client. > > "But your IP wouldn't be safe" is *not* a straw man argument. > _______________________________________________ > 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/20070709/6dd0751c/attachment.htm From kerdezixe at gmail.com Mon Jul 9 21:38:36 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Jul 9 21:38:38 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> Message-ID: <8a1bfe660707092138qba6e0fcvfcd39917f1b49c91@mail.gmail.com> The problem isn't the privacy itself, but "how people feel save and anonymous ?" and the folk on SL is paranoid about that. -- kerunix Flan On 7/10/07, Chance Unknown wrote: > i got your IP the minute you visited my hosted website. so your issue with > "privacy" is what? > > > > On 7/9/07, Argent Stonecutter wrote: > > > Mallory just uses the the Parcel Media Stream to set a specific URL > > > call for > > > Alice and gets her IP without any fuss or muss or any changes to > > > the current > > > SL codebase.... as long as Alice isn't on Linux. > > > > That only works if: > > > > a. Alice visits a parcel that Mallory owns, and > > b. Alice has media streaming on. > > > > The original scenario would only require that Mallory *or* a scripted > > object controlled by Mallory be able to get into draw distance of > > Alice. That scripted object could be an object on land owned by > > Mallory, an object Mallory leaves in land with build set and no > > autoreturn, an object on land owned by any group Mallory is in... > > including any malls he rents space on, OR an object that Mallory > > passes out as a transferrable freebie containing a no-mod script. > > > > This means that: > > > > a. The potential exposure is several decimal orders of magnitude > > greater unless Mallory is a Land Baron *and* is willing to devote the > > media streams of all Mallory's land to the search, and even then > > there's multiple decimal orders of magnitude greater exposure via web > > textures than media streams. > > b. Alice has no effective countermeasure within an unmodified client. > > > > "But your IP wouldn't be safe" is *not* a straw man argument. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From matsuu at gmail.com Mon Jul 9 21:41:42 2007 From: matsuu at gmail.com (MATSUU Takuto) Date: Mon Jul 9 21:41:45 2007 Subject: [sldev] 1.17.3 Source now available In-Reply-To: <468EE29F.3090203@lindenlab.com> References: <468EE29F.3090203@lindenlab.com> Message-ID: hi In 1.17.3.0, it seems that libllresolv6 is added and use instead of libresolv. What is the different between libllresolv6 and libresolv? and could I get the source of libllresolv6? 2007/7/7, Joshua Bell : > It was posted earlier today on the Wiki, but mail wasn't sent: > > http://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.3.0 > > Have at it! > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From chance at kalacia.com Mon Jul 9 21:46:10 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jul 9 21:46:13 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <8a1bfe660707092138qba6e0fcvfcd39917f1b49c91@mail.gmail.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> <8a1bfe660707092138qba6e0fcvfcd39917f1b49c91@mail.gmail.com> Message-ID: <2925011a0707092146k78f02406ra61cb4f60026e628@mail.gmail.com> well then maybe its time to get a clue? you are using the internet people..... On 7/9/07, Laurent Laborde wrote: > > The problem isn't the privacy itself, but "how people feel save and > anonymous ?" > and the folk on SL is paranoid about that. > > -- > kerunix Flan > > On 7/10/07, Chance Unknown wrote: > > i got your IP the minute you visited my hosted website. so your issue > with > > "privacy" is what? > > > > > > > > On 7/9/07, Argent Stonecutter wrote: > > > > Mallory just uses the the Parcel Media Stream to set a specific URL > > > > call for > > > > Alice and gets her IP without any fuss or muss or any changes to > > > > the current > > > > SL codebase.... as long as Alice isn't on Linux. > > > > > > That only works if: > > > > > > a. Alice visits a parcel that Mallory owns, and > > > b. Alice has media streaming on. > > > > > > The original scenario would only require that Mallory *or* a scripted > > > object controlled by Mallory be able to get into draw distance of > > > Alice. That scripted object could be an object on land owned by > > > Mallory, an object Mallory leaves in land with build set and no > > > autoreturn, an object on land owned by any group Mallory is in... > > > including any malls he rents space on, OR an object that Mallory > > > passes out as a transferrable freebie containing a no-mod script. > > > > > > This means that: > > > > > > a. The potential exposure is several decimal orders of magnitude > > > greater unless Mallory is a Land Baron *and* is willing to devote the > > > media streams of all Mallory's land to the search, and even then > > > there's multiple decimal orders of magnitude greater exposure via web > > > textures than media streams. > > > b. Alice has no effective countermeasure within an unmodified client. > > > > > > "But your IP wouldn't be safe" is *not* a straw man argument. > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > 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/20070709/1fc6ff11/attachment.htm From seg at haxxed.com Mon Jul 9 22:13:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jul 9 22:13:05 2007 Subject: [sldev] 1.17.3 Source now available In-Reply-To: References: <468EE29F.3090203@lindenlab.com> Message-ID: <1184044421.5428.7.camel@localhost> On Tue, 2007-07-10 at 13:41 +0900, MATSUU Takuto wrote: > hi > > In 1.17.3.0, it seems that libllresolv6 is added and use instead of libresolv. > What is the different between libllresolv6 and libresolv? > and could I get the source of libllresolv6? https://jira.secondlife.com/browse/VWR-1598 Its an API that the glibc people really don't want anyone to use, it seems. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/2dbd5fa8/attachment.pgp From tateru.nino at gmail.com Tue Jul 10 00:52:15 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jul 10 00:52:21 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <2925011a0707092146k78f02406ra61cb4f60026e628@mail.gmail.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> <8a1bfe660707092138qba6e0fcvfcd39917f1b49c91@mail.gmail.com> <2925011a0707092146k78f02406ra61cb4f60026e628@mail.gmail.com> Message-ID: <46933AAF.6080803@gmail.com> Well, if I have your avatar name, and IP - and let's face it, if you've commented on a blog I run, I probably do, or if I glom it through a media-stream trick, or if you posted to a mailing list just like this one - there _are_ things I can do to isolate your real identity. I can check the contributions in wikipedia associated with your IP address, or search through publically archived email lists to establish other identities you may have, real or assumed. Contributory or outspoken people are pretty easy to find all things considered. I'm not taking a side on good/bad here, because (frankly) I don't have one. However, that's basically the primary, easy-to-do use of IP addresses *if* you want to compromise or discover someone's identity. I don't have any interest in doing so, and I bet most or none of you do either. There will always be a few who do though, I suppose. Chance Unknown wrote: > well then maybe its time to get a clue? you are using the internet > people..... > > On 7/9/07, *Laurent Laborde* > wrote: > > The problem isn't the privacy itself, but "how people feel save > and anonymous ?" > and the folk on SL is paranoid about that. > > -- > kerunix Flan > > On 7/10/07, Chance Unknown > wrote: > > i got your IP the minute you visited my hosted website. so your > issue with > > "privacy" is what? > > > > > > > > On 7/9/07, Argent Stonecutter > wrote: > > > > Mallory just uses the the Parcel Media Stream to set a > specific URL > > > > call for > > > > Alice and gets her IP without any fuss or muss or any changes to > > > > the current > > > > SL codebase.... as long as Alice isn't on Linux. > > > > > > That only works if: > > > > > > a. Alice visits a parcel that Mallory owns, and > > > b. Alice has media streaming on. > > > > > > The original scenario would only require that Mallory *or* a > scripted > > > object controlled by Mallory be able to get into draw distance of > > > Alice. That scripted object could be an object on land owned by > > > Mallory, an object Mallory leaves in land with build set and no > > > autoreturn, an object on land owned by any group Mallory is in... > > > including any malls he rents space on, OR an object that Mallory > > > passes out as a transferrable freebie containing a no-mod script. > > > > > > This means that: > > > > > > a. The potential exposure is several decimal orders of magnitude > > > greater unless Mallory is a Land Baron *and* is willing to > devote the > > > media streams of all Mallory's land to the search, and even then > > > there's multiple decimal orders of magnitude greater exposure > via web > > > textures than media streams. > > > b. Alice has no effective countermeasure within an unmodified > client. > > > > > > "But your IP wouldn't be safe" is *not* a straw man argument. > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From dale at daleglass.net Tue Jul 10 01:18:29 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jul 10 01:18:47 2007 Subject: [sldev] Working on an installer, anybody figured out licensing yet_ In-Reply-To: <2925011a0707092115y89ab6a5n6beef0e4418a1915@mail.gmail.com> References: <20070708234710.GB23822@bruno.sbruno> <2925011a0707092115y89ab6a5n6beef0e4418a1915@mail.gmail.com> Message-ID: <20070710081829.GB11981@bruno.sbruno> On Mon, Jul 09, 2007 at 09:15:22PM -0700, Chance Unknown wrote: > LL has a branding policy you need to follow for use of their images on other > hosted media such as websites, assume that you would have to follow > something to use their copyrighted images. in as far as it goes, you might > just want to get your own mascot for installer branding and avoid their > images. Installer doesn't use the SL logo currently (has the default NSIS one), but the icon on the binary is the LL-provided one ATM. Wondering what other things should I do. For example: * Change the name in the title bar * Replace the login screen * Modify the help menu to avoid bug submission to LL * Change the interface color to make it clearly visible it's not offical etc There are two angles I'm interested in here: The LL one: What I MUST do to avoid problems. Licensing issues, too. End-user one: How far should I go for the sake of the end user. I expect that non-technically minded people will try it, so I'm wondering how to best present it in such a way that avoids confusion. > since you are forking and rebuilding from open source - erm sources - its > worth considering how to differentiate your viewer. different versioning is > confusing, and is the intent to identify to the grid, the user, or ___? > since they havent identified how forks are to connect to their grid, this is > a great question. if you rebuild using their sources without change, then > you will identify just as the official viewer does. caveat emptor. IIRC, if I identify as a third party client, I get to skip the version check. Which probably would be a good thing, since otherwise in the interval between the release of a required new version, and the release and compilation of new source, users of my viewer couldn't log in. > what you are describing is a fork from the original baseline? are you going > to track version numbers or use your own? are you adding only bug fixes (in > which case, whats the problem with submission back to the original Sort for a fork, but not a drastic one. Standard client, plus my improvements. Current improvements include: * Avatar scanner, which shows information about people found nearby. It can do things like moving the camera to an avatar, opening profile windows, sending IM, administrative stuff, etc. Currently not polished enough for integration. * Integration with my reputation system. Doubtful that such a thing would ever get integrated into the official viewer, as it requires a subscription. * Modifications for dealing with griefers. For example, there's a hack to log the names of avatars who own objects that emit sounds, but aren't found nearby. There are probably too specific, and not nearly polished enough for general usage. I don't think integration of third party commercial services into the official viewer is something that's going to happen any time soon. Over time I plan to track the official viewer, so this isn't intended to be a fork that goes in a radically different direction. > baseline)? the group or team that forks from the original baseline generally > assumes the responsiblity for licensing compliance on the forked project, is > it your intent to follow up on that as part of the fork? if you are just > pissed at the installer, then open source yours and submit it to replace the > one that resembles the nullsoft installer? Will OSS the installer, as soon as I get it working properly, which should be soon. For me, a custom installer is a requirement, as I can't ship llkdu.dll. So mine grabs it from an existing install. My understanding is that using OpenJPEG instead should result in a fully redistributable package, but it still has some bugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/f6bbcb79/attachment.pgp From blakar at gmail.com Tue Jul 10 02:23:08 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jul 10 02:23:11 2007 Subject: [sldev] P2P Web Textures now in demand to enable lossless image downloads to viewer In-Reply-To: <2925011a0707092121p6e91a4fdn3184aead55a529e5@mail.gmail.com> References: <468EF56A.9000400@dzonux.net> <002a01c7c235$fd2d2d00$0501a8c0@devbits.intra> <46924880.6090502@gmail.com> <46927FBF.4030302@knowprose.com> <2925011a0707092121p6e91a4fdn3184aead55a529e5@mail.gmail.com> Message-ID: <7992d0d60707100223p34e1661ay32484ba94ca9ded7@mail.gmail.com> On 7/10/07, Chance Unknown wrote: > this seems to be an overdesign to a problem that isnt present. Best summary I've seen upto now. Current bandwidth available from SL to me has never seemed to be problematic (and I'm in Europe so not exactly close). A P2P network would have to be very good for it to have any chance at beating that. Peer selection algorithms would be a pain for example and the chances that you find a high bandwidth peer are low. The overhead would kill any chance at achieving something. Why not just serve pointers to textures from sims and download all of them using http? You can set up as many proxies as you want (both LL and third party controlled). Sim hosters could easily set up their own squid and have it prefetch the textures related to their sim. You could for example allow proxies to send requests to a sim that ask it to give all the currently active textures on a sim after which the proxy can then autofeed itself in a timely manner from the main LL servers. As such a community can run their own proxies and have their own content served at high speeds (mostly interesting if the community is focused on a specific rl geographic region). In this way you could have ISP's even set up dedicated SL proxies tuned specifically for caching SL content. Or you could move towards a system where sims inform the client of dedicated proxies for that sim. At all times the goal should remain to have a solution that works in a simple, efficient way without too much overhead for peer or proxy selection. Dirk aka Blakar Ogre From blakar at gmail.com Tue Jul 10 02:24:09 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jul 10 02:24:12 2007 Subject: Fwd: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <7992d0d60707100157v54b156echac353e4e82f319b8@mail.gmail.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> <8a1bfe660707092138qba6e0fcvfcd39917f1b49c91@mail.gmail.com> <2925011a0707092146k78f02406ra61cb4f60026e628@mail.gmail.com> <46933AAF.6080803@gmail.com> <7992d0d60707100157v54b156echac353e4e82f319b8@mail.gmail.com> Message-ID: <7992d0d60707100224q65997263x425bce2048c0040a@mail.gmail.com> --- misclicked and list did not a copy --- I think this mailing list is a poor place to discuss this as few here are putting on the right hat when thinking about it. The type of attackers we need to analyse are griefers. The type of application we're dealing with is, just like the chat networks have always been, attractive to griefers. The pattern in such a case is that they'll go for instant gratification as much as possible. Hence they want to have your IP at that moment. They'll hence exploit any technique that helps them to easily and immediately get your IP at that moment. Opening up new ways to do so is likely to cause a rise in abuse. For me personally I don't care but it's the millions of ordinary users out there who'll never understand what's happening that will benefit from keeping their IP private as much as possible. I also don't think all the numerous examples of how people can get your IP are relevant. It's not the point. It's not because they already can (in many cases with a lot more effort) that it's ok to open up a new way and easy way to do so. Dirk aka Blakar Ogre From dale at daleglass.net Tue Jul 10 02:31:02 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jul 10 02:31:11 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <4692DC1C.9060108@blueflash.cc> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> Message-ID: <20070710093102.GA32710@bruno.sbruno> On Tue, Jul 10, 2007 at 03:08:44AM +0200, Nicholaz Beresford wrote: > Ummm, I'm probably missing the point of this discussion completely, > but what exactly do you think is this attacker doing with your > your IP address? DoS, for instance > I mean what is he doing different from that > which about 20+ people per hour aren't trying already through > IP scan. That on SL you can connect it to a name (even avatar name), and a random IP scan doesn't. Think IRC -- Doing something nasty to another person's computer is pretty common there, and people don't pick targets at random. If Bob is on IRC, and Mallory hates him for some reason, and the IRC server makes the IP addresses visible, then Mallory has all the required data to attack Bob specifically. Now, DoS is illegal of course, but it doesn't mean it won't happen, and it's a fuzzy concept as well. You can perform a DoS without making it really obvious it's an attack. For instance, there are plenty people with very low upload speeds. If you find this person runs a webserver or some other service that it's possible to download lots of data from, you don't even need to do anything particularly malicious. Just connect to the server, with maybe just 1-3 connections (to avoid looking obviously evil), and start downloading. On many connections that'll cause plenty lag. They can take the server down, but if you managed that, that's a DoS in itself. IMO, in SL this is even more likely. On IRC it's just name, on SL there are multiple well known groups targeted by various morons, who are identifiable by the way they look. And since there even are people trying to bring the grid down, despite LL's attempt at prosecution, I doubt legal threats are enough to dissuade everybody. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/e2b70c76/attachment.pgp From gigstaggart at gmail.com Tue Jul 10 02:42:44 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 10 02:43:10 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070710093102.GA32710@bruno.sbruno> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> Message-ID: <46935494.7070007@gmail.com> dale@daleglass.net wrote: > Think IRC -- Doing something nasty to another person's computer is > pretty common there, and people don't pick targets at random. An excellent example of a large, successful, platform, where they don't even attempt to obscure IPs from other users. I bet some of their users even cry about it too. http://www.petitiononline.com/sign4me3/petition.html Yeah, looks like all of 20 people on efnet care about it. -Jason From dale at daleglass.net Tue Jul 10 03:01:14 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jul 10 03:01:20 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <46935494.7070007@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <46935494.7070007@gmail.com> Message-ID: <20070710100114.GA32495@bruno.sbruno> On Tue, Jul 10, 2007 at 05:42:44AM -0400, Jason Giglio wrote: > dale@daleglass.net wrote: > >Think IRC -- Doing something nasty to another person's computer is > >pretty common there, and people don't pick targets at random. > > An excellent example of a large, successful, platform, where they don't > even attempt to obscure IPs from other users. I bet some of their users > even cry about it too. Actually, some networks do hide it. See this for example: http://www.link-net.org/index.php?sec=8 > > http://www.petitiononline.com/sign4me3/petition.html > > Yeah, looks like all of 20 people on efnet care about it. IRC doesn't worry me much, as I either don't log in at all, or ssh into another box, and log in from there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/c3fc7c0c/attachment.pgp From blakar at gmail.com Tue Jul 10 03:18:22 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jul 10 03:18:26 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <46935494.7070007@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <46935494.7070007@gmail.com> Message-ID: <7992d0d60707100318r5fe02647r473e8c89681772cd@mail.gmail.com> So that petition is the best way to establish how many users are interested in it? What a laugh. All IRC networks have been plagued by this and I'm sure even EFNet considered hiding at some point, we all did and went thru a few different ways of doing so. On Undernet I wasn't really happy with it either but I had a bit too much the attitude you show now. For me it didn't matter but it sure did for other more "ordinary" people. Dirk aka Blakar Ogre On 7/10/07, Jason Giglio wrote: > dale@daleglass.net wrote: > > Think IRC -- Doing something nasty to another person's computer is > > pretty common there, and people don't pick targets at random. > > An excellent example of a large, successful, platform, where they don't > even attempt to obscure IPs from other users. I bet some of their users > even cry about it too. > > http://www.petitiononline.com/sign4me3/petition.html > > Yeah, looks like all of 20 people on efnet care about it. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From pnolan at dsl.pipex.com Tue Jul 10 03:35:17 2007 From: pnolan at dsl.pipex.com (Paul Nolan) Date: Tue Jul 10 03:35:31 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <7992d0d60707100318r5fe02647r473e8c89681772cd@mail.gmail.com> Message-ID: Hi, I'm new to this, so please forgive if this is a silly question. I've got the source, but it failed to compile under linux (Ubuntu 7.04 - fiesty) The issue was a missing openssl header, needed for llblowfish.cpp which I fixed. My question is this - is this suitable for inclusion in the issue tracker, as a workaround ? And can anyone offer me guidance on the most approriate topic. (still learning) Paul. From pnolan at dsl.pipex.com Tue Jul 10 03:37:11 2007 From: pnolan at dsl.pipex.com (Paul Nolan) Date: Tue Jul 10 03:37:13 2007 Subject: [sldev] Ooops In-Reply-To: Message-ID: And even forgot to change the title. (blushes in a very newbie way...) Paul. It was 10/7/07 11:35, when "Paul Nolan" wrote: > Hi, > > I'm new to this, so please forgive if this is a silly question. > > I've got the source, but it failed to compile under linux (Ubuntu 7.04 - > fiesty) > > The issue was a missing openssl header, needed for llblowfish.cpp which I > fixed. > > My question is this - is this suitable for inclusion in the issue tracker, > as a workaround ? > > And can anyone offer me guidance on the most approriate topic. > > (still learning) > > Paul. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dale at daleglass.net Tue Jul 10 03:41:08 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jul 10 03:41:19 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: References: <7992d0d60707100318r5fe02647r473e8c89681772cd@mail.gmail.com> Message-ID: <20070710104108.GB32495@bruno.sbruno> On Tue, Jul 10, 2007 at 11:35:17AM +0100, Paul Nolan wrote: > Hi, > > I'm new to this, so please forgive if this is a silly question. > > I've got the source, but it failed to compile under linux (Ubuntu 7.04 - > fiesty) > > The issue was a missing openssl header, needed for llblowfish.cpp which I > fixed. > > My question is this - is this suitable for inclusion in the issue tracker, > as a workaround ? You're probably not doing it correctly, see the instructions on the wiki: http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29 Specifically, you need the library package, as well as copying the files mentioned in that page to the right locations. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/67100b39/attachment.pgp From robin.cornelius at gmail.com Tue Jul 10 04:22:11 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 10 04:22:14 2007 Subject: [sldev] 1.17.3 Source now available In-Reply-To: <468EE29F.3090203@lindenlab.com> References: <468EE29F.3090203@lindenlab.com> Message-ID: On 7/7/07, Joshua Bell wrote: > It was posted earlier today on the Wiki, but mail wasn't sent: > > http://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.3.0 > Just managed to get my (windows) build environment working but hit a few extra hoops I had to jump through. Not sure if I missed an instruction somewhere. I needed to copy the app_settings/static_data.db2 and app_settings/static_index.db2 file from a production viewer into place Also seems that on 1.17.3 the character dir is missing as well and need to copy across from production viewer or the viewer crashes ungracefully as it cannot open some of its xml files. After that I got in world with my viewer and promptly crashed about 1 minute later, now for the post mortum..... Robin Cornelius http://www.byteme.org.uk From robin.cornelius at gmail.com Tue Jul 10 05:08:04 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 10 05:08:07 2007 Subject: [sldev] UI Skin Message-ID: Hi everyone, Sorry to be a stupid noob, but what extra stage to you have to do to get the UI to resemble the official build on a custom build from (standard) source (with Visual C 2003.Net). I seem to be missing the various top bar icons and the graphics used for the buttons at the bottom and various preference menus etc. Thanks in advance! Robin -- Robin Cornelius http://www.byteme.org.uk From nicholaz at blueflash.cc Tue Jul 10 05:21:42 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 10 05:21:50 2007 Subject: [sldev] UI Skin In-Reply-To: References: Message-ID: <469379D6.2040605@blueflash.cc> Robin Cornelius wrote: > Hi everyone, > > Sorry to be a stupid noob, but what extra stage to you have to do to > get the UI to resemble the official build on a custom build from > (standard) source (with Visual C 2003.Net). I seem to be missing the > various top bar icons and the graphics used for the buttons at the > bottom and various preference menus etc. Did you download the artwork packet? Nick From nicholaz at blueflash.cc Tue Jul 10 05:28:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 10 05:28:21 2007 Subject: [sldev] UI Skin In-Reply-To: References: Message-ID: <46937B60.4050609@blueflash.cc> > Sorry to be a stupid noob, but what extra stage to you have to do to > get the UI to resemble the official build on a custom build from > (standard) source (with Visual C 2003.Net). I seem to be missing the > various top bar icons and the graphics used for the buttons at the > bottom and various preference menus etc. Of for a start try building the 1.17.2, that one seems to compile fine with the instructions (you'll just need to add the includes for the png stuff). Nick From robin.cornelius at gmail.com Tue Jul 10 05:34:27 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Jul 10 05:34:30 2007 Subject: [sldev] UI Skin In-Reply-To: <469379D6.2040605@blueflash.cc> References: <469379D6.2040605@blueflash.cc> Message-ID: On 7/10/07, Nicholaz Beresford wrote: > > Robin Cornelius wrote: > > Hi everyone, > > > > Sorry to be a stupid noob, but what extra stage to you have to do to > > get the UI to resemble the official build on a custom build from > > (standard) source (with Visual C 2003.Net). I seem to be missing the > > various top bar icons and the graphics used for the buttons at the > > bottom and various preference menus etc. > > Did you download the artwork packet? > Ooops, i though it must be somthing simple! apart from that and the other little problems of missing files which looking at the artwork zip file it appears all my missing files were infact in there. Eveything else compiled fine (almost) first time, i hit the png.h missing and found the link to that and eveything else has gone according to the instructions. I am currently in world with my homebrew viewer so thats OK. I will add in the artwork zip file now and I should be 100% there!. Many thanks Sorry to be a PITA! Robin -- Robin Cornelius http://www.byteme.org.uk From nicholaz at blueflash.cc Tue Jul 10 05:41:21 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 10 05:41:26 2007 Subject: [sldev] UI Skin In-Reply-To: References: <469379D6.2040605@blueflash.cc> Message-ID: <46937E71.1080903@blueflash.cc> Robin Cornelius wrote: > Eveything else compiled fine (almost) first time, i hit the png.h > missing and found the link to that and eveything else has gone > according to the instructions. I am currently in world with my > homebrew viewer so thats OK. I will add in the artwork zip file now > and I should be 100% there!. Not a problem ... ran into the same problem when doing my first compile :-) Nick From tofu.linden at lindenlab.com Tue Jul 10 07:32:58 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Jul 10 07:33:01 2007 Subject: [sldev] CPU detection code In-Reply-To: <20070702185816.GA27731@bruno.sbruno> References: <20070629211515.7D90141AFFD@stupor.lindenlab.com> <20CE58FA-D68D-4DD5-B9A2-F01EADE88967@gmail.com> <7992d0d60707020937n6ff01b4cx186fa1b7d9799439@mail.gmail.com> <46893F00.1030303@daleglass.net> <7992d0d60707021110m1a6f250fr1657b47295ec474@mail.gmail.com> <20070702185816.GA27731@bruno.sbruno> Message-ID: <4693989A.6070704@lindenlab.com> dale@daleglass.net wrote: > Point still stands though, on Linux /proc/cpuinfo should be the easiest > and most accurate way to do it. I agree. -Tofu From soft at lindenlab.com Tue Jul 10 08:57:26 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 10 08:57:28 2007 Subject: [sldev] Compare functions (llspatialpartition.h) In-Reply-To: <468D1574.70502@blueflash.cc> References: <468D1574.70502@blueflash.cc> Message-ID: <9e6e5c9e0707100857u405e8eb6q79075d86eff733c6@mail.gmail.com> I'm adding this to my list of things to look at. It's probably harmless, but I should at least do a blame and ask if it was intentional. On 7/5/07, Nicholaz Beresford wrote: > > There are two compare functions in llspatialpartition.h which I believe > are wrong. > > When doing pointer compares, if NULL pointers are involved I think the > result should be consistent (i.e. a NULL either being always considered > more or less than a pointer value). With these implementations however, > NULL is considered greater if it appears as lhs, but if it appears as > rhs the function returns also TRUE, which implicitely means that NULL > is lesser (as far as I understand it, these compare functions for std::sort > are bound to return if left is greater than right. Also in case both are > NULL, I think false should be returned (neither is greater). > > Shouldn't that be (assuming that NULL should be greater, to be sorted to > the end of the list): > > return lhs != rhs && (lhs == NULL || (rhs != NULL && lhs->mTexture > rhs->mTexture)); > > Or am I missing something? > > > > Original snippet: > > struct CompareTexturePtr > { > bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) > { > > return lhs == NULL || rhs == NULL || lhs->mTexture > rhs->mTexture; > } > }; > > struct CompareBump > { > bool operator()(const LLDrawInfo* const& lhs, const LLDrawInfo* const& rhs) > { > return lhs == NULL || rhs == NULL || lhs->mBump > rhs->mBump; > } > }; > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Tue Jul 10 09:03:27 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 10 09:03:31 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> <468D4D8B.2010001@lindenlab.com> <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> Message-ID: <9e6e5c9e0707100903n2ae215a3p2244454d63510968@mail.gmail.com> I don't have hard answers on this myself, and unfortunately Liana, the key licensing person, is out this week. But you might want to be sure you're on top of Dale Glass' work on redistribution (another thread). He's tackling the same problem here, is doing a lot of research on the library licenses, and has made an installer that attempts to be fully compliant. On 7/5/07, Able Whitman wrote: > Rob, > > I apologize, I haven't been clear enough in asking my questions. I'm not > asking you, or anyone else, to interpret the licensing agreements for the > component libraries for me. Like you said, the licenses are included and the > onus is on me to adhere to them. > > Assuming that I have taken the responsibility for adhering to all the > various component licenses, if I also adhere to the guidelines for > distributing the software itself ( > http://secondlife.com/corporate/trademark/distribution.php), > as well as the trademark usage for web and print material > (http://secondlife.com/corporate/trademark/print_web.php ) > and the policy for fan sites > (http://secondlife.com/community/fansites_regs.php), will > it be permissible for me to distribute an installer for the viewer built > using the scripts included with the viewer source, or are there other > guidelines I need to follow as well? > > --Able > > > On 7/5/07, Rob Lanphier wrote: > > Hi Able, > > > > I'm not going to be able to get you off the hook for reading and > > understanding all of the license files in order to redistribute a > > product based on them. It puts me in dangerous territory to try to > > paraphrase them. > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From liana at lindenlab.com Tue Jul 10 09:05:42 2007 From: liana at lindenlab.com (Liana Holmberg) Date: Tue Jul 10 09:05:37 2007 Subject: [sldev] Announcing the Linden Lab Innovation Awards Message-ID: <4693AE56.9090307@lindenlab.com> Dear Second Life Open Source Community Members: We are pleased to announce the inception of the annual Linden Lab Innovation Awards for excellence in developing the Second Life platform. The awards will acknowledge open source contributors who have made the biggest impact on the quality and advancement of the Second Life Viewer. We are now accepting nominations from the SL open source community for the 2007 Linden Lab Innovation Awards. Judges will include Linden developers and open source team members. Award winners will be announced during the Second Life Community Convention. How It Works 1. Nominations If you would like to nominate an open source developer or open source community contributor, then * sign in to the Issue Tracker and add the person's Second Life avatar name as a subtask to the appropriate category (below), and * write a comment about what their contribution was and why you find it to be exemplary. Linden Lab employees and family members are not eligible. Nominations are open from now through 22 July 2007 23:59 PDT. This year's categories are: *Contributor of the Year https://jira.secondlife.com/browse/MISC-392 *Best Contribution https://jira.secondlife.com/browse/MISC-393 *Best Feature https://jira.secondlife.com/browse/MISC-394 *Best Bug Hunter https://jira.secondlife.com/browse/MISC-395 *Best Community Organizer https://jira.secondlife.com/browse/MISC-396 2. Judging Judges will be announced separately and will include Linden developers and open source team members. These are juried awards, and they will be awarded based on a set of criteria and point system used by the judges. A note about voting: JIRA has this nifty voting feature. You are welcome to vote for nominees you believe have merit. However, winners will not be selected by popular vote but through the juried process above. 3. Awards Award winners will be announced in Second Life and during the Second Life Community Convention, held August 24-26 in Chicago, IL (http://slcc2007.wordpress.com/). A later announcement will give the date, time, and location of this event. The Contributor of the Year will receive a MacBook Pro. We appreciate all the contributions of the Second Life open source community, and we'll be listening to your feedback and recommendations for improving the awards program for next year. Please add constructive comments to this wiki https://wiki.secondlife.com/wiki/Linden_Lab_Innovation_Awards. Any questions, post them to sldev@lists.secondlife.com or email liana@lindenlab.com. Thanks, Liana - - - - - The LINDEN LAB INNOVATION AWARDS are for entertainment purposes only and have no monetary or other value. LINDEN LAB, LINDEN RESEARCH, and SECOND LIFE are trademarks or registered trademarks of Linden Research, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/fad5527c/attachment.htm From chance at kalacia.com Tue Jul 10 09:08:51 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jul 10 09:08:54 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070710093102.GA32710@bruno.sbruno> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> Message-ID: <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> since your target is SL, the people most argumentitive about privacy concerns are the bored lonely housewives that sit at home looking for cyber affairs. of course they want their identities masked. they dont get that kind of privay when looking for a hookup at myspace or facebook. are there any demographics that places these particular consumers in the primary seat driving development? it has been demonstrated over the past number of years that the paying customers (private islands) dont tend to have influence over development, so why should an even smaller cluster of customers be the ones responsible for driving design goals? On 7/10/07, dale@daleglass.net wrote: > > On Tue, Jul 10, 2007 at 03:08:44AM +0200, Nicholaz Beresford wrote: > > Ummm, I'm probably missing the point of this discussion completely, > > but what exactly do you think is this attacker doing with your > > your IP address? > DoS, for instance > > > I mean what is he doing different from that > > which about 20+ people per hour aren't trying already through > > IP scan. > That on SL you can connect it to a name (even avatar name), and a random > IP scan doesn't. > > Think IRC -- Doing something nasty to another person's computer is > pretty common there, and people don't pick targets at random. > > If Bob is on IRC, and Mallory hates him for some reason, and the IRC > server makes the IP addresses visible, then Mallory has all the required > data to attack Bob specifically. > > Now, DoS is illegal of course, but it doesn't mean it won't happen, and > it's a fuzzy concept as well. You can perform a DoS without making it > really obvious it's an attack. > > For instance, there are plenty people with very low upload speeds. If you > find this person runs a webserver or some other service that it's > possible to download lots of data from, you don't even need to do > anything particularly malicious. > > Just connect to the server, with maybe just 1-3 connections (to avoid > looking obviously evil), and start downloading. On many connections > that'll cause plenty lag. > > They can take the server down, but if you managed that, that's a DoS > in itself. > > > IMO, in SL this is even more likely. On IRC it's just name, on SL there > are multiple well known groups targeted by various morons, who are > identifiable by the way they look. > > And since there even are people trying to bring the grid down, despite > LL's attempt at prosecution, I doubt legal threats are enough to > dissuade everybody. > > _______________________________________________ > 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/20070710/77b6acd3/attachment.htm From jana at iastate.edu Tue Jul 10 09:26:40 2007 From: jana at iastate.edu (Jana Lepon) Date: Tue Jul 10 09:26:42 2007 Subject: [sldev] creating new windows Message-ID: Hi - I've been lurking on the list for a while, but this is my first post. I'm fairly new to the code, so apologies in advance if this is a stupid question... Right now, I'm trying to break up the UI to display floaters in new windows (outside of the viewer window.) Eventually, I'd like to have two windows running - one with the avatar, environment, and chat, and the other with menus and floaters. Is this feasible? If so, any tips on where to start would be greatly appreciated. Thank you! - Jana From able.whitman at gmail.com Tue Jul 10 09:33:06 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 10 09:33:10 2007 Subject: [sldev] Working on an installer, anybody figured out licensing yet_ In-Reply-To: <20070710081829.GB11981@bruno.sbruno> References: <20070708234710.GB23822@bruno.sbruno> <2925011a0707092115y89ab6a5n6beef0e4418a1915@mail.gmail.com> <20070710081829.GB11981@bruno.sbruno> Message-ID: <7b3a84fb0707100933m85a7dcer92cf71ae6baf5ad7@mail.gmail.com> Howdy Dale, I've been tackling many of the same issues you've been dealing with in trying to roll a custom, license-compliant installer. I reached the same conclusion that you did about the Kakadu library not being redistributable. IANAL, so I'm not sure if having your installer take a copy of the DLL from an existing official install could be construed as de facto redistribution. Aside from Kakadu, all the other OSS-licensed libraries are (as far as I can tell) freely redistributable. The Microsoft DLLs, dbghelp (see: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=CD1FC4B2-0885-47F4-AF45-7FD5E14DB6C0) and the msvcrt DLLs (see: http://msdn2.microsoft.com/en-US/library/abx4dbyh(VS.71).aspx) are also redistributable. In order to try and simplify my custom installer, I built one using NSIS which simply installs my custom viewer on top of an existing installation of the official viewer, in such a way that the two can run side-by-side. My installer requires that the user first install an official copy of the version of the viewer from which my custom build is derived from. (In my current case, this means requiring an official 1.17.3.0 install first.) Here are the changes I made to my client to accommodate this: 1. Change the build number (llversion.h) to a custom value, leaving the major, minor, and revision numbers the same. 2. My build requires changes to some XUL XML files, so I renamed the changed files by adding a "_aw" suffix to the filename 3. In conjunction with #2, I changed the source code to refer to my modified XML files, so that when my private build is executed it references the new, modified XML files, while the official viewer still references the original, unmodified files 4. Change the name of the crash dump files that are created by my viewer (handleException in llwindebug.cpp) so as not to overwrite crash dumps from the official viewer 5. Change the window class name for my viewer (gWindowName in viewer.cpp) 6. Change the name of the default settings XML file, so that the official viewer and my private build use different configs and do not stomp on one another, similar to First Look viewers (DEFAULT_SETTINGS_FILE in viewer.cpp; changing the value here has the advantage of not requiring special command line arguments) 7. Change the display name of the application (used as the window title, etc.) to include the phrase "unofficial edition" (gSecondLife, in WinMain, in viewer.cpp) 8. Change the executable name to not include the phrase "SecondLife" (I chose "AbleSL.exe") My installer does not use the SL logo, although the logo still remains as the icon for the executable in my private build. I believe that this use is consistent with the LL guidelines for use of their logo, but it's not difficult to change if it is not. I'd be happy to provide the NSI script I use and a diff for the source changes I mentioned, if they would be helpful. --Able On 7/10/07, dale@daleglass.net wrote: > > On Mon, Jul 09, 2007 at 09:15:22PM -0700, Chance Unknown wrote: > > LL has a branding policy you need to follow for use of their images on > other > > hosted media such as websites, assume that you would have to follow > > something to use their copyrighted images. in as far as it goes, you > might > > just want to get your own mascot for installer branding and avoid their > > images. > Installer doesn't use the SL logo currently (has the default NSIS one), > but the icon on the binary is the LL-provided one ATM. > > Wondering what other things should I do. For example: > > * Change the name in the title bar > * Replace the login screen > * Modify the help menu to avoid bug submission to LL > * Change the interface color to make it clearly visible it's not offical > etc > > There are two angles I'm interested in here: > > The LL one: What I MUST do to avoid problems. Licensing issues, too. > > End-user one: How far should I go for the sake of the end user. I expect > that non-technically minded people will try it, so I'm wondering how to > best present it in such a way that avoids confusion. > > > since you are forking and rebuilding from open source - erm sources - > its > > worth considering how to differentiate your viewer. different versioning > is > > confusing, and is the intent to identify to the grid, the user, or ___? > > since they havent identified how forks are to connect to their grid, > this is > > a great question. if you rebuild using their sources without change, > then > > you will identify just as the official viewer does. caveat emptor. > IIRC, if I identify as a third party client, I get to skip the version > check. Which probably would be a good thing, since otherwise in the > interval between the release of a required new version, and the release > and compilation of new source, users of my viewer couldn't log in. > > > > what you are describing is a fork from the original baseline? are you > going > > to track version numbers or use your own? are you adding only bug fixes > (in > > which case, whats the problem with submission back to the original > Sort for a fork, but not a drastic one. Standard client, plus my > improvements. > > Current improvements include: > * Avatar scanner, which shows information about people found nearby. > It can do things like moving the camera to an avatar, opening profile > windows, sending IM, administrative stuff, etc. Currently not polished > enough for integration. > > * Integration with my reputation system. Doubtful that such a thing > would ever get integrated into the official viewer, as it requires a > subscription. > > * Modifications for dealing with griefers. For example, there's a hack > to log the names of avatars who own objects that emit sounds, but > aren't found nearby. There are probably too specific, and not nearly > polished enough for general usage. > > I don't think integration of third party commercial services into the > official viewer is something that's going to happen any time soon. > > > Over time I plan to track the official viewer, so this isn't intended to > be a fork that goes in a radically different direction. > > > baseline)? the group or team that forks from the original baseline > generally > > assumes the responsiblity for licensing compliance on the forked > project, is > > it your intent to follow up on that as part of the fork? if you are just > > pissed at the installer, then open source yours and submit it to replace > the > > one that resembles the nullsoft installer? > Will OSS the installer, as soon as I get it working properly, which > should be soon. > > For me, a custom installer is a requirement, as I can't ship llkdu.dll. > So mine grabs it from an existing install. > > My understanding is that using OpenJPEG instead should result in a fully > redistributable package, but it still has some bugs. > > _______________________________________________ > 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/20070710/9fb45cf7/attachment-0001.htm From soft at lindenlab.com Tue Jul 10 09:36:54 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 10 09:36:57 2007 Subject: [sldev] SLDev-Traffic #19 - Now featuring prime Message-ID: <9e6e5c9e0707100936t5252e04dlb53c3fe5b7576d71@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_19 SLDev-Traffic number 19 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From able.whitman at gmail.com Tue Jul 10 09:39:11 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 10 09:39:13 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <9e6e5c9e0707100903n2ae215a3p2244454d63510968@mail.gmail.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> <468D4D8B.2010001@lindenlab.com> <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> <9e6e5c9e0707100903n2ae215a3p2244454d63510968@mail.gmail.com> Message-ID: <7b3a84fb0707100939y6d99fe3fh3ab3f1fd7ab38738@mail.gmail.com> Thanks, Soft. I replied to Dale's thread with what information and practices I've been using with my own installer as well. I know LL has no obligation to provide guidance on how to compliantly redistribute custom viewers, but it would be a very nice thing indeed if they did! I'm not asking you or Rob for official guidelines, but I know LL employs some lawyers, so I would like to ask *them* for guidelines. :) --Able On 7/10/07, Soft Linden wrote: > > I don't have hard answers on this myself, and unfortunately Liana, the > key licensing person, is out this week. But you might want to be sure > you're on top of Dale Glass' work on redistribution (another thread). > He's tackling the same problem here, is doing a lot of research on the > library licenses, and has made an installer that attempts to be fully > compliant. > > On 7/5/07, Able Whitman wrote: > > Rob, > > > > I apologize, I haven't been clear enough in asking my questions. I'm not > > asking you, or anyone else, to interpret the licensing agreements for > the > > component libraries for me. Like you said, the licenses are included and > the > > onus is on me to adhere to them. > > > > Assuming that I have taken the responsibility for adhering to all the > > various component licenses, if I also adhere to the guidelines for > > distributing the software itself ( > > http://secondlife.com/corporate/trademark/distribution.php), > > as well as the trademark usage for web and print material > > (http://secondlife.com/corporate/trademark/print_web.php ) > > and the policy for fan sites > > (http://secondlife.com/community/fansites_regs.php), will > > it be permissible for me to distribute an installer for the viewer built > > using the scripts included with the viewer source, or are there other > > guidelines I need to follow as well? > > > > --Able > > > > > > On 7/5/07, Rob Lanphier wrote: > > > Hi Able, > > > > > > I'm not going to be able to get you off the hook for reading and > > > understanding all of the license files in order to redistribute a > > > product based on them. It puts me in dangerous territory to try to > > > paraphrase them. > > > > > > > > > > _______________________________________________ > > 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/20070710/78aa9b50/attachment.htm From james at lindenlab.com Tue Jul 10 09:43:07 2007 From: james at lindenlab.com (James Cook (James)) Date: Tue Jul 10 09:45:25 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? Message-ID: <4693B71B.2020505@lindenlab.com> I tried and failed yesterday to fix "Crash on startup due to SSE instructions": https://jira.secondlife.com/browse/VWR-1610 We mistakenly tested this build on an Athlon Mobile XP 2000+ which supports SSE1. None of our internal developers have a processor this old. Does anyone have an early Athlon (K7 / Thunderbird) that doesn't support SSE who can get me a call stack off the current codebase? I'm reverting the SSE code from 1.18.0 until we can sort this out. We're putting together an old Athlon internally, but it won't be in time for the 1.18 series. James From dale at daleglass.net Tue Jul 10 09:50:42 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 10 09:57:35 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> Message-ID: <20070710165041.GA7685@bruno.sbruno> On Tue, Jul 10, 2007 at 09:08:51AM -0700, Chance Unknown wrote: > since your target is SL, the people most argumentitive about privacy > concerns are the bored lonely housewives that sit at home looking for cyber > affairs. of course they want their identities masked. they dont get that > kind of privay when looking for a hookup at myspace or facebook. How about people who do business? People do things like running servers that talk to say, in-world vendors. If you figure out their IP address, you could cause some major trouble very easily. > > are there any demographics that places these particular consumers in the > primary seat driving development? it has been demonstrated over the past > number of years that the paying customers (private islands) dont tend to > have influence over development, so why should an even smaller cluster of > customers be the ones responsible for driving design goals? It's not that they don't drive development, it's that they CAN'T (or think they can't) drive development. For instance, people told me they requested the "mute visibility" feature *years ago*, and LL said they can't/won't do it. So they gave up on it. Normal people can't "drive development" for things like that, because they have no effective way of forcing LL to do it. Sure they could quit, but who quits over something that's not critical? And even that would almost certainly fail unless done on a very large scale. But, now that we have the source, I'm pretty sure that with time this is going to change, when normal users figure out what it means. I wouldn't be surprised if people started contacting the developers of features they don't like and asking to drop them. And unlike with LL, single developers are small enough that a dedicated group of users could beat them into submission. IMO, private islands aren't entirely the same thing, because they're small, and because I imagine that people selling stuff want to keep their customers happy in the first place. But the day 1% of the 1.7M active users decide that they don't like your stuff... well, I think that will be an interesting one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/9a104a2d/attachment.pgp From able.whitman at gmail.com Tue Jul 10 10:03:08 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 10 10:03:13 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> Message-ID: <7b3a84fb0707101003i65ed1b4cubd8558ede9c09866@mail.gmail.com> On 7/10/07, Chance Unknown wrote: > > since your target is SL, the people most argumentitive about privacy > concerns are the bored lonely housewives that sit at home looking for cyber > affairs. of course they want their identities masked. they dont get that > kind of privay when looking for a hookup at myspace or facebook. > This is a straw man argument, and your conclusion is as presumptuous as it is wrong. There are many reasons someone might want to protect their RL identity. Some of these Argent has already mentioned. SL is also a place where people gather together to discuss politics, or religion, or health, or any number of topics where they may not want their RL identity disclosed. Some people come to SL precisely because they can have a forum to discuss things freely without fear of retribution, where it be from a government, a workplace, a family member, a friend, or even from a stranger. Even if there are no such principled endeavors involved, each user should be able to decide for him or herself whether such identifiable information is revealed. Nobody else should be able to make this decision for them (save, of course, for LL in the case of legal exigencies, through due process). are there any demographics that places these particular consumers in the > primary seat driving development? it has been demonstrated over the past > number of years that the paying customers (private islands) dont tend to > have influence over development, so why should an even smaller cluster of > customers be the ones responsible for driving design goals? > Privacy is a concern of essentially all users, even if they aren't explicitly aware of it. In fact, personal information should be protected by default because most people don't think about it. Just because people aren't clamoring for their information to be protected doesn't mean that it should be shared freely and without their consent. There is no immutable requirement that the SL viewer act in a way to help protect users' personal information, but it should do so anyway. Again, I am not arguing steadfastly against any features which would, by their nature, necessitate disclosure of such information. My position is simply that in cases where users' private information could be disclosed, that the disclosure be disabled by default, that the user be informed and asked for consent, and that such consent be revocable. On 7/10/07, dale@daleglass.net wrote: > > > On Tue, Jul 10, 2007 at 03:08:44AM +0200, Nicholaz Beresford wrote: > > > Ummm, I'm probably missing the point of this discussion completely, > > > but what exactly do you think is this attacker doing with your > > > your IP address? > > DoS, for instance > > > > > I mean what is he doing different from that > > > which about 20+ people per hour aren't trying already through > > > IP scan. > > That on SL you can connect it to a name (even avatar name), and a random > > IP scan doesn't. > > > > Think IRC -- Doing something nasty to another person's computer is > > pretty common there, and people don't pick targets at random. > > > > If Bob is on IRC, and Mallory hates him for some reason, and the IRC > > server makes the IP addresses visible, then Mallory has all the required > > data to attack Bob specifically. > > > > Now, DoS is illegal of course, but it doesn't mean it won't happen, and > > it's a fuzzy concept as well. You can perform a DoS without making it > > really obvious it's an attack. > > > > For instance, there are plenty people with very low upload speeds. If > > you > > find this person runs a webserver or some other service that it's > > possible to download lots of data from, you don't even need to do > > anything particularly malicious. > > > > Just connect to the server, with maybe just 1-3 connections (to avoid > > looking obviously evil), and start downloading. On many connections > > that'll cause plenty lag. > > > > They can take the server down, but if you managed that, that's a DoS > > in itself. > > > > > > IMO, in SL this is even more likely. On IRC it's just name, on SL there > > are multiple well known groups targeted by various morons, who are > > identifiable by the way they look. > > > > And since there even are people trying to bring the grid down, despite > > LL's attempt at prosecution, I doubt legal threats are enough to > > dissuade everybody. > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > _______________________________________________ > 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/20070710/b276b235/attachment-0001.htm From soft at lindenlab.com Tue Jul 10 10:16:28 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 10 10:16:30 2007 Subject: [sldev] Profiling and optimization In-Reply-To: <7992d0d60706230941q6469fa40m220cf4973554d670@mail.gmail.com> References: <672B7BC888DC6DAA8C2205C9@10.14.11.59> <467D46D9.5050207@blueflash.cc> <7992d0d60706230941q6469fa40m220cf4973554d670@mail.gmail.com> Message-ID: <9e6e5c9e0707101016j24461088q36494377e215fb46@mail.gmail.com> Blakar, did you end up going with AMD CodeAnalyst? Do you have any approach to creating a reproducible workload for benchmarking viewer changes? I know optimization's kind of a sexy subject, but it's also easy to misinterpret the tools and focus on the wrong areas without a good profiling approach. It looks like you're off to a good start and maybe trending toward bigger things... can you think of anything you've found so far that could be added to Douglas' profiling guide? https://wiki.secondlife.com/wiki/Profiling_and_Optimization On 6/23/07, Dirk Moerenhout wrote: > I haven't used it as I don't plan to pay for a profiler. I'm recently > downloaded AMD's CodeAnalyst as it's the only free alternative for > windows I know off. It works pretty well but I haven't managed to get > the call stack sampling to work which I'd like to have. > > It does properly show you function names and can do drilldown to code > and such. I did have an issue getting it to work with the ForDownload > pdb but I figured out that compiling only viewer.cpp with /ZI is > enough to have it working again. > > Dirk aka Blakar Ogre > > On 6/23/07, Nicholaz Beresford wrote: > > > > Did anyone try GlowCode on Windows? I ordered > > an Eval and tried it with their demo app, but > > it doesn't seem to show any function calls > > (just a thread list) for any of the SecondLife > > builds (either debug, NoOpt or ForDownload). > > > > > > Nick > > > > > > > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > > > > > Douglas Soo wrote: > > > After watching the chatter fly on this list, I thought that it might be > > > worthwhile to write up a short summary of what we have found at Linden > > > to be effective approaches to profiling and optimizing code. > > > > > > > > > > > > It's pretty thing, but hopefully will be useful. > > > > > > - Doug > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robla at lindenlab.com Tue Jul 10 10:18:14 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 10 10:18:21 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <7b3a84fb0707100939y6d99fe3fh3ab3f1fd7ab38738@mail.gmail.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> <468D4D8B.2010001@lindenlab.com> <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> <9e6e5c9e0707100903n2ae215a3p2244454d63510968@mail.gmail.com> <7b3a84fb0707100939y6d99fe3fh3ab3f1fd7ab38738@mail.gmail.com> Message-ID: <4693BF56.2060104@lindenlab.com> On 7/10/07 9:39 AM, Able Whitman wrote: > Thanks, Soft. I replied to Dale's thread with what information and > practices I've been using with my own installer as well. > > I know LL has no obligation to provide guidance on how to compliantly > redistribute custom viewers, but it would be a very nice thing indeed > if they did! I'm not asking you or Rob for official guidelines, but I > know LL employs some lawyers, so I would like to ask *them* for > guidelines. :) But they're *our* lawyers, and they're kinda busy. :) Seriously, though, if you need legal advice, you need to have a lawyer who represents you. We provide you with all of the licenses you need to make a decision. They say what they say. Legal counsel is very expensive, and as it turns out, our full-time staff is busy enough we'd have to turn this request to outside counsel, which would be very expensive for us. As this program matures, I'm hopeful we'll be able to provide more detailed FAQs, and be in a better position to help you out. However, right now, it's not going to work out that way. I'd also like to request that for every mail you send to sldev about licensing issues, that you send mail to licensing@lindenlab.com. I do not forward this type of mail from sldev to licensing. Sending mail to licensing@lindenlab.com gets your message to the right set of people, without bothering the wrong set of people. If you feel it's necessary to have further public conversation on this topic, please file an issue on jira.secondlife.com, and direct further traffic there. Thanks Rob > On 7/10/07, *Soft Linden* > wrote: > > I don't have hard answers on this myself, and unfortunately Liana, the > key licensing person, is out this week. But you might want to be sure > you're on top of Dale Glass' work on redistribution (another thread). > He's tackling the same problem here, is doing a lot of research on the > library licenses, and has made an installer that attempts to be fully > compliant. > > On 7/5/07, Able Whitman < able.whitman@gmail.com > > wrote: > > Rob, > > > > I apologize, I haven't been clear enough in asking my questions. > I'm not > > asking you, or anyone else, to interpret the licensing > agreements for the > > component libraries for me. Like you said, the licenses are > included and the > > onus is on me to adhere to them. > > > > Assuming that I have taken the responsibility for adhering to > all the > > various component licenses, if I also adhere to the guidelines for > > distributing the software itself ( > > http://secondlife.com/corporate/trademark/distribution.php), > > as well as the trademark usage for web and print material > > (http://secondlife.com/corporate/trademark/print_web.php ) > > and the policy for fan sites > > ( http://secondlife.com/community/fansites_regs.php), will > > it be permissible for me to distribute an installer for the > viewer built > > using the scripts included with the viewer source, or are there > other > > guidelines I need to follow as well? > > > > --Able > > > > > > On 7/5/07, Rob Lanphier > wrote: > > > Hi Able, > > > > > > I'm not going to be able to get you off the hook for reading and > > > understanding all of the license files in order to redistribute a > > > product based on them. It puts me in dangerous territory to > try to > > > paraphrase them. > > > > > > > > > > _______________________________________________ > > 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: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/33c10ea7/signature.pgp From dale at daleglass.net Tue Jul 10 10:18:19 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 10 10:22:48 2007 Subject: [sldev] Working on an installer, anybody figured out licensing yet_ In-Reply-To: <7b3a84fb0707100933m85a7dcer92cf71ae6baf5ad7@mail.gmail.com> References: <20070708234710.GB23822@bruno.sbruno> <2925011a0707092115y89ab6a5n6beef0e4418a1915@mail.gmail.com> <20070710081829.GB11981@bruno.sbruno> <7b3a84fb0707100933m85a7dcer92cf71ae6baf5ad7@mail.gmail.com> Message-ID: <20070710171819.GB7685@bruno.sbruno> On Tue, Jul 10, 2007 at 12:33:06PM -0400, Able Whitman wrote: > Howdy Dale, > > I've been tackling many of the same issues you've been dealing with in > trying to roll a custom, license-compliant installer. > > I reached the same conclusion that you did about the Kakadu library not > being redistributable. IANAL, so I'm not sure if having your installer take > a copy of the DLL from an existing official install could be construed as de > facto redistribution. Aside from Kakadu, all the other OSS-licensed Hmm, I doubt so, as the library isn't changing hands at all. But, to avoid any possible issues here I'll switch to openjpeg here as soon as I can. > In order to try and simplify my custom installer, I built one using NSIS > which simply installs my custom viewer on top of an existing installation of > the official viewer, in such a way that the two can run side-by-side. My > installer requires that the user first install an official copy of the > version of the viewer from which my custom build is derived from. (In my > current case, this means requiring an official 1.17.3.0 install first.) Also NSIS here. Here's how mine works: Installer only carries a list of files. Information includes: Name, MD5 sum of uncompressed file, size, SHA-1 of compressed file, size of compressed file, flags (redistributable or not). Installer scans all present SL installs (firstlook and such included) and if the file it needs has the same MD5, uses that. Otherwise it downloads it, if it's redistributable. The installer verifies that each downloaded file has the right SHA-1 hash, so that even though it downloads files on demand, signing the installer would imply that everything it downloads is effectively signed as well. > 4. Change the name of the crash dump files that are created by my viewer > (handleException in llwindebug.cpp) so as not to overwrite crash dumps from > the official viewer > 5. Change the window class name for my viewer (gWindowName in viewer.cpp) > 6. Change the name of the default settings XML file, so that the official > viewer and my private build use different configs and do not stomp on one > another, similar to First Look viewers (DEFAULT_SETTINGS_FILE in viewer.cpp; > changing the value here has the advantage of not requiring special command > line arguments) > 7. Change the display name of the application (used as the window title, > etc.) to include the phrase "unofficial edition" (gSecondLife, in WinMain, > in viewer.cpp) > 8. Change the executable name to not include the phrase "SecondLife" (I > chose "AbleSL.exe") Makes sense. To add to this: I thought it'd be a good to make my viewer distinctive, so I changed my viewer's menu bar color to 0,128,255. > I'd be happy to provide the NSI script I use and a diff for the source > changes I mentioned, if they would be helpful. diff would be appreciated :-) NSI script probably isn't needed, as I have my own already, which I plan to release as soon as I'm done tweaking stuff. > > --Able -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/2a308a30/attachment.pgp From dzonatas at dzonux.net Tue Jul 10 10:24:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 10 10:24:15 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: <4693B71B.2020505@lindenlab.com> References: <4693B71B.2020505@lindenlab.com> Message-ID: <4693C0C1.2080509@dzonux.net> James, let me know and I'll drive out there to help you set it up and work on it... =) James Cook (James) wrote: > I tried and failed yesterday to fix "Crash on startup due to SSE > instructions": > https://jira.secondlife.com/browse/VWR-1610 > > We mistakenly tested this build on an Athlon Mobile XP 2000+ which > supports SSE1. > > None of our internal developers have a processor this old. Does > anyone have an early Athlon (K7 / Thunderbird) that doesn't support > SSE who can get me a call stack off the current codebase? > > I'm reverting the SSE code from 1.18.0 until we can sort this out. > We're putting together an old Athlon internally, but it won't be in > time for the 1.18 series. > > James > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From robla at lindenlab.com Tue Jul 10 10:30:35 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Jul 10 10:31:15 2007 Subject: [sldev] Please take this thread off list -> ("But your IP wouldn't be safe") In-Reply-To: <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> Message-ID: <4693C23B.6010507@lindenlab.com> Per the (not yet enforced) guidelines of this mailing list: http://wiki.secondlife.com/wiki/SLDev ....please take this thread off list. In particular, there are two entirely suitable homes for this conversation: https://wiki.secondlife.com/wiki/Talk:Web_Textures https://jira.secondlife.com/browse/VWR-217 Also, per the guidelines, replies to my email should also go off list. Here's a great place to discuss these guidelines: https://wiki.secondlife.com/wiki/Talk:SLDev Rob On 7/10/07 9:08 AM, Chance Unknown wrote: > since your target is SL, the people most argumentitive about privacy > concerns are the bored lonely housewives that sit at home looking for > cyber affairs. of course they want their identities masked. they dont > get that kind of privay when looking for a hookup at myspace or facebook. > > are there any demographics that places these particular consumers in > the primary seat driving development? it has been demonstrated over > the past number of years that the paying customers (private islands) > dont tend to have influence over development, so why should an even > smaller cluster of customers be the ones responsible for > driving design goals? > > On 7/10/07, *dale@daleglass.net * > > wrote: > > On Tue, Jul 10, 2007 at 03:08:44AM +0200, Nicholaz Beresford wrote: > > Ummm, I'm probably missing the point of this discussion completely, > > but what exactly do you think is this attacker doing with your > > your IP address? > DoS, for instance > > > I mean what is he doing different from that > > which about 20+ people per hour aren't trying already through > > IP scan. > That on SL you can connect it to a name (even avatar name), and a > random > IP scan doesn't. > > Think IRC -- Doing something nasty to another person's computer is > pretty common there, and people don't pick targets at random. > > If Bob is on IRC, and Mallory hates him for some reason, and the IRC > server makes the IP addresses visible, then Mallory has all the > required > data to attack Bob specifically. > > Now, DoS is illegal of course, but it doesn't mean it won't > happen, and > it's a fuzzy concept as well. You can perform a DoS without making it > really obvious it's an attack. > > For instance, there are plenty people with very low upload speeds. > If you > find this person runs a webserver or some other service that it's > possible to download lots of data from, you don't even need to do > anything particularly malicious. > > Just connect to the server, with maybe just 1-3 connections (to avoid > looking obviously evil), and start downloading. On many connections > that'll cause plenty lag. > > They can take the server down, but if you managed that, that's a DoS > in itself. > > > IMO, in SL this is even more likely. On IRC it's just name, on SL > there > are multiple well known groups targeted by various morons, who are > identifiable by the way they look. > > And since there even are people trying to bring the grid down, despite > LL's attempt at prosecution, I doubt legal threats are enough to > dissuade everybody. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/fe51f755/signature.pgp From able.whitman at gmail.com Tue Jul 10 10:32:38 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 10 10:32:42 2007 Subject: [sldev] Working on an installer, anybody figured out licensing yet_ In-Reply-To: <20070710171819.GB7685@bruno.sbruno> References: <20070708234710.GB23822@bruno.sbruno> <2925011a0707092115y89ab6a5n6beef0e4418a1915@mail.gmail.com> <20070710081829.GB11981@bruno.sbruno> <7b3a84fb0707100933m85a7dcer92cf71ae6baf5ad7@mail.gmail.com> <20070710171819.GB7685@bruno.sbruno> Message-ID: <7b3a84fb0707101032w65298825yb991266a3f313c27@mail.gmail.com> It sounds like you're going after a rather more sophisticated approach, which sounds a lot more robust than my "install and hope" method :) Changing the menubar color is an excellent idea. I'll send you a diff of my changes as well. On 7/10/07, Dale Glass wrote: > > On Tue, Jul 10, 2007 at 12:33:06PM -0400, Able Whitman wrote: > > Howdy Dale, > > > > I've been tackling many of the same issues you've been dealing with in > > trying to roll a custom, license-compliant installer. > > > > I reached the same conclusion that you did about the Kakadu library not > > being redistributable. IANAL, so I'm not sure if having your installer > take > > a copy of the DLL from an existing official install could be construed > as de > > facto redistribution. Aside from Kakadu, all the other OSS-licensed > Hmm, I doubt so, as the library isn't changing hands at all. > > But, to avoid any possible issues here I'll switch to openjpeg here as > soon as I can. > > > > In order to try and simplify my custom installer, I built one using NSIS > > which simply installs my custom viewer on top of an existing > installation of > > the official viewer, in such a way that the two can run side-by-side. My > > installer requires that the user first install an official copy of the > > version of the viewer from which my custom build is derived from. (In my > > current case, this means requiring an official 1.17.3.0 install first.) > Also NSIS here. Here's how mine works: > > Installer only carries a list of files. Information includes: > Name, MD5 sum of uncompressed file, size, SHA-1 of compressed file, size > of compressed file, flags (redistributable or not). > > Installer scans all present SL installs (firstlook and such included) > and if the file it needs has the same MD5, uses that. Otherwise it > downloads it, if it's redistributable. > > The installer verifies that each downloaded file has the right SHA-1 > hash, so that even though it downloads files on demand, signing the > installer would imply that everything it downloads is effectively signed > as well. > > > > 4. Change the name of the crash dump files that are created by my viewer > > (handleException in llwindebug.cpp) so as not to overwrite crash dumps > from > > the official viewer > > 5. Change the window class name for my viewer (gWindowName in viewer.cpp > ) > > 6. Change the name of the default settings XML file, so that the > official > > viewer and my private build use different configs and do not stomp on > one > > another, similar to First Look viewers (DEFAULT_SETTINGS_FILE in > viewer.cpp; > > changing the value here has the advantage of not requiring special > command > > line arguments) > > 7. Change the display name of the application (used as the window title, > > etc.) to include the phrase "unofficial edition" (gSecondLife, in > WinMain, > > in viewer.cpp) > > 8. Change the executable name to not include the phrase "SecondLife" (I > > chose "AbleSL.exe") > Makes sense. > > To add to this: I thought it'd be a good to make my viewer distinctive, > so I changed my viewer's menu bar color to 0,128,255. > > > > I'd be happy to provide the NSI script I use and a diff for the source > > changes I mentioned, if they would be helpful. > diff would be appreciated :-) > > NSI script probably isn't needed, as I have my own already, which I plan > to release as soon as I'm done tweaking stuff. > > > > > > --Able > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/ffef3f47/attachment-0001.htm From blakar at gmail.com Tue Jul 10 10:33:26 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jul 10 10:33:34 2007 Subject: [sldev] Profiling and optimization In-Reply-To: <9e6e5c9e0707101016j24461088q36494377e215fb46@mail.gmail.com> References: <672B7BC888DC6DAA8C2205C9@10.14.11.59> <467D46D9.5050207@blueflash.cc> <7992d0d60706230941q6469fa40m220cf4973554d670@mail.gmail.com> <9e6e5c9e0707101016j24461088q36494377e215fb46@mail.gmail.com> Message-ID: <7992d0d60707101033l5ccca662sb7d6a3f966235a1@mail.gmail.com> For now I use rather basic scenarios where I render a specific scene to see how different environments impact performance. This is off course perfectly reproducable by logging in and out at the same spot. The beta grid is ideal as there's really noone there. The tough part will come when I try to have a go at profiling complex scenarios where there are many avatars in view. This is never perfectly reproducable. Upto now most of the optimisations I've tested were easy because by looking at the assembly alone it were clear winners (for example preparing to call addTextureStats used to be about as complex as the inlined code is by itself). What is very important is that people must never forget that they need to profile the most suitable executable. The debug info needs to be present but besides that you need all the optimisations you get in a real build. If you don't do that you end up seeing hotspots that are auto-eliminated by the compiler. Also important is to make sure you're running clean. Don't leave browser windows open cause while running the viewer you may end up seeing drops in fps because something else is chewing your cycles. I had it once when I forgot to close a page that was using flash. You also need to keep the focus on the viewer window so that it tries to perform at its best. Personally it feels like I've only just begun so my tips are limited for now. I'll come up with more as I proceed. Most important thing for that page would be to rewrite it in third person so it's easier to contribute to it :) Dirk aka Blakar Ogre On 7/10/07, Soft Linden wrote: > Blakar, did you end up going with AMD CodeAnalyst? Do you have any > approach to creating a reproducible workload for benchmarking viewer > changes? > > I know optimization's kind of a sexy subject, but it's also easy to > misinterpret the tools and focus on the wrong areas without a good > profiling approach. It looks like you're off to a good start and maybe > trending toward bigger things... can you think of anything you've > found so far that could be added to Douglas' profiling guide? > > https://wiki.secondlife.com/wiki/Profiling_and_Optimization > > > On 6/23/07, Dirk Moerenhout wrote: > > I haven't used it as I don't plan to pay for a profiler. I'm recently > > downloaded AMD's CodeAnalyst as it's the only free alternative for > > windows I know off. It works pretty well but I haven't managed to get > > the call stack sampling to work which I'd like to have. > > > > It does properly show you function names and can do drilldown to code > > and such. I did have an issue getting it to work with the ForDownload > > pdb but I figured out that compiling only viewer.cpp with /ZI is > > enough to have it working again. > > > > Dirk aka Blakar Ogre > > > > On 6/23/07, Nicholaz Beresford wrote: > > > > > > Did anyone try GlowCode on Windows? I ordered > > > an Eval and tried it with their demo app, but > > > it doesn't seem to show any function calls > > > (just a thread list) for any of the SecondLife > > > builds (either debug, NoOpt or ForDownload). > > > > > > > > > Nick > > > > > > > > > > > > Second Life from the inside out: > > > http://nicholaz-beresford.blogspot.com/ > > > > > > > > > Douglas Soo wrote: > > > > After watching the chatter fly on this list, I thought that it might be > > > > worthwhile to write up a short summary of what we have found at Linden > > > > to be effective approaches to profiling and optimizing code. > > > > > > > > > > > > > > > > It's pretty thing, but hopefully will be useful. > > > > > > > > - Doug > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From bos at lindenlab.com Tue Jul 10 10:47:35 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jul 10 10:48:12 2007 Subject: [sldev] 1.17.3 Source now available In-Reply-To: <1184044421.5428.7.camel@localhost> References: <468EE29F.3090203@lindenlab.com> <1184044421.5428.7.camel@localhost> Message-ID: <4693C637.5090203@lindenlab.com> Callum Lerwick wrote: > https://jira.secondlife.com/browse/VWR-1598 > > Its an API that the glibc people really don't want anyone to use, it > seems. I've not been able to figure out why that is. I don't know of any other public API to do things like SRV record lookups and parsing, and I sure don't want to have to roll that kind of code by hand. References: <4693B71B.2020505@lindenlab.com> <4693C0C1.2080509@dzonux.net> Message-ID: Not sure what I all I can do with the system I tested with last night. (Athalon XP 1500+, No SSE/SSE2) It's not exactly the beefiest machine but I'll see what I can do. I'm off RL work for vacation starting this weekend.. so I'll definately have some time to mess with it then. On 7/10/07, Dzonatas wrote: > James, let me know and I'll drive out there to help you set it up and > work on it... =) > > James Cook (James) wrote: > > I tried and failed yesterday to fix "Crash on startup due to SSE > > instructions": > > https://jira.secondlife.com/browse/VWR-1610 > > > > We mistakenly tested this build on an Athlon Mobile XP 2000+ which > > supports SSE1. > > > > None of our internal developers have a processor this old. Does > > anyone have an early Athlon (K7 / Thunderbird) that doesn't support > > SSE who can get me a call stack off the current codebase? > > > > I'm reverting the SSE code from 1.18.0 until we can sort this out. > > We're putting together an old Athlon internally, but it won't be in > > time for the 1.18 series. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/3c8ae659/attachment.htm From dale at daleglass.net Tue Jul 10 10:57:28 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 10 11:10:35 2007 Subject: [sldev] Rolling a custom viewer installer? In-Reply-To: <4693BF56.2060104@lindenlab.com> References: <7b3a84fb0707020107i112a8685hc8b376474ce6521@mail.gmail.com> <9e6e5c9e0707022038p51a73d7fm69035c8e96cfb59@mail.gmail.com> <7b3a84fb0707022138j223156a3ube6f51baee771cc0@mail.gmail.com> <468D4D8B.2010001@lindenlab.com> <7b3a84fb0707051346h5ae7c30vbf1e50dc119114a@mail.gmail.com> <9e6e5c9e0707100903n2ae215a3p2244454d63510968@mail.gmail.com> <7b3a84fb0707100939y6d99fe3fh3ab3f1fd7ab38738@mail.gmail.com> <4693BF56.2060104@lindenlab.com> Message-ID: <20070710175728.GC7685@bruno.sbruno> On Tue, Jul 10, 2007 at 10:18:14AM -0700, Rob Lanphier wrote: > But they're *our* lawyers, and they're kinda busy. :) > > Seriously, though, if you need legal advice, you need to have a lawyer > who represents you. We provide you with all of the licenses you need to > make a decision. They say what they say. Legal counsel is very > expensive, and as it turns out, our full-time staff is busy enough we'd > have to turn this request to outside counsel, which would be very > expensive for us. Well, for general legal advice, of course a lawyer would be needed. I understand that LL legal isn't going to answer questions about say, the licensing terms of Kakadu, but I don't see how anybody but LL can answer things like what should I do with my own version of the viewer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/8da94c45/attachment.pgp From dzonatas at dzonux.net Tue Jul 10 12:14:29 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 10 12:14:27 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: References: <4693B71B.2020505@lindenlab.com> <4693C0C1.2080509@dzonux.net> Message-ID: <4693DA95.9070509@dzonux.net> I got a hold of a 586tsc, which appears very similar to the older Thunderbird 800mhz. Eh... it has linux preinstalled... i'll see what i can do Harold Brown wrote: > Not sure what I all I can do with the system I tested with last night. > (Athalon XP 1500+, No SSE/SSE2) > > It's not exactly the beefiest machine but I'll see what I can do. I'm > off RL work for vacation starting this weekend.. so I'll definately > have some time to mess with it then. > > On 7/10/07, *Dzonatas* > wrote: > > James, let me know and I'll drive out there to help you set it up and > work on it... =) > > James Cook (James) wrote: > > I tried and failed yesterday to fix "Crash on startup due to SSE > > instructions": > > https://jira.secondlife.com/browse/VWR-1610 > > > > We mistakenly tested this build on an Athlon Mobile XP 2000+ which > > supports SSE1. > > > > None of our internal developers have a processor this old. Does > > anyone have an early Athlon (K7 / Thunderbird) that doesn't support > > SSE who can get me a call stack off the current codebase? > > > > I'm reverting the SSE code from 1.18.0 until we can sort this out. > > We're putting together an old Athlon internally, but it won't be in > > time for the 1.18 series. > > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/13f8ed5b/attachment.htm From dzonatas at dzonux.net Tue Jul 10 12:41:42 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 10 12:41:40 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: <4693DA95.9070509@dzonux.net> References: <4693B71B.2020505@lindenlab.com> <4693C0C1.2080509@dzonux.net> <4693DA95.9070509@dzonux.net> Message-ID: <4693E0F6.1040102@dzonux.net> The immediate test on the 586tsc shows it working -- starts up. The 586tsc does not have SSE but does have MMX. The only thing apparently different with the K7 would be the 3DNow! features. Dzonatas wrote: > I got a hold of a 586tsc, which appears very similar to the older > Thunderbird 800mhz. Eh... it has linux preinstalled... i'll see what > i can do > > Harold Brown wrote: >> Not sure what I all I can do with the system I tested with last >> night. (Athalon XP 1500+, No SSE/SSE2) >> >> It's not exactly the beefiest machine but I'll see what I can do. >> I'm off RL work for vacation starting this weekend.. so I'll >> definately have some time to mess with it then. >> >> On 7/10/07, *Dzonatas* > > wrote: >> >> James, let me know and I'll drive out there to help you set it up and >> work on it... =) >> >> James Cook (James) wrote: >> > I tried and failed yesterday to fix "Crash on startup due to SSE >> > instructions": >> > https://jira.secondlife.com/browse/VWR-1610 >> > >> > We mistakenly tested this build on an Athlon Mobile XP 2000+ which >> > supports SSE1. >> > >> > None of our internal developers have a processor this old. Does >> > anyone have an early Athlon (K7 / Thunderbird) that doesn't >> support >> > SSE who can get me a call stack off the current codebase? >> > >> > I'm reverting the SSE code from 1.18.0 until we can sort this out. >> > We're putting together an old Athlon internally, but it won't >> be in >> > time for the 1.18 series. >> > >> > > -- > Power to Change the Void > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/2df7e7c3/attachment.htm From phoenix at secondlife.com Tue Jul 10 12:49:09 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Jul 10 12:49:51 2007 Subject: [sldev] Where we are headed in IPC development Message-ID: Though the movement in the back-end and web services front-end is not as visible or potentially as interesting to the current subscribers of this list, we have been diligently working on making inter-process communication work more reliably, and robustly. We have begun development on a new model for handling processes like giving L$, purchasing object inventory, and transferring land. The first basic building block is how we plan to communicate this information when several different hosts have to agree to the final state, which I present now in a new proposal we have been calling Certified HTTP: https://wiki.secondlife.com/wiki/Reliable_Message_Delivery_Over_HTTP Why I thought I would present this here is that we are planning on making our implementation for chttp open source pretty much as soon as we can. It doesn't work yet and we have to clear a few hurdles internally before it can be released, but I wanted to give interested parties a preview of what we're doing. -------------- 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/20070710/b1f545cf/PGP.pgp From dale at daleglass.net Tue Jul 10 13:07:26 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 10 13:07:32 2007 Subject: [sldev] Where we are headed in IPC development In-Reply-To: References: Message-ID: <20070710200726.GD7685@bruno.sbruno> On Tue, Jul 10, 2007 at 12:49:09PM -0700, Phoenix wrote: > Though the movement in the back-end and web services front-end is not > as visible or potentially as interesting to the current subscribers > of this list, we have been diligently working on making inter-process > communication work more reliably, and robustly. > > We have begun development on a new model for handling processes like > giving L$, purchasing object inventory, and transferring land. The > first basic building block is how we plan to communicate this > information when several different hosts have to agree to the final > state, which I present now in a new proposal we have been calling > Certified HTTP: Very interesting! Would this extend to LSL? It would be really nice to be able to have a confirmation for money transfers and inventory deliveries. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/6cbbcd88/attachment.pgp From kamilion at gmail.com Tue Jul 10 14:28:45 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Jul 10 14:28:47 2007 Subject: [sldev] Where we are headed in IPC development In-Reply-To: References: Message-ID: Very cool! I especially like the client's delivery confirmation response to the server; running a DELETE on the X-Message-URL to confirm receipt... Very ingenious. Best of luck! -- Kamilion On 7/10/07, Phoenix wrote: > Though the movement in the back-end and web services front-end is not > as visible or potentially as interesting to the current subscribers > of this list, we have been diligently working on making inter-process > communication work more reliably, and robustly. > > We have begun development on a new model for handling processes like > giving L$, purchasing object inventory, and transferring land. The > first basic building block is how we plan to communicate this > information when several different hosts have to agree to the final > state, which I present now in a new proposal we have been calling > Certified HTTP: > > https://wiki.secondlife.com/wiki/Reliable_Message_Delivery_Over_HTTP > > Why I thought I would present this here is that we are planning on > making our implementation for chttp open source pretty much as soon > as we can. It doesn't work yet and we have to clear a few hurdles > internally before it can be released, but I wanted to give interested > parties a preview of what we're doing. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From zortiger at gmail.com Tue Jul 10 15:06:17 2007 From: zortiger at gmail.com (Erik Hill) Date: Tue Jul 10 15:06:20 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <7b3a84fb0707101003i65ed1b4cubd8558ede9c09866@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> <7b3a84fb0707101003i65ed1b4cubd8558ede9c09866@mail.gmail.com> Message-ID: <7c61ce730707101506g36e03b6dtf4ac1c332233f220@mail.gmail.com> If privacy concerns are all that big, yet it still be a major benfit/advancement, why dont you do something down the middle. For html on a prim, or web images on prims, it would be an idea to limit use to 'varifyed/certified' content providers. Require a signature on non-disclosure agreement, proof of identity for LL's records, and perhaps locking to domains they can prove ownership of. Such would not necessarily get rid of the risks, but It would cause most to think twice about collecting such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/efdd94f9/attachment.htm From matthew.dowd at hotmail.co.uk Tue Jul 10 15:09:00 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jul 10 15:09:02 2007 Subject: [sldev] Another small UI patch (opening a partners profile from an avatar's profile) Message-ID: More or less as per subject. It has alway bugged me that although you can see the name of a partner in an avatar's profile, you can't actually see the partners profile without typing (or copy/pasting) their name into search. The patch adds a small button into the profile panel above the text box for the partner which opens a new window displaying the partners profile (if a partner exists). https://jira.secondlife.com/browse/VWR-1651 Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From blakar at gmail.com Tue Jul 10 15:17:30 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jul 10 15:17:33 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: <4693E0F6.1040102@dzonux.net> References: <4693B71B.2020505@lindenlab.com> <4693C0C1.2080509@dzonux.net> <4693DA95.9070509@dzonux.net> <4693E0F6.1040102@dzonux.net> Message-ID: <7992d0d60707101517m1ba6539o8a487b4719bf6b1@mail.gmail.com> Which binary did you test? Given this is more a compiler issue than a code issue I doubt it'll crash if you were using anything but an MSVC compiled binary. And even then it might be compiler version dependent. Dirk aka Blakar Ogre On 7/10/07, Dzonatas wrote: > > The immediate test on the 586tsc shows it working -- starts up. The 586tsc > does not have SSE but does have MMX. The only thing apparently different > with the K7 would be the 3DNow! features. > > Dzonatas wrote: > I got a hold of a 586tsc, which appears very similar to the older > Thunderbird 800mhz. Eh... it has linux preinstalled... i'll see what i can > do > > Harold Brown wrote: > > Not sure what I all I can do with the system I tested with last night. > (Athalon XP 1500+, No SSE/SSE2) > > It's not exactly the beefiest machine but I'll see what I can do. I'm off > RL work for vacation starting this weekend.. so I'll definately have some > time to mess with it then. > > On 7/10/07, Dzonatas wrote: > > > James, let me know and I'll drive out there to help you set it up and > > work on it... =) > > > > James Cook (James) wrote: > > > I tried and failed yesterday to fix "Crash on startup due to SSE > > > instructions": > > > https://jira.secondlife.com/browse/VWR-1610 > > > > > > We mistakenly tested this build on an Athlon Mobile XP 2000+ which > > > supports SSE1. > > > > > > None of our internal developers have a processor this old. Does > > > anyone have an early Athlon (K7 / Thunderbird) that doesn't support > > > SSE who can get me a call stack off the current codebase? > > > > > > I'm reverting the SSE code from 1.18.0 until we can sort this out. > > > We're putting together an old Athlon internally, but it won't be in > > > time for the 1.18 series. > > > > > > -- > Power to Change the Void ________________________________ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From phoenix at secondlife.com Tue Jul 10 15:18:02 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Jul 10 15:18:15 2007 Subject: [sldev] Where we are headed in IPC development In-Reply-To: <20070710200726.GD7685@bruno.sbruno> References: <20070710200726.GD7685@bruno.sbruno> Message-ID: On 2007/07/10, at 13:07, Dale Glass wrote: > On Tue, Jul 10, 2007 at 12:49:09PM -0700, Phoenix wrote: >> We have begun development on a new model for handling processes like >> giving L$, purchasing object inventory, and transferring land. The >> first basic building block is how we plan to communicate this >> information when several different hosts have to agree to the final >> state, which I present now in a new proposal we have been calling >> Certified HTTP: > > Very interesting! > > Would this extend to LSL? It would be really nice to be able to have a > confirmation for money transfers and inventory deliveries. Not for the next few months, but this will eventually be extended into an escrow service with an lsl interface which is visibly distinct on the viewer from the current 'please pay me and I promise to give you some stuff.' -------------- 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/20070710/f2ea03a7/PGP.pgp From seg at haxxed.com Tue Jul 10 15:21:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jul 10 15:21:08 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: <4693B71B.2020505@lindenlab.com> References: <4693B71B.2020505@lindenlab.com> Message-ID: <1184106113.26509.15.camel@localhost> On Tue, 2007-07-10 at 09:43 -0700, James Cook (James) wrote: > I tried and failed yesterday to fix "Crash on startup due to SSE > instructions": > https://jira.secondlife.com/browse/VWR-1610 > > We mistakenly tested this build on an Athlon Mobile XP 2000+ which > supports SSE1. > > None of our internal developers have a processor this old. Does anyone > have an early Athlon (K7 / Thunderbird) that doesn't support SSE who can > get me a call stack off the current codebase? I apparently have an oddball one. Its in a green OPGA package, and marked as a 1700+, but it is not an XP it seems to be a Thunderbird. No SSE. I can find no references online to any T-birds being made in XP packaging. Anyway, 1.17.3.0 does in fact fail to run on it. I'll put the details on Jira. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070710/1d29ca07/attachment.pgp From secret.argent at gmail.com Tue Jul 10 15:26:40 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 10 15:26:31 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> References: <20070707025157.5F85B41AFE8@stupor.lindenlab.com> <8658DB64-6BB9-4998-83CC-C085735555C8@gmail.com> <2925011a0707092130p51de0706o6c00e0c1eff4759e@mail.gmail.com> Message-ID: On 09-Jul-2007, at 23:30, Chance Unknown wrote: > i got your IP the minute you visited my hosted website. so your > issue with "privacy" is what? The difference is that I visited... that is, I made a specific and conscious decision to visit, your website. That's exactly the *current* situation in SL. If Alice visits Mallory's parcel (website), and doesn't do anything to hide (like turning off streaming audio), then Mallory can get Alice's address. The situation with web textures would be that Mallory could get Alice's IP address even if Alice never visited any of Mallory's "websites", and even if none of the people whose "websites" she does visit is in collusion with Mallory. This would be like an Internet where I could put "web bugs" on microsoft.com and Microsoft could do nothing about it. From secret.argent at gmail.com Tue Jul 10 15:31:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 10 15:31:10 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <20070710163659.34bf5235.cyeoh@ozlabs.org> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <20070710163659.34bf5235.cyeoh@ozlabs.org> Message-ID: <9CEDF458-AF00-4AF4-A3DD-ED7C58274933@gmail.com> On 10-Jul-2007, at 01:36, Christopher Yeoh wrote: > If the protocol used to retrieve the textures is a widely supported > one (eg http), then the SL client could support a proxy server > setting for retreival of the textures. This way those concerned > about their RL identity leaking could use web anonymisers like they > already might do for web browsing. I have been trying to get LL to provide proxy support in SL for over two years now. From secret.argent at gmail.com Tue Jul 10 15:37:48 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 10 15:37:37 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <46935494.7070007@gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <46935494.7070007@gmail.com> Message-ID: <408A492A-30A8-4321-A10E-598287179D27@gmail.com> On 10-Jul-2007, at 04:42, Jason Giglio wrote: > An excellent example of a large, successful, platform, where they > don't even attempt to obscure IPs from other users. I bet some of > their users even cry about it too. Not any more. Rampant abuse by bots and DOS attacks on IRC have led to IRC fragmenting into hundreds of isolated networks, some of which have no more than three or four systems on them, and a massive exodus of people from IRC to chat systems that provide more privacy and security. Pointing to IRC as an environment where a laissez-faire approach to privacy was a "success" just means you're not really familiar with the history of IRC. From bos at lindenlab.com Tue Jul 10 15:41:35 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jul 10 15:41:38 2007 Subject: [sldev] Another small UI patch (opening a partners profile from an avatar's profile) In-Reply-To: References: Message-ID: <46940B1F.70204@lindenlab.com> Matthew Dowd wrote: > The patch adds a small button into the profile panel above the text box for the partner which opens a new window displaying the partners profile (if a partner exists). Nice idea. I'd encourage you to submit it as a JIRA task and attach the patch, as that way it won't fall through the cracks. References: <20070710163310.34CC841B044@stupor.lindenlab.com> Message-ID: <1E127F91-BF40-49F8-B36B-C62C5A431F2B@gmail.com> From: "Chance Unknown" > since your target is SL, the people most argumentitive about privacy > concerns are the bored lonely housewives that sit at home looking > for cyber > affairs. of course they want their identities masked. they dont get > that > kind of privay when looking for a hookup at myspace or facebook. If we can carry on this discussion without demonizing or belittling people (people who are, furthermore, not present to defend themselves) I believe it will be more productive. From secret.argent at gmail.com Tue Jul 10 15:51:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 10 15:51:40 2007 Subject: [sldev] Re: Please take this thread off list In-Reply-To: <20070710173242.C9F2F41B02B@stupor.lindenlab.com> References: <20070710173242.C9F2F41B02B@stupor.lindenlab.com> Message-ID: Sorry for the last few messages. I read this in digest and I've been doing real work (well, paid work) all day... so I haven't been in- world or following the lists in real time. From secret.argent at gmail.com Tue Jul 10 16:14:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 10 16:14:14 2007 Subject: [sldev] Re: Where we are headed in IPC development (Phoenix) In-Reply-To: <20070710220902.C421441AF1B@stupor.lindenlab.com> References: <20070710220902.C421441AF1B@stupor.lindenlab.com> Message-ID: <43E402EF-9AF4-46B3-B783-2C4ED63F4894@gmail.com> Looks like it's got a lot in common with Usenet, with duplicated message IDs receiving identical responses rather than being dropped. I'm not sure about the requirement that the URL and response be opaque, do you simply mean that chttp must not modify them? That's what the implementation would seem to imply. From rdw at lindenlab.com Tue Jul 10 16:29:09 2007 From: rdw at lindenlab.com (Which Linden) Date: Tue Jul 10 16:30:01 2007 Subject: [sldev] Re: Where we are headed in IPC development (Phoenix) In-Reply-To: <43E402EF-9AF4-46B3-B783-2C4ED63F4894@gmail.com> References: <20070710220902.C421441AF1B@stupor.lindenlab.com> <43E402EF-9AF4-46B3-B783-2C4ED63F4894@gmail.com> Message-ID: <46941645.8080509@lindenlab.com> Argent Stonecutter wrote: > Looks like it's got a lot in common with Usenet, with duplicated message > IDs receiving identical responses rather than being dropped. I'm not > sure about the requirement that the URL and response be opaque, do you > simply mean that chttp must not modify them? That's what the > implementation would seem to imply. Yeah, it also means that chttp can't depend on any special structure in the urls themselves (e.g. assuming that the url contains "?message_id=ABC" and parsing the ID out). -RYaN From dzonatas at dzonux.net Tue Jul 10 17:19:25 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 10 17:19:23 2007 Subject: [sldev] Re: Where we are headed in IPC development (Phoenix) In-Reply-To: <43E402EF-9AF4-46B3-B783-2C4ED63F4894@gmail.com> References: <20070710220902.C421441AF1B@stupor.lindenlab.com> <43E402EF-9AF4-46B3-B783-2C4ED63F4894@gmail.com> Message-ID: <4694220D.6080500@dzonux.net> Argent Stonecutter wrote: > Looks like it's got a lot in common with Usenet, with duplicated > message IDs receiving identical responses rather than being dropped. > I'm not sure about the requirement that the URL and response be > opaque, do you simply mean that chttp must not modify them? That's > what the implementation would seem to imply. Hey now, the IHAVE/SENDME protocol of USENET was one of the best eras to get a distribution across the world before such concepts as an always-on Internet connection. As for what I have considered of CHTTP, I second the motion for the wider proof-of-concept phase! -- Power to Change the Void From dzonatas at dzonux.net Tue Jul 10 17:58:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 10 17:58:17 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: <7992d0d60707101517m1ba6539o8a487b4719bf6b1@mail.gmail.com> References: <4693B71B.2020505@lindenlab.com> <4693C0C1.2080509@dzonux.net> <4693DA95.9070509@dzonux.net> <4693E0F6.1040102@dzonux.net> <7992d0d60707101517m1ba6539o8a487b4719bf6b1@mail.gmail.com> Message-ID: <46942B2C.9020000@dzonux.net> I have just borrowed more hardware to further test this issue. The exact result will not be release, however. That is due to an equivocal agreement with Zero Linden made in the office hours under the envelope of Quality Assurance and the Residents. We might see some progress for LL to extend the "team" effort of required by QA to *actually* involve all developers that have worked on Second Life. I'm going to put a higher priority on the issue to get the auto-initialized global C++ classes moved over to be manually initialized. For one, it is obviously impossible to fully QA such classes with them being auto-initialized in a chaotic order. There are just dozens of classes that could potentially output very useful log information, but such classes can't until the log class is initialized and opens the log file, which currently happens after the auto-initialized classes! You know I have involuntarily wasted time to trace auto-initialized C++ classes when it could have been done much much easier! Dirk Moerenhout wrote: > Which binary did you test? Given this is more a compiler issue than a > code issue I doubt it'll crash if you were using anything but an MSVC > compiled binary. And even then it might be compiler version dependent. > > Dirk aka Blakar Ogre > > On 7/10/07, Dzonatas wrote: >> >> The immediate test on the 586tsc shows it working -- starts up. The >> 586tsc >> does not have SSE but does have MMX. The only thing apparently different >> with the K7 would be the 3DNow! features. >> >> Dzonatas wrote: >> I got a hold of a 586tsc, which appears very similar to the older >> Thunderbird 800mhz. Eh... it has linux preinstalled... i'll see what >> i can >> do >> >> Harold Brown wrote: >> >> Not sure what I all I can do with the system I tested with last night. >> (Athalon XP 1500+, No SSE/SSE2) >> >> It's not exactly the beefiest machine but I'll see what I can do. >> I'm off >> RL work for vacation starting this weekend.. so I'll definately have >> some >> time to mess with it then. >> >> On 7/10/07, Dzonatas wrote: >> >> > James, let me know and I'll drive out there to help you set it up and >> > work on it... =) >> > >> > James Cook (James) wrote: >> > > I tried and failed yesterday to fix "Crash on startup due to SSE >> > > instructions": >> > > https://jira.secondlife.com/browse/VWR-1610 >> > > >> > > We mistakenly tested this build on an Athlon Mobile XP 2000+ which >> > > supports SSE1. >> > > >> > > None of our internal developers have a processor this old. Does >> > > anyone have an early Athlon (K7 / Thunderbird) that doesn't support >> > > SSE who can get me a call stack off the current codebase? >> > > >> > > I'm reverting the SSE code from 1.18.0 until we can sort this out. >> > > We're putting together an old Athlon internally, but it won't be in >> > > time for the 1.18 series. >> > > >> >> >> -- >> Power to Change the Void ________________________________ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > -- Power to Change the Void From gigstaggart at gmail.com Tue Jul 10 18:15:11 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 10 18:15:33 2007 Subject: [sldev] Privacy vs Anonymity. In-Reply-To: <7b3a84fb0707101003i65ed1b4cubd8558ede9c09866@mail.gmail.com> References: <20070707140025.E44AF41AFDF@stupor.lindenlab.com> <4692D04E.2060806@gmail.com> <4692DC1C.9060108@blueflash.cc> <20070710093102.GA32710@bruno.sbruno> <2925011a0707100908j35d67b36nc605fab11e87dcf4@mail.gmail.com> <7b3a84fb0707101003i65ed1b4cubd8558ede9c09866@mail.gmail.com> Message-ID: <46942F1F.5010700@gmail.com> Able Whitman wrote: > Privacy is a concern of essentially all users, even if they aren't > explicitly aware of it. In fact, personal information should be Privacy and anonymity are two different things. The latter is not necessary for the former. Your home is private, but there is nothing anonymous about it. It has a sign on the front lawn, specifying its address. Just like your computer. Anyone you send mail to can get this address, for good reason, no one could reply without it. To extend the analogy, what you are asking is that the post office deliver mail using an internal GPS tracking system so that everyone can take the address markers off their house. The post office can do this, but it has drawbacks, such as when you need to give someone directions to your house (Direct client connections). *What you all are advocating is that the post office turn into a private taxi service, a freight delivery service, and a pizza delivery service, so that no one ever needs to know any else's address. The post office could do this, and protect your address, but it is not their job to deliver pizza and freight and people to your address, just to protect your anonymity. They would do a poor job at it, anyway. This is exactly the situation you are advocating putting Linden Lab in.* There are plenty of things we can do to add *real* privacy into Second Life, without crippling the platform by having some silly goal of "protect IP addresses". Anonymity, in any case, has some serious drawbacks that privacy doesn't. It makes fraud easier. It makes griefing easier. A griefer doesn't need to worry about being banned right now, because it's by avatar name, not anything that matters and is a little harder to change like IP address or IP address block. Fraud is a *huge* issue right now too. These fraudsters don't care, because no one gets their IP except Linden Lab, and Linden Lab apparently won't do anything in many cases, unless Linden Lab is the one losing money from their fraud operation. When you advocate this anonymity, you are giving your blessing to grifers, to fraudsters, to every undesirable element that wants to hide their identity to prevent being held accountable for their actions. -Jason From gigstaggart at gmail.com Tue Jul 10 18:23:51 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 10 18:24:13 2007 Subject: [sldev] Call stack for crash on startup in SSE code on early Athlon processors? In-Reply-To: <46942B2C.9020000@dzonux.net> References: <4693B71B.2020505@lindenlab.com> <4693C0C1.2080509@dzonux.net> <4693DA95.9070509@dzonux.net> <4693E0F6.1040102@dzonux.net> <7992d0d60707101517m1ba6539o8a487b4719bf6b1@mail.gmail.com> <46942B2C.9020000@dzonux.net> Message-ID: <46943127.5080006@gmail.com> Dzonatas wrote: > I'm going to put a higher priority on the issue to get the > auto-initialized global C++ classes moved over to be manually > initialized. For one, it is obviously impossible to fully QA such I agree. The startup order right now is unpredictable and that creates a lot of trouble. I've run into this personally before. -Jason From chance at kalacia.com Tue Jul 10 18:33:59 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jul 10 18:34:01 2007 Subject: [sldev] Re: "But your IP wouldn't be safe" In-Reply-To: <1E127F91-BF40-49F8-B36B-C62C5A431F2B@gmail.com> References: <20070710163310.34CC841B044@stupor.lindenlab.com> <1E127F91-BF40-49F8-B36B-C62C5A431F2B@gmail.com> Message-ID: <2925011a0707101833o2f39c430ue66c2bf142596c5e@mail.gmail.com> take it off list per request of rob linden. it has gotten to the point of the ridiculous if you didn't recognize the sarcasm. On 7/10/07, Argent Stonecutter wrote: > > From: "Chance Unknown" > > since your target is SL, the people most argumentitive about privacy > > concerns are the bored lonely housewives that sit at home looking > > for cyber > > affairs. of course they want their identities masked. they dont get > > that > > kind of privay when looking for a hookup at myspace or facebook. > > If we can carry on this discussion without demonizing or belittling > people (people who are, furthermore, not present to defend > themselves) I believe it will be more productive. > _______________________________________________ > 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/20070710/170d78db/attachment.htm From secret.argent at gmail.com Tue Jul 10 19:15:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jul 10 19:15:05 2007 Subject: [sldev] Re: Where we are headed in IPC development (Phoenix) In-Reply-To: <4694220D.6080500@dzonux.net> References: <20070710220902.C421441AF1B@stupor.lindenlab.com> <43E402EF-9AF4-46B3-B783-2C4ED63F4894@gmail.com> <4694220D.6080500@dzonux.net> Message-ID: On 10-Jul-2007, at 19:19, Dzonatas wrote: > Argent Stonecutter wrote: >> Looks like it's got a lot in common with Usenet, with duplicated >> message IDs receiving identical responses rather than being >> dropped. I'm not sure about the requirement that the URL and >> response be opaque, do you simply mean that chttp must not modify >> them? That's what the implementation would seem to imply. > Hey now, the IHAVE/SENDME protocol of USENET was one of the best > eras to get a distribution across the world before such concepts as > an always-on Internet connection. Hey, you don't need to convince me. I've been on Usenet since 1981. This is one of those really clever and simple designs that needs to be widely adopted. That it's based on an existing clever and simple design is not a problem. :) From dale at daleglass.net Tue Jul 10 19:29:37 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 10 19:29:49 2007 Subject: [sldev] Very experimental viewer released Message-ID: <20070711022937.GE7685@bruno.sbruno> I've been working on my own version of the viewer. Here's the result: http://daleglass.net/installer/sl_rev_38.exe Codebase is based on 1.17.3.0, although it tries to find llkdu.dll distributed with 1.17.3.1 (remains of a test I did for a tester) It will work by trying to get files from official installs, if any. It'll try to grab Kakadu from there. If it can't, it'll go on anyway (should use openjpeg instead) Changes: * Branding * Changed the channel, so grid won't offer updates * Avatar scanner (View/Avatar List) * Partial support for my reputation system (won't work, needs attachment for now) Known problems: * Installer is glacially slow if you're doing a full install (much faster if you've got an official viewer installed) * I've seen the installer crash once, couldn't reproduce yet (will continue from where it stopped if restarted though) Avatar list usage: Columns: * Name * Distance * Age * Score (won't work) * Payment info * Activity: walking, making sounds, particles, gone Lindens appear in bold Avatars that left are kept in the list for a short time Click column to sort Double click a row to focus camera on avatar Scanning range is roughly the draw distance Actions tab: Should be mostly self-explanatory. Select multiple people and click IM to create a group chat with the selected people. TrustNet tab: Won't work Luskwood tab: Specific to Luskwood, only useful if you're a moderator there. Options tab: Self-explanatory Installer has been giving me some trouble and should be done and fully released with source tomorrow. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/e837c288/attachment-0001.pgp From dereck at gmail.com Tue Jul 10 20:00:12 2007 From: dereck at gmail.com (Dereck Wonnacott) Date: Tue Jul 10 20:00:14 2007 Subject: [sldev] Log question Message-ID: <2d8148cd0707102000u24ed73bam6027a551faa1e39f@mail.gmail.com> Hi all! I've got the VWR compiled with all x64 libs and not including FMOD on Ubuntu 7.04 AMD64 today. YAY! When I attempt to connect with official or my compiled VWR, I find this in the console: 2007-07-11T01:39:42Z INFO: idle_startup: Verifying message template... 2007-07-11T01:39:42Z WARNING: decodeTemplate: Message #0 received but not registered! 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Dump from: 192.168.0.1:53 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Size:230 ...?useless? dump of packet... 2007-07-11T01:39:42Z WARNING: checkMessages: Packet from invalid circuit 192.168.0.1:53 Then the VRW goes bye bye. I dont know what that that stuff above means or where to look to fix it. Sorry if it is obvious, I'm still new to this. I'm keeping track of it here: https://jira.secondlife.com/browse/VWR-1606 ~Dereck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070710/3c86f650/attachment.htm From tateru.nino at gmail.com Tue Jul 10 20:22:41 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jul 10 20:22:48 2007 Subject: [sldev] Log question In-Reply-To: <2d8148cd0707102000u24ed73bam6027a551faa1e39f@mail.gmail.com> References: <2d8148cd0707102000u24ed73bam6027a551faa1e39f@mail.gmail.com> Message-ID: <46944D01.5050709@gmail.com> Port 53. That's a DNS response. Why would a DNS packet be being passed to the message decoder? Dereck Wonnacott wrote: > Hi all! > > I've got the VWR compiled with all x64 libs and not including FMOD on > Ubuntu 7.04 AMD64 today. YAY! When I attempt to connect with official > or my compiled VWR, I find this in the console: > > 2007-07-11T01:39:42Z INFO: idle_startup: Verifying message template... > 2007-07-11T01:39:42Z WARNING: decodeTemplate: Message #0 received but > not registered! > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Dump > from:192.168.0.1:53 > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Size:230 > ...?useless? dump of packet... > 2007-07-11T01:39:42Z WARNING: checkMessages: Packet from invalid > circuit 192.168.0.1:53 > > > Then the VRW goes bye bye. I dont know what that that stuff above > means or where to look to fix it. Sorry if it is obvious, I'm still > new to this. > > I'm keeping track of it here: https://jira.secondlife.com/browse/VWR-1606 > > > ~Dereck > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From kerdezixe at gmail.com Tue Jul 10 22:18:34 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jul 10 22:18:38 2007 Subject: [sldev] Bugtracking tool Message-ID: <8a1bfe660707102218u411d10etdf40b8f8fafb3ac3@mail.gmail.com> Hello, i'm kerunix Flan. i'm the biggest french sim owner and own the most popular french sim, including the french school (sim : gaia) with a big community and a lot of voluntary helper (we currently limit the amount of volunteers). I'm creating my website, dedicated to SL of course. Currently in beta-test, featuring forums, calendars, the registration api, etc ... I installed a livehelp system, powered by "craftysyntax", i don't know if i'll use it, yet. I have some betatesters and they found some bugs on my website, more than i tought. So i want to install a bugtracking system, for my website/forum/etc and... why not ... Secondlife bug category for french ppl who can't write english and bug triage session to report translated bug on the LL's public jira. Naturally, i wanted to install JIRA but it's really too expensive. (and require another webserver, my current webserver don't support java stuff, but it's not a blocking problem. The price of jira is.) I know bugzilla but it's pain in the *** for the user and admin. The only other bugtracker i know is mantis (last time i used it was 4 years ago, i think). Do you know another web-based bugtracker tool, multi user, with functionality close to JIRA ? i know JIRA : too expensive bugzilla : too complex, not "user friendly". mantis : not bad :) something else ? thx -- kerunix Flan http://www.electrosphere.fr/ From jhurliman at wsu.edu Tue Jul 10 23:01:52 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Jul 10 23:03:26 2007 Subject: [sldev] Bugtracking tool In-Reply-To: <8a1bfe660707102218u411d10etdf40b8f8fafb3ac3@mail.gmail.com> References: <8a1bfe660707102218u411d10etdf40b8f8fafb3ac3@mail.gmail.com> Message-ID: <46947250.3010408@wsu.edu> Laurent Laborde wrote: > Hello, i'm kerunix Flan. > i'm the biggest french sim owner and own the most popular french sim, > including the french school (sim : gaia) with a big community and a > lot of voluntary helper (we currently limit the amount of volunteers). > > I'm creating my website, dedicated to SL of course. > Currently in beta-test, featuring forums, calendars, the registration > api, etc ... > I installed a livehelp system, powered by "craftysyntax", i don't know > if i'll use it, yet. > > > I have some betatesters and they found some bugs on my website, more > than i tought. > So i want to install a bugtracking system, for my website/forum/etc > and... why not ... Secondlife bug category for french ppl who can't > write english and bug triage session to report translated bug on the > LL's public jira. > > > Naturally, i wanted to install JIRA but it's really too expensive. > (and require another webserver, my current webserver don't support > java stuff, but it's not a blocking problem. The price of jira is.) > > I know bugzilla but it's pain in the *** for the user and admin. > The only other bugtracker i know is mantis (last time i used it was 4 > years ago, i think). > > Do you know another web-based bugtracker tool, multi user, with > functionality close to JIRA ? > > i know JIRA : too expensive > bugzilla : too complex, not "user friendly". > mantis : not bad :) > something else ? > > thx > > The libsecondlife and OpenSim projects share an install of Mantis and it seems to work well. Maybe not the simplest to understand interface for non-developer users though, so keep your target audience in mind. John Hurliman From kerdezixe at gmail.com Tue Jul 10 23:41:16 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue Jul 10 23:41:18 2007 Subject: [sldev] "bogus bug" triage - MISC Message-ID: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> I'm playing with jira today. Here is my triage : - MISC-377 : whining about a a notecard bug. Incomplete, probably duplicated with a VWR or SVC bug. Close it ? ("missfilled" ?) - MISC-253 : Legal question/suggestion about international law, age verification. Add a comment and close it ? (i suggest a "won't fix") - MISC-347 About bulk mail not sent by "@lindenlab.com" but "vresp". Upgraded to "Blocking" because it *could* block. Should be downgraded to "major", or "normal". - MISC-280 Permission(?) bug / Bogus creator name. Not a MISC bug. VWR-permission maybe ? - MISC-252 Feature request about hierarchical linked set. Not a MISC . Certainly not "critical". Don't provide enough information about how "grandchild" link set is supposed to work. I bet for a "won't fix" :) - MISC-235 Suggestion about pending uploads/downloads in sim. Should be changed to "feature request" and ... mmm ... SVC ? Shouldn't be "critical" and better fix the pending download/upload bug instead of adding a poor workaround. - MISC-316 SLRR Trains Keep Disappearing. Ingame issue about the SLRR train. Shouldn't be critical. Shouldn't be in jira. poke the land managment team about that ? - MISC-189 Copy/Resale permision not working. Buggy "allow anyone to copy". Move it to VWR-permission bug ? - MISC-181 Upload animation faillure. Old, seems related to a bogus bvh file, as patchouli said in the comment. User never replied. Close it ? There is still a lot of MISC to check, but JIRA is too slow. just wake up and already falling asleep on my keyboard waiting for jira :) -- kerunix Flan From kerdezixe at gmail.com Wed Jul 11 00:53:14 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 00:53:16 2007 Subject: [sldev] https very slow. Message-ID: <8a1bfe660707110053i1dee3963u26f96d6fba525bb5@mail.gmail.com> Hi again ! Some of us are complaining about *really* slow jira while some other one say it's "not that bad". I noticed that https://wiki.secondlife.com/ is insanly slower (unuseable) than http://wiki.secondlife.com/ (http vs https) Is it possible that, somewhere in the nested network, http and https and not routed in the same way and https may be superslow for some location in the world ? Since the jira is all https, that could explain why some people see the jira much slower than some other ppl. also, we noticed a long time ago (it's not hapenning anymore) that european sometime lose the capability while, in the SAME SIM, the US folk still have the caps. and if i remember correctly the caps are https. It happened more frequently when the sim was hosted in the texas coloc. -- kerunix Flan From matthew.dowd at hotmail.co.uk Wed Jul 11 01:16:51 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 11 01:16:52 2007 Subject: [sldev] https very slow. Message-ID: May not be routing. It could be some hiccup or timeout doing the certificate chain validation and/or attempting to retrieve certificate revocation lists. https is always slower than http due to the overhead of setting up the encryption each request: quite a lot of sites which don't dealing with confidential information (so for instance wikis, message boards, etc.) use https just for the authentication step (to protect username and password) and/or signup process but then drop to http. The difference between https and http is particularly noticeable if you are doing a lot of small requests in quick succession (each involving setting up and taking down the encryption stack), so even https enabling websites may use http for static images (especially if they have a lot of small icons). Another solution is to use http pipeling (http://en.wikipedia.org/wiki/HTTP_pipelining) so that you only set up the encrytion stack once and send all the requests and responses over the same connection - does the SL caps stuff use this? Matthew ---------------------------------------- > Date: Wed, 11 Jul 2007 09:53:14 +0200 > From: kerdezixe@gmail.com > To: sldev@lists.secondlife.com > Subject: [sldev] https very slow. > > Hi again ! > Some of us are complaining about *really* slow jira while some other > one say it's "not that bad". > > I noticed that https://wiki.secondlife.com/ is insanly slower > (unuseable) than http://wiki.secondlife.com/ > (http vs https) > > Is it possible that, somewhere in the nested network, http and https > and not routed in the same way and https may be superslow for some > location in the world ? > > Since the jira is all https, that could explain why some people see > the jira much slower than some other ppl. > > also, we noticed a long time ago (it's not hapenning anymore) that > european sometime lose the capability while, in the SAME SIM, the US > folk still have the caps. and if i remember correctly the caps are > https. > It happened more frequently when the sim was hosted in the texas coloc. > > -- > kerunix Flan > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From kerdezixe at gmail.com Wed Jul 11 01:17:51 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 01:17:53 2007 Subject: [sldev] Re: "bogus bug" triage - MISC In-Reply-To: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> References: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> Message-ID: <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> Updating the triage. anyone willing to open a wiki page for the "bogus bug" ? If someone create a template, i'll happily fill the page, i don't know the syntax to create a nice wiki template. - MISC-377 : https://jira.secondlife.com/browse/MISC-377 description : whining about a a notecard bug. Incomplete, probably duplicated with a VWR or SVC bug. (VWR-permission ?) suggestion : Close it ? ("missfilled" ?) - MISC-347 : https://jira.secondlife.com/browse/MISC-347 description : About bulk mail not sent by "@lindenlab.com" but "vresp". Upgraded to "Blocking" because it *could* block. suggestion : Should be downgraded to "major", or "normal". - MISC-253 : https://jira.secondlife.com/browse/MISC-253 description : Legal question/suggestion about international law, age verification. suggestion : Add a comment and close it ? (i suggest a "won't fix") - MISC-280 : https://jira.secondlife.com/browse/MISC-280 description : Permission(?) bug / Bogus creator name. suggestion : Not a MISC bug. VWR-permission maybe ? - MISC-252 : https://jira.secondlife.com/browse/MISC-252 Description Feature request about hierarchical linked set. Suggestion : Not a MISC . Certainly not "critical". Don't provide enough information about how "grandchild" link set is supposed to work. I bet for a "won't fix" or "need more info" - MISC-235 : https://jira.secondlife.com/browse/MISC-235 Description : Suggestion about pending uploads/downloads in sim. Suggestion : Should be changed to "feature request" and ... mmm ... SVC ? Shouldn't be "critical". link it to MISC-100, SVC-188, VWR-673 - MISC-316 : https://jira.secondlife.com/browse/MISC-316 Description : SLRR Trains Keep Disappearing. Ingame issue about the SLRR train. Suggestion : Shouldn't be critical. Shouldn't be in jira. poke the land managment team about that and close ? - MISC-189 : https://jira.secondlife.com/browse/MISC-189 Description : Copy/Resale permision not working. Buggy "allow anyone to copy". Suggestion : Move it to VWR-permission bug ? - MISC-181 : https://jira.secondlife.com/browse/MISC-181 Description : Upload animation faillure. Old, seems related to a bogus bvh file, as patchouli said in the comment. User never replied. Suggestion : Close it, "need more info" ? nicer :) -- kerunix Flan From matthew.dowd at hotmail.co.uk Wed Jul 11 01:27:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 11 01:27:18 2007 Subject: [sldev] "bogus bug" triage - MISC Message-ID: > - MISC-347 > About bulk mail not sent by "@lindenlab.com" but "vresp". Upgraded to > "Blocking" because it *could* block. > Should be downgraded to "major", or "normal". Not really blocker, but someone needs to kick LL policy team on this one - (a) it is pretty poor practice (b) it is no good blogging a warning about phishing attacks when LL's billing e-mails and registration process contain all the suspicious danger signals that the references supplied in that blog told people to look out for! Anyway, I'd better get off my soapbox on this one. > - MISC-316 > SLRR Trains Keep Disappearing. > Ingame issue about the SLRR train. > Shouldn't be critical. Shouldn't be in jira. Which begs the question where should issues like this be? Do we perhaps need a land management project in Jira? Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From jhurliman at wsu.edu Wed Jul 11 01:28:05 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Jul 11 01:29:39 2007 Subject: [sldev] https very slow. In-Reply-To: References: Message-ID: <46949495.1060809@wsu.edu> Matthew Dowd wrote: > May not be routing. It could be some hiccup or timeout doing the certificate chain validation and/or attempting to retrieve certificate revocation lists. > > https is always slower than http due to the overhead of setting up the encryption each request: quite a lot of sites which don't dealing with confidential information (so for instance wikis, message boards, etc.) use https just for the authentication step (to protect username and password) and/or signup process but then drop to http. The difference between https and http is particularly noticeable if you are doing a lot of small requests in quick succession (each involving setting up and taking down the encryption stack), so even https enabling websites may use http for static images (especially if they have a lot of small icons). > > Another solution is to use http pipeling (http://en.wikipedia.org/wiki/HTTP_pipelining) so that you only set up the encrytion stack once and send all the requests and responses over the same connection - does the SL caps stuff use this? > > Matthew > CAPS holds connections from the client to the server open until the server has something to say, or the connection times out. After either case the connection is immediately re-established, so you are only setting up and tearing down https connections if there are a lot of events coming over CAPS. John Hurliman From matthew.dowd at hotmail.co.uk Wed Jul 11 01:43:01 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 11 01:43:02 2007 Subject: [sldev] https very slow. Message-ID: > CAPS holds connections from the client to the server open until the > server has something to say, or the connection times out. After either > case the connection is immediately re-established, so you are only > setting up and tearing down https connections if there are a lot of > events coming over CAPS. My understanding of http pipelining is that in the latter situation (lots of events coming in over CAPS) you could still use the same https connection and not have to set up and tear down https connections in that scenario. Sorry, I've not delved into CAPS enough to know if that scenario is particularly likely and whether using http pipelining would be an optimisation or a case of diminishing returns. Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From gigstaggart at gmail.com Wed Jul 11 01:46:00 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 11 01:46:28 2007 Subject: [sldev] Re: "bogus bug" triage - MISC In-Reply-To: <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> References: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> Message-ID: <469498C8.7080308@gmail.com> Laurent Laborde wrote: > Updating the triage. > anyone willing to open a wiki page for the "bogus bug" ? > If someone create a template, i'll happily fill the page, i don't know > the syntax to create a nice wiki template. > No, don't do that. This stuff changes too fast for a wiki. > - MISC-377 : https://jira.secondlife.com/browse/MISC-377 > description : whining about a a notecard bug. Incomplete, probably > duplicated with a > VWR or SVC bug. (VWR-permission ?) > suggestion : Close it ? ("missfilled" ?) > Duplicate > - MISC-347 : https://jira.secondlife.com/browse/MISC-347 > description : About bulk mail not sent by "@lindenlab.com" but > "vresp". Upgraded to > "Blocking" because it *could* block. > suggestion : Should be downgraded to "major", or "normal". > Change to "bug", downgrade to critical. If a linden is watching this.... PLEASE import MISC-347. It's a valid and important issue. > - MISC-253 : https://jira.secondlife.com/browse/MISC-253 > description : Legal question/suggestion about international law, age > verification. > suggestion : Add a comment and close it ? (i suggest a "won't fix") Linden Lab is based in the US. They must comply with US law. I recommend resolving won't fix. > - MISC-280 : https://jira.secondlife.com/browse/MISC-280 > description : Permission(?) bug / Bogus creator name. > suggestion : Not a MISC bug. VWR-permission maybe ? Leave in MISC. Resolve needs repro. > - MISC-252 : https://jira.secondlife.com/browse/MISC-252 > Description Feature request about hierarchical linked set. > Suggestion : Not a MISC . Certainly not "critical". Don't provide > enough information about how "grandchild" link set is supposed to > work. I bet for a "won't fix" or "need more info" Search for heirarchy linking duplicates, if there are none, leave it alone. > - MISC-235 : https://jira.secondlife.com/browse/MISC-235 > Description : Suggestion about pending uploads/downloads in sim. > Suggestion : Should be changed to "feature request" and ... mmm ... > SVC ? Shouldn't be "critical". link it to MISC-100, SVC-188, VWR-673 > This is old, resolve it can't reproduce. > - MISC-316 : https://jira.secondlife.com/browse/MISC-316 > Description : SLRR Trains Keep Disappearing. Ingame issue about the SLRR > train. > Suggestion : Shouldn't be critical. Shouldn't be in jira. poke the > land managment > team about that and close ? > No, leave it on Jira. Someone should probably poke one of the lindens that works on the train though. > - MISC-189 : https://jira.secondlife.com/browse/MISC-189 > Description : Copy/Resale permision not working. Buggy "allow anyone to > copy". > Suggestion : Move it to VWR-permission bug ? I got informal confirmation on this repro from Lasivian on IRC. I say leave it in MISC until it's determined whether it's client or server side. > > - MISC-181 : https://jira.secondlife.com/browse/MISC-181 > Description : Upload animation faillure. Old, seems related to a bogus > bvh file, as patchouli said in the comment. User never replied. > Suggestion : Close it, "need more info" ? Yes, resolve needs more info. Don't close bugs in general. From tateru.nino at gmail.com Wed Jul 11 02:34:35 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 11 02:34:45 2007 Subject: [sldev] https very slow. In-Reply-To: References: Message-ID: <4694A42B.9020103@gmail.com> https defaults to connection re-use (and may in some circumstances, also pipeline, though true pipelining - that is multiple outstanding requests on the same connection- is rare). The reason that it's sometimes slower when viewing websites is that most browsers do not parallelize https connections to a server, but instead waits for responses on the pipe before issuing further requests. That said, the slowdowns of this approach are significantly mitgated by the widening of the TCP window after a couple of entities have transferred. Matthew Dowd wrote: > > >> CAPS holds connections from the client to the server open until the >> server has something to say, or the connection times out. After either >> case the connection is immediately re-established, so you are only >> setting up and tearing down https connections if there are a lot of >> events coming over CAPS. >> > > My understanding of http pipelining is that in the latter situation (lots of events coming in over CAPS) you could still use the same https connection and not have to set up and tear down https connections in that scenario. Sorry, I've not delved into CAPS enough to know if that scenario is particularly likely and whether using http pipelining would be an optimisation or a case of diminishing returns. > > Matthew > _________________________________________________________________ > 100?s of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Tateru Nino http://dwellonit.blogspot.com/ From dereck at gmail.com Wed Jul 11 04:29:21 2007 From: dereck at gmail.com (Dereck Wonnacott) Date: Wed Jul 11 04:29:24 2007 Subject: [sldev] Log question In-Reply-To: <46944D01.5050709@gmail.com> References: <2d8148cd0707102000u24ed73bam6027a551faa1e39f@mail.gmail.com> <46944D01.5050709@gmail.com> Message-ID: <2d8148cd0707110429y54ccce10i4e39bf2ba92d384e@mail.gmail.com> Wewt! I got in, crashed within 10 seconds, but thats progress! well well well, I'm not sure exaclty why, but I changed my DNS servers to OpenDNS, and I can log in JUST FINE! Is this a bug, or some misconfiguration on my part, I dunno~? ~Dereck [https://jira.secondlife.com/browse/VWR-1606] On 7/10/07, Tateru Nino wrote: > > Port 53. That's a DNS response. Why would a DNS packet be being passed > to the message decoder? > > Dereck Wonnacott wrote: > > Hi all! > > > > I've got the VWR compiled with all x64 libs and not including FMOD on > > Ubuntu 7.04 AMD64 today. YAY! When I attempt to connect with official > > or my compiled VWR, I find this in the console: > > > > 2007-07-11T01:39:42Z INFO: idle_startup: Verifying message template... > > 2007-07-11T01:39:42Z WARNING: decodeTemplate: Message #0 received but > > not registered! > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Dump > > from:192.168.0.1:53 > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Size:230 > > ...?useless? dump of packet... > > 2007-07-11T01:39:42Z WARNING: checkMessages: Packet from invalid > > circuit 192.168.0.1:53 > > > > > > Then the VRW goes bye bye. I dont know what that that stuff above > > means or where to look to fix it. Sorry if it is obvious, I'm still > > new to this. > > > > I'm keeping track of it here: > https://jira.secondlife.com/browse/VWR-1606 > > > > > > ~Dereck > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070711/3ca98196/attachment.htm From kerdezixe at gmail.com Wed Jul 11 04:48:16 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 04:48:19 2007 Subject: [sldev] Bugtracking tool In-Reply-To: <46947250.3010408@wsu.edu> References: <8a1bfe660707102218u411d10etdf40b8f8fafb3ac3@mail.gmail.com> <46947250.3010408@wsu.edu> Message-ID: <8a1bfe660707110448k73479984id4e3f1d4b57bd4af@mail.gmail.com> On 7/11/07, John Hurliman wrote: > > The libsecondlife and OpenSim projects share an install of Mantis and it > seems to work well. Maybe not the simplest to understand interface for > non-developer users though, so keep your target audience in mind. I installed mantis on http://www.electrosphere.fr/bug/ for testing. I'm still open to suggestion for other bt tools. thx :) -- Kerunix Flan From kerdezixe at gmail.com Wed Jul 11 07:04:49 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 07:04:51 2007 Subject: [sldev] Bugtracking tool In-Reply-To: <8a1bfe660707110448k73479984id4e3f1d4b57bd4af@mail.gmail.com> References: <8a1bfe660707102218u411d10etdf40b8f8fafb3ac3@mail.gmail.com> <46947250.3010408@wsu.edu> <8a1bfe660707110448k73479984id4e3f1d4b57bd4af@mail.gmail.com> Message-ID: <8a1bfe660707110704x74c2deb2qe2ac617090d12c80@mail.gmail.com> On 7/11/07, Laurent Laborde wrote: > On 7/11/07, John Hurliman wrote: > > > > The libsecondlife and OpenSim projects share an install of Mantis and it > > seems to work well. Maybe not the simplest to understand interface for > > non-developer users though, so keep your target audience in mind. > > I installed mantis on http://www.electrosphere.fr/bug/ for testing. > I'm still open to suggestion for other bt tools. http://www.atlassian.com/software/views/opensource-license-request.jsp atlassian offer licence to opensource project. I give it a try ;) -- kerunix Flan From robla at lindenlab.com Wed Jul 11 08:31:02 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jul 11 08:32:02 2007 Subject: [sldev] https very slow. In-Reply-To: <8a1bfe660707110053i1dee3963u26f96d6fba525bb5@mail.gmail.com> References: <8a1bfe660707110053i1dee3963u26f96d6fba525bb5@mail.gmail.com> Message-ID: <4694F7B6.4000808@lindenlab.com> On 7/11/07 12:53 AM, Laurent Laborde wrote: > Some of us are complaining about *really* slow jira while some other > one say it's "not that bad". > > I noticed that https://wiki.secondlife.com/ is insanly slower > (unuseable) than http://wiki.secondlife.com/ > (http vs https) > > Is it possible that, somewhere in the nested network, http and https > and not routed in the same way and https may be superslow for some > location in the world ? I've been hit by wiki.secondlife.com being unusably slow too, and I'm already working with our vendor. The problem, we suspect, is that we're relying on NFS where we really shouldn't be. We think that one machine in the cluster will get blocked because NFS stalls somehow; the others are fine and so most people don't see the problem. The http vs. https distinction is only important because you're probably going to hit a different machine in the cluster when you switch protocols (view source on the html, and look at the bottom of the page to confirm this). We're going to be addng memcached in the mix (and thus, subtract much of our NFS reliance). We're hoping that fixes things. It's going to take some time to get things set up, so in the meantime, sorry. As near as we know, this has nothing to do with any issues in Second Life itself. The only connection between the two is logins, and that only hits the SL infrastructure at the time of login, not on subsequent attempts. While it's /possible/ that we're running into an awful blocking problem on the login stage, we don't think that's what's going on. We're on it, but if you want, go ahead and file a ticket in JIRA and then let everyone know what that ticket is. I'll give further updates when we think we've got this issue fixed. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/458c23c4/signature-0001.pgp From kerdezixe at gmail.com Wed Jul 11 08:59:29 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 08:59:34 2007 Subject: [sldev] https very slow. In-Reply-To: <4694F7B6.4000808@lindenlab.com> References: <8a1bfe660707110053i1dee3963u26f96d6fba525bb5@mail.gmail.com> <4694F7B6.4000808@lindenlab.com> Message-ID: <8a1bfe660707110859m23ce018ar919dba56306c2de9@mail.gmail.com> On 7/11/07, Rob Lanphier wrote: > On 7/11/07 12:53 AM, Laurent Laborde wrote: > > Some of us are complaining about *really* slow jira while some other > > one say it's "not that bad". > > > > I noticed that https://wiki.secondlife.com/ is insanly slower > > (unuseable) than http://wiki.secondlife.com/ > > (http vs https) > > > > Is it possible that, somewhere in the nested network, http and https > > and not routed in the same way and https may be superslow for some > > location in the world ? > > I've been hit by wiki.secondlife.com being unusably slow too, and I'm > already working with our vendor. The problem, we suspect, is that we're > relying on NFS where we really shouldn't be. We think that one machine > in the cluster will get blocked because NFS stalls somehow; the others > are fine and so most people don't see the problem. The http vs. https > distinction is only important because you're probably going to hit a > different machine in the cluster when you switch protocols (view source > on the html, and look at the bottom of the page to confirm this). Thx rob. Reported on jira : https://jira.secondlife.com/browse/WEB-223 -- kerunix Flan From gwardell at gwsystems.co.il Wed Jul 11 09:29:12 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Wed Jul 11 09:29:20 2007 Subject: [sldev] https very slow. In-Reply-To: <4694F7B6.4000808@lindenlab.com> Message-ID: <040e01c7c3d8$9e49fdf0$a4689943@gwsystems2.com> > On 7/11/07 12:53 AM, Laurent Laborde wrote: > > Some of us are complaining about *really* slow jira while some other > > one say it's "not that bad". > > > > I noticed that https://wiki.secondlife.com/ is insanly slower > > (unuseable) than http://wiki.secondlife.com/ > > (http vs https) > > > > Is it possible that, somewhere in the nested network, http and https > > and not routed in the same way and https may be superslow for some > > location in the world ? > Hi, >From a provider's stand point, only pages/requests that need to be encrypted should be encrypted. Pages/requests that don't have sensitive information on them shouldn't be, as encrypting those places significant unnecessary load on the server. Hosts, such as financial institutions, that require a high number of pages to be encrypted use SSL accelerators on the front end to off-load the encryption form their servers. This (SSL accelerators) might be something to consider for in world transactions, but I doubt it's needed for jira or wiki logons, but I don't have access to the numbers to be sure. However, I don't see why SSL would be needed for jira and wiki content. Gary From kerdezixe at gmail.com Wed Jul 11 09:40:38 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 09:40:40 2007 Subject: [sldev] https very slow. In-Reply-To: <040e01c7c3d8$9e49fdf0$a4689943@gwsystems2.com> References: <4694F7B6.4000808@lindenlab.com> <040e01c7c3d8$9e49fdf0$a4689943@gwsystems2.com> Message-ID: <8a1bfe660707110940n32bfadcfxfd3eb1a94f906f74@mail.gmail.com> On 7/11/07, Gary Wardell wrote: > > On 7/11/07 12:53 AM, Laurent Laborde wrote: > > > Some of us are complaining about *really* slow jira while some other > > > one say it's "not that bad". > > > > > > I noticed that https://wiki.secondlife.com/ is insanly slower > > > (unuseable) than http://wiki.secondlife.com/ > > > (http vs https) > > > > > > Is it possible that, somewhere in the nested network, http and https > > > and not routed in the same way and https may be superslow for some > > > location in the world ? > > > > Hi, > > >From a provider's stand point, only pages/requests that need to be encrypted should be encrypted. Pages/requests that don't have > sensitive information on them shouldn't be, as encrypting those places significant unnecessary load on the server. > > Hosts, such as financial institutions, that require a high number of pages to be encrypted use SSL accelerators on the front end > to off-load the encryption form their servers. > > This (SSL accelerators) might be something to consider for in world transactions, but I doubt it's needed for jira or wiki logons, > but I don't have access to the numbers to be sure. However, I don't see why SSL would be needed for jira and wiki content. I only use http wiki, but sometime i follow a link which is https. And there is no "http version" of the public jira. -- Kerunix Flan From nicholaz at blueflash.cc Wed Jul 11 09:54:29 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 09:54:38 2007 Subject: [sldev] https very slow. In-Reply-To: <040e01c7c3d8$9e49fdf0$a4689943@gwsystems2.com> References: <040e01c7c3d8$9e49fdf0$a4689943@gwsystems2.com> Message-ID: <46950B45.6080502@blueflash.cc> Btw, one of the first things I wondered about was the use of https in the viewer. (Reason was of course, that the memory leak was caused by libcurl https requests.) But with the efforts of shaving cpu cycles off the main loop, it may be worth looking at the things that go through encryption, because these may eat a non trivial amount of cpu cycles on both ends. I have not looked at it in any depth because at this point I'm not interested in optimization, so I may be totally off the mark, but it may be worth a look. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From gwardell at gwsystems.co.il Wed Jul 11 10:05:55 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Wed Jul 11 10:06:06 2007 Subject: [sldev] https very slow. In-Reply-To: <46950B45.6080502@blueflash.cc> Message-ID: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> Hi, Well, I haven't time to look closely at the viewer, but in general, form a privacy and security standpoint (I work in these areas), encryption is needed anytime there is personally identifiable information being passed back and forth. Examples of this sort of things would be names, address, credit card or bank account numbers. Usually all three of these need to be present to qualify. Normally most monetary transactions need to e encrypted as they carry all of this information. So, given that one can do monetary transaction through the viewer, it may need encryption. However, if the transactions are actually done on the server, and no sensitive information is in the viewer, ... That being said, encryption would be superfluous for non-monetary transactions. Also, it is more than a few cpu cycles. Actually it can be significant. It also balloons the size of the payload so it requires more bandwidth. Gary > -----Original Message----- > From: Nicholaz Beresford [mailto:nicholaz@blueflash.cc] > Sent: Wed, July 11, 2007 12:54 PM > To: Gary Wardell > Cc: sldev@lists.secondlife.com > Subject: Re: [sldev] https very slow. > > > > Btw, one of the first things I wondered about was > the use of https in the viewer. (Reason was of course, > that the memory leak was caused by libcurl https > requests.) > > But with the efforts of shaving cpu cycles off the > main loop, it may be worth looking at the things that > go through encryption, because these may eat a > non trivial amount of cpu cycles on both ends. > > I have not looked at it in any depth because at this > point I'm not interested in optimization, so I may be > totally off the mark, but it may be worth a look. > > > Nick > --- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > From bos at lindenlab.com Wed Jul 11 10:14:39 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Jul 11 10:14:42 2007 Subject: [sldev] "bogus bug" triage - MISC In-Reply-To: References: Message-ID: <46950FFF.2020506@lindenlab.com> Matthew Dowd wrote: > Not really blocker, but someone needs to kick LL policy team on this one - > > (a) it is pretty poor practice > (b) it is no good blogging a warning about phishing attacks when LL's billing e-mails and registration process contain all the suspicious danger signals that the references supplied in that blog told people to look out for! We've already had exactly this discussion internally. As far as I know, Vertical Response won't be sending any more emails out until they and we have figured out how to ensure that they at least look like they're coming from us, and that any embedded URLs are in our domain. References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> Message-ID: <469515B0.6030508@blueflash.cc> Gary Wardell wrote: > So, given that one can do monetary transaction through the viewer, it may need encryption. However, if the transactions are > actually done on the server, and no sensitive information is in the viewer, ... > > That being said, encryption would be superfluous for non-monetary transactions. > > Also, it is more than a few cpu cycles. Actually it can be significant. It also balloons the size of the payload so it requires > more bandwidth. I'm sure it's more than that (these were up to a few hundred per minute as far as I remember). It may have something to do with securing copyright (like limiting the ability to intercept objects or textures through a proxy), but dunno really ... just remember that I was wondering about it at that time. Nick From dale at daleglass.net Wed Jul 11 10:56:54 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 11 10:57:00 2007 Subject: [sldev] https very slow. In-Reply-To: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> Message-ID: <20070711175653.GA14142@bruno.sbruno> On Wed, Jul 11, 2007 at 01:05:55PM -0400, Gary Wardell wrote: > So, given that one can do monetary transaction through the viewer, it may need encryption. However, if the transactions are > actually done on the server, and no sensitive information is in the viewer, ... I consider data about the transaction (such as when it happens, the amount, and from who to who) sensitive as well. > > That being said, encryption would be superfluous for non-monetary transactions. And chat messages. People have sensitive conversations sometimes, and many people can only contact each other through SL. So there are going to be people there doing things like sending passwords by IM. > > Also, it is more than a few cpu cycles. Actually it can be significant. It also balloons the size of the payload so it requires > more bandwidth. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 106414.88k 110166.80k 111630.30k 112218.07k 112954.03k aes-192 cbc 94869.67k 97565.29k 99250.35k 99177.31k 98961.55k aes-256 cbc 85501.83k 87546.11k 88859.48k 89190.40k 89300.99k So, my box can do aes-256 at about 90MB/s on one core. I don't think I've seen much more than 300KB/s normally, so that's about 3ms. For the viewer it's really insignificant. Of course it's a lot more significant for the sim, but the average amount of data being transferred should be well below 300 KB/s per agent. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/2a3c20b1/attachment.pgp From gigstaggart at gmail.com Wed Jul 11 11:01:46 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 11 11:02:10 2007 Subject: [sldev] https very slow. In-Reply-To: <20070711175653.GA14142@bruno.sbruno> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> Message-ID: <46951B0A.4030406@gmail.com> Dale Glass wrote: > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > aes-128 cbc 106414.88k 110166.80k 111630.30k 112218.07k 112954.03k > aes-192 cbc 94869.67k 97565.29k 99250.35k 99177.31k 98961.55k > aes-256 cbc 85501.83k 87546.11k 88859.48k 89190.40k 89300.99k > > So, my box can do aes-256 at about 90MB/s on one core. > > I don't think I've seen much more than 300KB/s normally, so that's about > 3ms. For the viewer it's really insignificant. > > Of course it's a lot more significant for the sim, but the average > amount of data being transferred should be well below 300 KB/s per > agent. RC4 would be a more relevant benchmark. RC4 is likely an order of magnitude faster than aes-256. I know I was filling up 100mbit LAN to max possible speed with RC4, on CPUs 4 years ago using scp -c arcfour. If the client is using aes-256, it should be using RC4 instead. -Jason From kerdezixe at gmail.com Wed Jul 11 11:07:04 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 11:07:06 2007 Subject: [sldev] Re: "bogus bug" triage - MISC In-Reply-To: <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> References: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> Message-ID: <8a1bfe660707111107s192ee2aey7a628e57c39abffe@mail.gmail.com> - MISC-377 : https://jira.secondlife.com/browse/MISC-377 Closed "misfiled" - MISC-347 : https://jira.secondlife.com/browse/MISC-347 Action taken by rob and torley. - MISC-280 : https://jira.secondlife.com/browse/MISC-280 Closed as "missfiled" Duplicate https://jira.secondlife.com/browse/VWR-1581 - MISC-252 : https://jira.secondlife.com/browse/MISC-252 Closed "need more info". - MISC-235 : https://jira.secondlife.com/browse/MISC-235 Linked : duplicate https://jira.secondlife.com/browse/MISC-100 Someone resolved it as "cannot reproduce". - MISC-181 : https://jira.secondlife.com/browse/MISC-181 Closed "need more info". -- kerunix Flan From dale at daleglass.net Wed Jul 11 11:08:12 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 11 11:08:17 2007 Subject: [sldev] https very slow. In-Reply-To: <46951B0A.4030406@gmail.com> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> <46951B0A.4030406@gmail.com> Message-ID: <20070711180812.GB14142@bruno.sbruno> On Wed, Jul 11, 2007 at 02:01:46PM -0400, Jason Giglio wrote: > Dale Glass wrote: > >type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > >aes-128 cbc 106414.88k 110166.80k 111630.30k 112218.07k 112954.03k > >aes-192 cbc 94869.67k 97565.29k 99250.35k 99177.31k 98961.55k > >aes-256 cbc 85501.83k 87546.11k 88859.48k 89190.40k 89300.99k > > > >So, my box can do aes-256 at about 90MB/s on one core. > > > >I don't think I've seen much more than 300KB/s normally, so that's about > >3ms. For the viewer it's really insignificant. > > > >Of course it's a lot more significant for the sim, but the average > >amount of data being transferred should be well below 300 KB/s per > >agent. > > RC4 would be a more relevant benchmark. RC4 is likely an order of > magnitude faster than aes-256. Ok, rc4 then: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes rc4 265796.22k 334144.99k 354972.96k 366394.94k 363973.29k RC4 is less than perfect though: http://en.wikipedia.org/wiki/RC4#Fluhrer.2C_Mantin_and_Shamir_attack -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/0dc10bdb/attachment.pgp From robla at lindenlab.com Wed Jul 11 12:06:14 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jul 11 12:06:20 2007 Subject: [sldev] Re: "bogus bug" triage - MISC In-Reply-To: <8a1bfe660707111107s192ee2aey7a628e57c39abffe@mail.gmail.com> References: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> <8a1bfe660707111107s192ee2aey7a628e57c39abffe@mail.gmail.com> Message-ID: <46952A26.3000403@lindenlab.com> Make sure you mark things as "Resolved" rather than "Closed". General JIRA etiquette (or general bug tracker for that matter) is that the reporter is the person who moves an issue from "resolved" to "closed" as acknowledgment that they agree with the resolution. More on this topic here: https://wiki.secondlife.com/wiki/Issue_tracker Otherwise, thanks for taking action! Rob On 7/11/07 11:07 AM, Laurent Laborde wrote: > - MISC-377 : https://jira.secondlife.com/browse/MISC-377 > Closed "misfiled" > > - MISC-347 : https://jira.secondlife.com/browse/MISC-347 > Action taken by rob and torley. > > - MISC-280 : https://jira.secondlife.com/browse/MISC-280 > Closed as "missfiled" > Duplicate https://jira.secondlife.com/browse/VWR-1581 > > - MISC-252 : https://jira.secondlife.com/browse/MISC-252 > Closed "need more info". > > - MISC-235 : https://jira.secondlife.com/browse/MISC-235 > Linked : duplicate https://jira.secondlife.com/browse/MISC-100 > Someone resolved it as "cannot reproduce". > > > - MISC-181 : https://jira.secondlife.com/browse/MISC-181 > Closed "need more info". > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/27f25497/signature.pgp From secret.argent at gmail.com Wed Jul 11 12:12:13 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 11 12:12:03 2007 Subject: [sldev] Re: "bogus bug" triage - MISC (Laurent Laborde) In-Reply-To: <20070711081753.E220341AF53@stupor.lindenlab.com> References: <20070711081753.E220341AF53@stupor.lindenlab.com> Message-ID: <40F8B03A-8E36-4FD7-A364-562CBC638791@gmail.com> > - MISC-316 : https://jira.secondlife.com/browse/MISC-316 > Description : SLRR Trains Keep Disappearing. Ingame issue about the > SLRR train. > Suggestion : Shouldn't be critical. Shouldn't be in jira. poke the > land managment team about that and close ? Unfortunately there's no way to poke land management from outside any more. :( How about a new Jira category? > - MISC-189 : https://jira.secondlife.com/browse/MISC-189 > Description : Copy/Resale permision not working. Buggy "allow > anyone to copy". > Suggestion : Move it to VWR-permission bug ? Permissions should be handled in SVC, yesno? From secret.argent at gmail.com Wed Jul 11 12:23:41 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 11 12:23:30 2007 Subject: [sldev] Re: Bugtracking tool (Laurent Laborde) In-Reply-To: <20070711153201.D4D9641AF53@stupor.lindenlab.com> References: <20070711153201.D4D9641AF53@stupor.lindenlab.com> Message-ID: <1CA02CA2-7F89-4D76-B9D0-B5FA8E7DC4B3@gmail.com> kerunix Flan: > http://www.atlassian.com/software/views/opensource-license-request.jsp > atlassian offer licence to opensource project. I give it a try ;) Speaking of which, has anyone had any luck with the Atlassian client software? There should be a copy of the open source client license they sent me for the open source client project on the wiki, but I can't pull the wiki up right now to check. From dale at daleglass.net Wed Jul 11 12:27:14 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 11 12:27:19 2007 Subject: [sldev] Re: Bugtracking tool (Laurent Laborde) In-Reply-To: <1CA02CA2-7F89-4D76-B9D0-B5FA8E7DC4B3@gmail.com> References: <20070711153201.D4D9641AF53@stupor.lindenlab.com> <1CA02CA2-7F89-4D76-B9D0-B5FA8E7DC4B3@gmail.com> Message-ID: <20070711192713.GC14142@bruno.sbruno> On Wed, Jul 11, 2007 at 02:23:41PM -0500, Argent Stonecutter wrote: > kerunix Flan: > >http://www.atlassian.com/software/views/opensource-license-request.jsp > >atlassian offer licence to opensource project. I give it a try ;) > > Speaking of which, has anyone had any luck with the Atlassian client > software? > > There should be a copy of the open source client license they sent me > for the open source client project on the wiki, but I can't pull the > wiki up right now to check. I like it a lot, makes it really a lot less painful. Except, logging in doesn't work, so it's readonly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/159d0e35/attachment.pgp From labrat.hb at gmail.com Wed Jul 11 12:33:46 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Jul 11 12:33:48 2007 Subject: [sldev] Re: Bugtracking tool (Laurent Laborde) In-Reply-To: <20070711192713.GC14142@bruno.sbruno> References: <20070711153201.D4D9641AF53@stupor.lindenlab.com> <1CA02CA2-7F89-4D76-B9D0-B5FA8E7DC4B3@gmail.com> <20070711192713.GC14142@bruno.sbruno> Message-ID: Yep... I use it read only also. On 7/11/07, Dale Glass wrote: > > On Wed, Jul 11, 2007 at 02:23:41PM -0500, Argent Stonecutter wrote: > > kerunix Flan: > > >http://www.atlassian.com/software/views/opensource-license-request.jsp > > >atlassian offer licence to opensource project. I give it a try ;) > > > > Speaking of which, has anyone had any luck with the Atlassian client > > software? > > > > There should be a copy of the open source client license they sent me > > for the open source client project on the wiki, but I can't pull the > > wiki up right now to check. > > I like it a lot, makes it really a lot less painful. > > Except, logging in doesn't work, so it's readonly. > > _______________________________________________ > 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/20070711/239e0371/attachment.htm From kerdezixe at gmail.com Wed Jul 11 12:59:33 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 12:59:35 2007 Subject: [sldev] Re: "bogus bug" triage - MISC (Laurent Laborde) In-Reply-To: <40F8B03A-8E36-4FD7-A364-562CBC638791@gmail.com> References: <20070711081753.E220341AF53@stupor.lindenlab.com> <40F8B03A-8E36-4FD7-A364-562CBC638791@gmail.com> Message-ID: <8a1bfe660707111259n24e5f4dctcd82fb5c8c5c4a2e@mail.gmail.com> On 7/11/07, Argent Stonecutter wrote: > > > - MISC-189 : https://jira.secondlife.com/browse/MISC-189 > > Description : Copy/Resale permision not working. Buggy "allow > > anyone to copy". > > Suggestion : Move it to VWR-permission bug ? > > Permissions should be handled in SVC, yesno? I think so. But there is no "permission" category in SVC, only in VWR. -- kerunix Flan From seg at haxxed.com Wed Jul 11 13:51:01 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jul 11 13:50:16 2007 Subject: [sldev] https very slow. In-Reply-To: <20070711180812.GB14142@bruno.sbruno> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> <46951B0A.4030406@gmail.com> <20070711180812.GB14142@bruno.sbruno> Message-ID: <1184187061.11166.1.camel@localhost> On Wed, 2007-07-11 at 20:08 +0200, Dale Glass wrote: > On Wed, Jul 11, 2007 at 02:01:46PM -0400, Jason Giglio wrote: > > RC4 would be a more relevant benchmark. RC4 is likely an order of > > magnitude faster than aes-256. > Ok, rc4 then: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > rc4 265796.22k 334144.99k 354972.96k 366394.94k 363973.29k > > RC4 is less than perfect though: > http://en.wikipedia.org/wiki/RC4#Fluhrer.2C_Mantin_and_Shamir_attack Blowfish? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/c4ca8a53/attachment.pgp From josh at lindenlab.com Wed Jul 11 13:58:31 2007 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jul 11 13:59:36 2007 Subject: [sldev] Re: Bugtracking tool (Laurent Laborde) In-Reply-To: References: <20070711153201.D4D9641AF53@stupor.lindenlab.com> <1CA02CA2-7F89-4D76-B9D0-B5FA8E7DC4B3@gmail.com> <20070711192713.GC14142@bruno.sbruno> Message-ID: <46954477.6040409@lindenlab.com> I feel your pain. FYI, the issue is that the delegated authentication mechanism we use for jira.secondlife.com (so you can log in with your SL credentials) isn't supported by Jira's XML RPC mechanism. We're attempting to get that supported, but it requires new code, not just flipping a switch. Harold Brown wrote: > Yep... I use it read only also. > > On 7/11/07, *Dale Glass* > wrote: > > On Wed, Jul 11, 2007 at 02:23:41PM -0500, Argent Stonecutter wrote: > > kerunix Flan: > > > > http://www.atlassian.com/software/views/opensource-license-request.jsp > > >atlassian offer licence to opensource project. I give it a try ;) > > > > Speaking of which, has anyone had any luck with the Atlassian > client > > software? > > > > There should be a copy of the open source client license they > sent me > > for the open source client project on the wiki, but I can't pull the > > wiki up right now to check. > > I like it a lot, makes it really a lot less painful. > > Except, logging in doesn't work, so it's readonly. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Wed Jul 11 13:59:56 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 14:00:17 2007 Subject: [sldev] 1.18.0.6 Message-ID: <469544CC.2060009@blueflash.cc> I'm getting more gray textures than there should be in one location and activity the texture console (ctrl+shift+3) definitely looks a lot different than before (dunno if the pipeline was changed). Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dale at daleglass.net Wed Jul 11 14:07:42 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 11 14:07:47 2007 Subject: [sldev] https very slow. In-Reply-To: <1184187061.11166.1.camel@localhost> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> <46951B0A.4030406@gmail.com> <20070711180812.GB14142@bruno.sbruno> <1184187061.11166.1.camel@localhost> Message-ID: <20070711210741.GD14142@bruno.sbruno> On Wed, Jul 11, 2007 at 03:51:01PM -0500, Callum Lerwick wrote: > On Wed, 2007-07-11 at 20:08 +0200, Dale Glass wrote: > > On Wed, Jul 11, 2007 at 02:01:46PM -0400, Jason Giglio wrote: > > > RC4 would be a more relevant benchmark. RC4 is likely an order of > > > magnitude faster than aes-256. > > Ok, rc4 then: > > > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > > rc4 265796.22k 334144.99k 354972.96k 366394.94k 363973.29k > > > > RC4 is less than perfect though: > > http://en.wikipedia.org/wiki/RC4#Fluhrer.2C_Mantin_and_Shamir_attack > > Blowfish? About the same performance as for AES: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes blowfish cbc 93727.58k 99827.99k 101858.99k 102497.96k 103030.15k BTW, benchmarks are done with "openssl speed" > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070711/59bfcd06/attachment.pgp From able.whitman at gmail.com Wed Jul 11 14:08:45 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 11 14:08:47 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <469544CC.2060009@blueflash.cc> References: <469544CC.2060009@blueflash.cc> Message-ID: <7b3a84fb0707111408w217bb0dcnc0f90fc05efa722d@mail.gmail.com> I'm seeing a very similar behavior, where it seems (subjectively, at least) that it takes longer for the 1.18.0.6 viewer to download the textures for objects in prim-heavy locations. In particular, objects nearer to the agent seem to take longer to render without default grey than before. Once the 1.18.0.6 source is available, I'm interested in looking at a diff between it an 1.17 to see what (if any) pipeline changes were made. --Able On 7/11/07, Nicholaz Beresford wrote: > > > I'm getting more gray textures than there should be > in one location and activity the texture console > (ctrl+shift+3) definitely looks a lot different > than before (dunno if the pipeline was changed). > > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > 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/20070711/aa0fa5cf/attachment.htm From nicholaz at blueflash.cc Wed Jul 11 14:11:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 14:12:06 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <7b3a84fb0707111408w217bb0dcnc0f90fc05efa722d@mail.gmail.com> References: <469544CC.2060009@blueflash.cc> <7b3a84fb0707111408w217bb0dcnc0f90fc05efa722d@mail.gmail.com> Message-ID: <46954799.6080306@blueflash.cc> > I'm seeing a very similar behavior, where it seems (subjectively, at > least) that it takes longer for the 1.18.0.6 viewer to > download the textures for objects in prim-heavy locations. In > particular, objects nearer to the agent seem to take longer to render > without default grey than before. One user on my blog says he's just getting the small blurry ones. And I think I saw unusually high decode priorities in the texture console. > Once the 1.18.0.6 source is available, I'm interested > in looking at a diff between it an 1.17 to see what (if any) pipeline > changes were made. Hmm, would be worth checking with 1.18.4 ... not that the release notes said anything (or not that I already was looking). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From able.whitman at gmail.com Wed Jul 11 14:22:52 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 11 14:22:54 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <46954799.6080306@blueflash.cc> References: <469544CC.2060009@blueflash.cc> <7b3a84fb0707111408w217bb0dcnc0f90fc05efa722d@mail.gmail.com> <46954799.6080306@blueflash.cc> Message-ID: <7b3a84fb0707111422m250e748an33a78067d14b56ce@mail.gmail.com> > > One user on my blog says he's just getting the small blurry ones. And > I think I saw unusually high decode priorities in the texture console. I'm getting the full-rez textures, eventually. I'm not sure that the full textures are taking longer to load, but it does seem that the initial blurry textures (is there a proper name for these?) take longer to appear, so objects have the default textures for longer. > Once the 1.18.0.6 source is available, I'm interested > > in looking at a diff between it an 1.17 to see what (if any) pipeline > > changes were made. > > Hmm, would be worth checking with 1.18.4 ... not that the release notes > said anything (or not that I already was looking). This raises an interesting question: would it be reasonable to ask for the release notes to include the internal LL issues that are addressed in each release, in addition to the public JIRA issues? I assume that every change that is made to the viewer has an associated issue, whether it be a public or internal one. --Able Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070711/ac5c5d19/attachment.htm From monkowsk at watson.ibm.com Wed Jul 11 14:27:31 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Jul 11 14:26:57 2007 Subject: [sldev] Log question In-Reply-To: <2d8148cd0707110429y54ccce10i4e39bf2ba92d384e@mail.gmail.com> References: <2d8148cd0707102000u24ed73bam6027a551faa1e39f@mail.gmail.com> <46944D01.5050709@gmail.com> <2d8148cd0707110429y54ccce10i4e39bf2ba92d384e@mail.gmail.com> Message-ID: <46954B43.8030702@watson.ibm.com> 192.168.0.1 is a special address used by home routers. Search Google for details. You probably had something configured wrong. Mike Dereck Wonnacott wrote: > Wewt! I got in, crashed within 10 seconds, but thats progress! > > well well well, I'm not sure exaclty why, but I changed my DNS servers > to OpenDNS, and I can log in JUST FINE! > > Is this a bug, or some misconfiguration on my part, I dunno~? > > ~Dereck > > [https://jira.secondlife.com/browse/VWR-1606] > > > On 7/10/07, *Tateru Nino* > wrote: > > Port 53. That's a DNS response. Why would a DNS packet be being passed > to the message decoder? > > Dereck Wonnacott wrote: > > Hi all! > > > > I've got the VWR compiled with all x64 libs and not including FMOD on > > Ubuntu 7.04 AMD64 today. YAY! When I attempt to connect with > official > > or my compiled VWR, I find this in the console: > > > > 2007-07-11T01:39:42Z INFO: idle_startup: Verifying message > template... > > 2007-07-11T01:39:42Z WARNING: decodeTemplate: Message #0 received > but > > not registered! > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Dump > > from:192.168.0.1:53 > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Size:230 > > ...?useless? dump of packet... > > 2007-07-11T01:39:42Z WARNING: checkMessages: Packet from invalid > > circuit 192.168.0.1:53 > > > > > > > Then the VRW goes bye bye. I dont know what that that stuff above > > means or where to look to fix it. Sorry if it is obvious, I'm still > > new to this. > > > > I'm keeping track of it here: > https://jira.secondlife.com/browse/VWR-1606 > > > > > > ~Dereck > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From matthew.dowd at hotmail.co.uk Wed Jul 11 14:29:45 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 11 14:29:47 2007 Subject: [sldev] https very slow. Message-ID: > I don't think I've seen much more than 300KB/s normally, so that's about > 3ms. For the viewer it's really insignificant. The way https (and other PKI based encyption works), is that during the initial connect fairly compute intensive assymetric algorithms are used to securely exchange a randomly generated passphrase between client and server. Once this has been done, the actual data is encrypted with the pass phrase using a symmetric algorithm - a bit more sophisticate then XORing with the passphrase but more or less along the same principle and more or less with the same rather low impact on performance. So the real impact is if you are creating lots of small httsp connections. If you are creating a few https connections and sending repeated data down those, the impact is pretty negligible and other bottlenecks would be more likely to be the cause of performance issues. > Of course it's a lot more significant for the sim, but the average > amount of data being transferred should be well below 300 KB/s per > agent. The real impact on the server would be when there are mass simultaneous log ons creating https connections e.g. after grid downtime. That said, most of the server class network cards have hardware support for encryption protocols so the server impact could be mitigated by that. Matthew _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From matthew.dowd at hotmail.co.uk Wed Jul 11 14:30:51 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 11 14:30:52 2007 Subject: [sldev] 1.18.0.6 Message-ID: > Once the 1.18.0.6 source is available, I'm interested in looking at a diff between it an 1.17 to see what (if any) pipeline changes were made. What's the usual lead time between a release and the source going up? Matthew _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From able.whitman at gmail.com Wed Jul 11 14:42:55 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 11 14:42:58 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: References: Message-ID: <7b3a84fb0707111442g21e8604cs583950b483c97a1b@mail.gmail.com> The turnaround has been pretty quick, lately. I'm hoping to see the 1.18.0.6source available today sometime, if the stars align properly :) On 7/11/07, Matthew Dowd wrote: > > > > Once the 1.18.0.6 source is available, I'm interested in looking at a > diff between it an 1.17 to see what (if any) pipeline changes were made. > > What's the usual lead time between a release and the source going up? > > Matthew > _________________________________________________________________ > Celeb spotting ? Play CelebMashup and win cool prizes > https://www.celebmashup.com/index2.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070711/a993f212/attachment-0001.htm From nicholaz at blueflash.cc Wed Jul 11 14:47:41 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 14:47:56 2007 Subject: [sldev] https very slow. In-Reply-To: References: Message-ID: <46954FFD.9080406@blueflash.cc> > So the real impact is if you are creating lots of small httsp connections. I think that is what I saw during the libcurl leak. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From odysseus654 at gmail.com Wed Jul 11 14:48:42 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Jul 11 14:48:45 2007 Subject: [sldev] Log question In-Reply-To: <46954B43.8030702@watson.ibm.com> References: <2d8148cd0707102000u24ed73bam6027a551faa1e39f@mail.gmail.com> <46944D01.5050709@gmail.com> <2d8148cd0707110429y54ccce10i4e39bf2ba92d384e@mail.gmail.com> <46954B43.8030702@watson.ibm.com> Message-ID: <1674f6c70707111448u71b0125p91791f8011ec15a4@mail.gmail.com> A quick warning, some DSL modems (i.e. Adaptec) will do a transparent intercept of all packets it things are DNS packets and then process them locally (giving them an IP address of 192.168.x.1). Not sure how your router would be interpreting outgoing packets as destined for a DNS server though. On 7/11/07, Mike Monkowski wrote: > > 192.168.0.1 is a special address used by home routers. Search Google > for details. You probably had something configured wrong. > > Mike > > > Dereck Wonnacott wrote: > > Wewt! I got in, crashed within 10 seconds, but thats progress! > > > > well well well, I'm not sure exaclty why, but I changed my DNS servers > > to OpenDNS, and I can log in JUST FINE! > > > > Is this a bug, or some misconfiguration on my part, I dunno~? > > > > ~Dereck > > > > [https://jira.secondlife.com/browse/VWR-1606] > > > > > > On 7/10/07, *Tateru Nino* > > wrote: > > > > Port 53. That's a DNS response. Why would a DNS packet be being > passed > > to the message decoder? > > > > Dereck Wonnacott wrote: > > > Hi all! > > > > > > I've got the VWR compiled with all x64 libs and not including > FMOD on > > > Ubuntu 7.04 AMD64 today. YAY! When I attempt to connect with > > official > > > or my compiled VWR, I find this in the console: > > > > > > 2007-07-11T01:39:42Z INFO: idle_startup: Verifying message > > template... > > > 2007-07-11T01:39:42Z WARNING: decodeTemplate: Message #0 received > > but > > > not registered! > > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Dump > > > from:192.168.0.1:53 < > http://192.168.0.1:53> > > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Size:230 > > > ...?useless? dump of packet... > > > 2007-07-11T01:39:42Z WARNING: checkMessages: Packet from invalid > > > circuit 192.168.0.1:53 > > > > > > > > > > > Then the VRW goes bye bye. I dont know what that that stuff above > > > means or where to look to fix it. Sorry if it is obvious, I'm > still > > > new to this. > > > > > > I'm keeping track of it here: > > https://jira.secondlife.com/browse/VWR-1606 > > > > > > > > > ~Dereck > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > 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/20070711/c4473473/attachment.htm From nicholaz at blueflash.cc Wed Jul 11 14:49:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 14:49:34 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: References: Message-ID: <46955062.2090809@blueflash.cc> > What's the usual lead time between a release and the source going up? If the last releases are a measure, it should already be here. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Wed Jul 11 14:55:21 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 14:55:29 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <7b3a84fb0707111422m250e748an33a78067d14b56ce@mail.gmail.com> References: <469544CC.2060009@blueflash.cc> <7b3a84fb0707111408w217bb0dcnc0f90fc05efa722d@mail.gmail.com> <46954799.6080306@blueflash.cc> <7b3a84fb0707111422m250e748an33a78067d14b56ce@mail.gmail.com> Message-ID: <469551C9.9040000@blueflash.cc> I'm getting lots of grays in new locations and asked people, they're seeing the same. Nick ---- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From blakar at gmail.com Wed Jul 11 15:29:25 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jul 11 15:29:28 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <469551C9.9040000@blueflash.cc> References: <469544CC.2060009@blueflash.cc> <7b3a84fb0707111408w217bb0dcnc0f90fc05efa722d@mail.gmail.com> <46954799.6080306@blueflash.cc> <7b3a84fb0707111422m250e748an33a78067d14b56ce@mail.gmail.com> <469551C9.9040000@blueflash.cc> Message-ID: <7992d0d60707111529l4041ffcaq82e987d9a5ebafae@mail.gmail.com> Be careful. When the grid has just went up it's not the best time to compare to day to day activity. All the parts of the grid also need to refresh their caches and as such they may not perform as they do on an average day. Might as well work just like before within a few hours when the grid and the clients are back to normal. Dirk aka Blakar Ogre On 7/11/07, Nicholaz Beresford wrote: > > I'm getting lots of grays in new locations and > asked people, they're seeing the same. > > Nick > ---- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From able.whitman at gmail.com Wed Jul 11 15:47:53 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 11 15:47:56 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <7b3a84fb0707111442g21e8604cs583950b483c97a1b@mail.gmail.com> References: <7b3a84fb0707111442g21e8604cs583950b483c97a1b@mail.gmail.com> Message-ID: <7b3a84fb0707111547p450b30c9ne4ea983b6f007bf9@mail.gmail.com> In fact the source is out now: http://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.6 On 7/11/07, Able Whitman wrote: > > The turnaround has been pretty quick, lately. I'm hoping to see the > 1.18.0.6 source available today sometime, if the stars align properly :) > > On 7/11/07, Matthew Dowd wrote: > > > > > > > Once the 1.18.0.6 source is available, I'm interested in looking at a > > diff between it an 1.17 to see what (if any) pipeline changes were made. > > > > > > What's the usual lead time between a release and the source going up? > > > > Matthew > > _________________________________________________________________ > > Celeb spotting ? Play CelebMashup and win cool prizes > > https://www.celebmashup.com/index2.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070711/d9399ffa/attachment.htm From nicholaz at blueflash.cc Wed Jul 11 15:52:15 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 15:52:24 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <7b3a84fb0707111547p450b30c9ne4ea983b6f007bf9@mail.gmail.com> References: <7b3a84fb0707111442g21e8604cs583950b483c97a1b@mail.gmail.com> <7b3a84fb0707111547p450b30c9ne4ea983b6f007bf9@mail.gmail.com> Message-ID: <46955F1F.2050200@blueflash.cc> Dirk aka Blakar Ogre: > Be careful. When the grid has just went up it's not the best time to > compare to day to day activity. Well, I hope you're right ... it's getting a bit better already (I usually don't logon directly after ape day). Able Whitman wrote: > In fact the source is out now: > http://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.6 Oh, kewl! Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From kelly at lindenlab.com Wed Jul 11 16:06:59 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Jul 11 16:07:03 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <46955F1F.2050200@blueflash.cc> References: <7b3a84fb0707111442g21e8604cs583950b483c97a1b@mail.gmail.com> <7b3a84fb0707111547p450b30c9ne4ea983b6f007bf9@mail.gmail.com> <46955F1F.2050200@blueflash.cc> Message-ID: <46956293.1080408@lindenlab.com> Nicholaz Beresford wrote: > > Dirk aka Blakar Ogre: > > Be careful. When the grid has just went up it's not the best time to > > compare to day to day activity. > > Well, I hope you're right ... it's getting a bit better already (I > usually don't logon directly after ape day). > > > Able Whitman wrote: >> In fact the source is out now: >> http://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.6 > > Oh, kewl! > > > Nick > --- It looks like we blew through a bandwidth limit on one of our switches to the asset servers. We rebalanced some so things should be 'better' now. However we are still investigating *why* it happened, and asset requests do still seem higher than normal. It is unlikely the viewer is actually to blame, the problem is probably somewhere in the servers, either a code change or configuration change (message lib did include some configuration changes), or it is possible the asset server maintenance work flushed or invalidated some existing caches. I wish we had an open source sim already so I could throw it at you guys ;) (no, don't reply to that here please). Until then ... If you guys can prove me wrong I'd be happy to hear it - a new viewer is far easier to release than rolling out a new sim if needed. :p - Kelly From soft at lindenlab.com Wed Jul 11 16:10:26 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jul 11 16:10:28 2007 Subject: [sldev] Open Source Meeting Agenda - Thursday 2pm Message-ID: <9e6e5c9e0707111610h49e4d852jaf8bd9eb464a2cdb@mail.gmail.com> A reminder that Thursdays, we hold open source office hours at 2pm in Grasmere, with Rob, Liana and myself in attendance. Last week, things were a bit chaotic, to put it gently! Let's try and improve the focus. If you have a topic you'd like to discuss, please make a note on the agenda page in the wiki: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda We can plan to go back to last week's free-form chaos after covering anything on the agenda. :) From nicholaz at blueflash.cc Wed Jul 11 16:37:15 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 11 16:37:25 2007 Subject: [sldev] 1.18.0.6 In-Reply-To: <46956293.1080408@lindenlab.com> References: <7b3a84fb0707111442g21e8604cs583950b483c97a1b@mail.gmail.com> <7b3a84fb0707111547p450b30c9ne4ea983b6f007bf9@mail.gmail.com> <46955F1F.2050200@blueflash.cc> <46956293.1080408@lindenlab.com> Message-ID: <469569AB.305@blueflash.cc> Kelly Linden wrote: > Until then ... If you guys can prove me wrong I'd be happy to hear it - > a new viewer is far easier to release than rolling out a new sim if > needed. :p At the moment it looks like both are doing fine ... Kudos folks! (keeping fingers crossed) Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From able.whitman at gmail.com Wed Jul 11 17:24:46 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 11 17:24:48 2007 Subject: [sldev] 1.18.0.6 uses an older version of the Boost library? Message-ID: <7b3a84fb0707111724l2319dff6kb00a7761d5bbd063@mail.gmail.com> I'm looking at a diff I made between the 1.17.3.0 and the 1.18.0.6 source trees, and I'm seeing a bunch of blocks that look like this: --- slviewer-src-1.17.3.0\linden\/libraries/include/boost/mpl/assert.hpp 2007-07-06 11:46:14.000000000 -0400 +++ slviewer-src-1.18.0.6\linden\/libraries/include/boost/mpl/assert.hpp 2007-07-11 15:19:50.000000000 -0400 @@ -11,8 +11,8 @@ // See http://www.boost.org/libs/mpl for documentation. // $Source$ -// $Date: 2007-03-22 15:03:42 -0700 (Thu, 22 Mar 2007) $ -// $Revision: 59599 $ +// $Date: 2006-02-24 13:34:57 -0800 (Fri, 24 Feb 2006) $ +// $Revision: 45264 $ #include #include I verified that the revision 45264 files are the ones that came from the 1.18.0.6 win32 libraries archive I downloaded. Did 1.18 revert to an earlier version of the Boost libraries? Or am I imagining things? --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070711/ccbfa110/attachment.htm From soft at lindenlab.com Wed Jul 11 18:02:52 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jul 11 18:02:55 2007 Subject: [sldev] 1.18.0.6 uses an older version of the Boost library? In-Reply-To: <7b3a84fb0707111724l2319dff6kb00a7761d5bbd063@mail.gmail.com> References: <7b3a84fb0707111724l2319dff6kb00a7761d5bbd063@mail.gmail.com> Message-ID: <9e6e5c9e0707111802va0c1ef5p1dd13d9c33f00f7a@mail.gmail.com> Looking at the changelists internally, the "newer" version was actually a reversion to the other version. (A developer had upgraded boost, only to find that the Windows upgrade didn't play well with Linux and OS X.) I think you're just looking at our own programmatically generated headers, which are reporting the base version of that file for that merge. If you do a compare on the full boost directories, try filtering out those header lines with grep and see if there's anything left over. On 7/11/07, Able Whitman wrote: > I'm looking at a diff I made between the 1.17.3.0 and the 1.18.0.6 source > trees, and I'm seeing a bunch of blocks that look like this: > > --- > slviewer-src-1.17.3.0\linden\/libraries/include/boost/mpl/assert.hpp > 2007-07-06 11:46:14.000000000 -0400 > +++ > slviewer-src-1.18.0.6\linden\/libraries/include/boost/mpl/assert.hpp > 2007-07-11 15:19:50.000000000 -0400 > @@ -11,8 +11,8 @@ > // See http://www.boost.org/libs/mpl for documentation. > > // $Source$ > -// $Date: 2007-03-22 15:03:42 -0700 (Thu, 22 Mar 2007) $ > -// $Revision: 59599 $ > +// $Date: 2006-02-24 13:34:57 -0800 (Fri, 24 Feb 2006) $ > +// $Revision: 45264 $ > > #include > #include > > I verified that the revision 45264 files are the ones that came from the > 1.18.0.6 win32 libraries archive I downloaded. Did 1.18 revert to an earlier > version of the Boost libraries? Or am I imagining things? > > --Able From able.whitman at gmail.com Wed Jul 11 18:27:44 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 11 18:27:46 2007 Subject: [sldev] 1.18.0.6 uses an older version of the Boost library? In-Reply-To: <7b3a84fb0707111827v43063814r81cc4c1ae212c694@mail.gmail.com> References: <7b3a84fb0707111724l2319dff6kb00a7761d5bbd063@mail.gmail.com> <9e6e5c9e0707111802va0c1ef5p1dd13d9c33f00f7a@mail.gmail.com> <7b3a84fb0707111827v43063814r81cc4c1ae212c694@mail.gmail.com> Message-ID: <7b3a84fb0707111827l82aff8dy6d432a8ef6ce3216@mail.gmail.com> Ahh, okay. I looked at my full diff and there were lots of changes found in the boost files, but when I took a closer look, it turned out that the diff was basically noting that large blocks in each file were being replaced with an identical block (save for the headers). When I re-diffed with the "-w" option, the only thing I was left with were the version numbers in the headers. I guess somehow the line endings for my 1.17 files are different than the ones i have for 1.18, although I'm not sure if this is an artifact of VC++ 2005, or something else. Thanks, Soft! On 7/11/07, Soft Linden wrote: > > Looking at the changelists internally, the "newer" version was > actually a reversion to the other version. (A developer had upgraded > boost, only to find that the Windows upgrade didn't play well with > Linux and OS X.) I think you're just looking at our own > programmatically generated headers, which are reporting the base > version of that file for that merge. > > If you do a compare on the full boost directories, try filtering out > those header lines with grep and see if there's anything left over. > > > On 7/11/07, Able Whitman wrote: > > I'm looking at a diff I made between the 1.17.3.0 and the 1.18.0.6source > > trees, and I'm seeing a bunch of blocks that look like this: > > > > --- > > slviewer-src-1.17.3.0\linden\/libraries/include/boost/mpl/assert.hpp > > 2007-07-06 11:46:14.000000000 -0400 > > +++ > > slviewer-src-1.18.0.6\linden\/libraries/include/boost/mpl/assert.hpp > > 2007-07-11 15:19:50.000000000 -0400 > > @@ -11,8 +11,8 @@ > > // See http://www.boost.org/libs/mpl for documentation. > > > > // $Source$ > > -// $Date: 2007-03-22 15:03:42 -0700 (Thu, 22 Mar 2007) $ > > -// $Revision: 59599 $ > > +// $Date: 2006-02-24 13:34:57 -0800 (Fri, 24 Feb 2006) $ > > +// $Revision: 45264 $ > > > > #include > > #include > > > > I verified that the revision 45264 files are the ones that came from the > > > 1.18.0.6 win32 libraries archive I downloaded. Did 1.18 revert to an > earlier > > version of the Boost libraries? Or am I imagining things? > > > > --Able > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070711/a2c13ec0/attachment.htm From dale at daleglass.net Wed Jul 11 19:10:37 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 11 19:10:43 2007 Subject: [sldev] Installer source Message-ID: <20070712021037.GG14142@bruno.sbruno> Ok, in case anybody wants it, this is the installer I've made: A bit messy still, and could use some cleanup, but maybe somebody will find it useful. http://daleglass.net/installer.zip it goes in indra/newview/installers/ viewer_manifest.py needs to be run first -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/3d315e95/attachment.pgp From kerdezixe at gmail.com Wed Jul 11 23:04:52 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 23:04:54 2007 Subject: [sldev] https very slow. In-Reply-To: <46954FFD.9080406@blueflash.cc> References: <46954FFD.9080406@blueflash.cc> Message-ID: <8a1bfe660707112304l1396bc84w3d6375dfedf37caa@mail.gmail.com> Now i use jira in http, and it's much, much faster than https ! -- kerunix Flan From kerdezixe at gmail.com Wed Jul 11 23:27:49 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jul 11 23:27:51 2007 Subject: [sldev] Re: "bogus bug" triage - MISC In-Reply-To: <46952A26.3000403@lindenlab.com> References: <8a1bfe660707102341qb97773bkedb8df3619dfe33c@mail.gmail.com> <8a1bfe660707110117p4670e4dcnf3350b9ec5f9d11d@mail.gmail.com> <8a1bfe660707111107s192ee2aey7a628e57c39abffe@mail.gmail.com> <46952A26.3000403@lindenlab.com> Message-ID: <8a1bfe660707112327v64da3a5brd01d063ec9beebcf@mail.gmail.com> On 7/11/07, Rob Lanphier wrote: > Make sure you mark things as "Resolved" rather than "Closed". General > JIRA etiquette (or general bug tracker for that matter) is that the > reporter is the person who moves an issue from "resolved" to "closed" as > acknowledgment that they agree with the resolution. > > More on this topic here: > https://wiki.secondlife.com/wiki/Issue_tracker woopsy ... thx ! i will :) Also ... - Added "Meta-issue : Legal and TOS" http://jira.secondlife.com/browse/MISC-412 - linked to "Meta-Issue: Meta-Issue Organization" MISC-398 - linked to "New Jira Project - Policy" WEB-71 This meta-issue thingy is a great idea. I'm planning to work at least 1h per day on the JIRA. if you think i'm flooding the list please tell me, on sldev or in private mail. thx :) JIRA is the best bugreport tool i ever seen. -- kerunix Flan From gigstaggart at gmail.com Thu Jul 12 00:15:51 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 12 00:16:20 2007 Subject: [sldev] releasefordownload - linux Message-ID: <4695D527.6090808@gmail.com> Is is just something I'm doing, or does releasefordownload no longer properly make a tarball? I had to run cp ../linden/indra/lib_releasefordownload_client/i686-linux/ lib/ to get the libraries that it neglected to tar up apparently. I don't see anything on the wiki about this issue, and I had to do it last time too. -Jason From kerdezixe at gmail.com Thu Jul 12 00:33:17 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jul 12 00:33:20 2007 Subject: [sldev] https very slow. In-Reply-To: <8a1bfe660707112304l1396bc84w3d6375dfedf37caa@mail.gmail.com> References: <46954FFD.9080406@blueflash.cc> <8a1bfe660707112304l1396bc84w3d6375dfedf37caa@mail.gmail.com> Message-ID: <8a1bfe660707120033n6c606676kfc87bb3e554c0f55@mail.gmail.com> On 7/12/07, Laurent Laborde wrote: > Now i use jira in http, and it's much, much faster than https ! All internal JIRA link in comments are "https" while some other link point correctly to "http". see : http://jira.secondlife.com/browse/WEB-225 Try both link : - in issue links (http) - in comments. (https) http is much much faster than https. Enough said. I won't flood anymore about this issue :) -- kerunix Flan From gigstaggart at gmail.com Thu Jul 12 01:28:41 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 12 01:29:11 2007 Subject: [sldev] Japanese SDL support. Message-ID: <4695E639.2050803@gmail.com> http://emasaka.blog65.fc2.com/blog-entry-242.html I have been told by a Japanese user that all Japanese linux users must apply this patch to get usable input. I can't read or write japanese, but can this patch be merged into the distribution? I guess the author will need to have a contribution agreement if they don't already. Is this already in Jira and I missed it? -Jason From seg at haxxed.com Thu Jul 12 01:53:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 12 01:52:39 2007 Subject: [sldev] Japanese SDL support. In-Reply-To: <4695E639.2050803@gmail.com> References: <4695E639.2050803@gmail.com> Message-ID: <1184230391.3313.2.camel@localhost> On Thu, 2007-07-12 at 04:28 -0400, Jason Giglio wrote: > http://emasaka.blog65.fc2.com/blog-entry-242.html > > I have been told by a Japanese user that all Japanese linux users must > apply this patch to get usable input. > > I can't read or write japanese, but can this patch be merged into the > distribution? I guess the author will need to have a contribution > agreement if they don't already. > > Is this already in Jira and I missed it? This belongs upstream at the SDL project. Is there a reason its not? Language barrier? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/79f13a9b/attachment.pgp From matthew.dowd at hotmail.co.uk Thu Jul 12 02:15:36 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 12 02:15:38 2007 Subject: [sldev] Help with send_places_query Message-ID: I'm having trouble getting my head around the send_places_query. The following is used to populate the Land Holdings floater: send_places_query(query_id, LLUUID::null, "", DFQ_AGENT_OWNED, LLParcel::C_ANY, ""); And this to populate group land holdings send_places_query(mGroupID, mTransID, "", DFQ_GROUP_OWNED, LLParcel::C_ANY, "") So I thought the following would list all parcels in a named sim send_places_query(mGroupID, mTransID, "", 0, LLParcel::C_ANY, mSimName) But for some sims I get nothing back, and others I get a partial list. Any hints? For those interested, what I'm working towards is a new panel in Estate tools for displaying details of all the parcels on an owned island (name, owner, area, prims etc.), motivated by wanting to keep an island wide view of prim usage for islands where the prim bonus is something other than 1. Matthew _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From fparnigoni at videosoft.biz Thu Jul 12 03:01:52 2007 From: fparnigoni at videosoft.biz (Fulvio Parnigoni) Date: Thu Jul 12 03:02:01 2007 Subject: [sldev] Linker error building viewer from 1.18.0.4 sources under VC8 Message-ID: <4695FC10.2010407@videosoft.biz> Hi all, this is my configuration: - Visual C++ 2005 Express Edition - I read the page https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 - viewer source code 2.1 ver beta 1.18.0.4 - pre-built solution vc8_1_18_V5.zip (JIRA/Feep Larsson) - Nicholaz Beresford patch - project: ReleaseForDownload the compiler works ok the linker no, there are two warnings and many hundreds of errors, the two warnings: module llmath: llrect.obj: warning LNK4221: no public symbols found; archive member will be inaccessible module llmedia: llmediaimplquiktime.obj:warning LNK4221: no public symbols found; archive member will be inaccessible I have tried also with: - viewer source code 1.2 ver 1.17.2.0 - pre-built solution vc8_1_17_2_V4.zip but the result is the same. Any ideas ? Any FAQ ? Thank you Fulvio this is a little block of errors: llviewermenu.obj : error LNK2001: unresolved external symbol "public: int __thiscall LLPermissions::allowOperationBy(unsigned int,class LLUUID const &,class LLUUID const &)const " (?allowOperationBy@LLPermissions@@QBEHIABVLLUUID@@0@Z) llviewerobject.obj : error LNK2001: unresolved external symbol "public: int __thiscall LLPermissions::allowOperationBy(unsigned int,class LLUUID const &,class LLUUID const &)const " (?allowOperationBy@LLPermissions@@QBEHIABVLLUUID@@0@Z) . . pipeline.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl LLError::Log::shouldLog(class LLError::CallSite &)" (?shouldLog@Log@LLError@@SA_NAAVCallSite@2@@Z) viewer.obj : error LNK2001: unresolved external symbol "public: static bool __cdecl LLError::Log::shouldLog(class LLError::CallSite &)" (?shouldLog@Log@LLError@@SA_NAAVCallSite@2@@Z) . . llvopartgroup.obj : error LNK2001: unresolved external symbol "public: static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) llwearable.obj : error LNK2001: unresolved external symbol "public: static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) llwearablelist.obj : error LNK2001: unresolved external symbol "public: static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) llworldmapview.obj : error LNK2001: unresolved external symbol "public: static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) . . llhudobject.obj : error LNK2001: unresolved external symbol "public: int __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) llhudtext.obj : error LNK2001: unresolved external symbol "public: int __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) llhudview.obj : error LNK2001: unresolved external symbol "public: int __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) . . llvoavatar.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) llvosky.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) . . llviewerparceloverlay.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) llviewerpartsim.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) llviewertexteditor.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) . . llgesturemgr.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::nextBlockFast(char const *)" (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) llgivemoney.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::nextBlockFast(char const *)" (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) llgroupmgr.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::nextBlockFast(char const *)" (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) llhudmanager.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::nextBlockFast(char const *)" (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) . . lleventinfo.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::getU32(char const *,char const *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) llfloaterregioninfo.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::getU32(char const *,char const *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) llfloaterreporter.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::getU32(char const *,char const *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) llviewerparcelmgr.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::getBOOL(char const *,char const *,int &,int)" (?getBOOL@LLMessageSystem@@QAEXPBD0AAHH@Z) llviewerregion.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLMessageSystem::getBOOL(char const *,char const *,int &,int)" (?getBOOL@LLMessageSystem@@QAEXPBD0AAHH@Z) . . llagent.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) llassetuploadresponders.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) llcompilequeue.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) llinventorymodel.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) llwearablelist.obj : error LNK2001: unresolved external symbol "public: class LLPermissions const & __thiscall LLInventoryItem::getPermissions(void)const " (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) llviewerobject.obj : error LNK2001: unresolved external symbol "public: class LLPermissions const & __thiscall LLInventoryItem::getPermissions(void)const " (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) llviewertexteditor.obj : error LNK2001: unresolved external symbol "public: class LLPermissions const & __thiscall LLInventoryItem::getPermissions(void)const " (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) . . llfloatercustomize.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLButton::setToggleState(int)" (?setToggleState@LLButton@@QAEXH@Z) llagent.obj : error LNK2019: riferimento al unresolved external symbol "public: void __thiscall LLCoordFrame::yaw(float)" (?yaw@LLCoordFrame@@QAEXM@Z) nella funzione "public: void __thiscall LLAgent::updateLookAt(int,int)" (?updateLookAt@LLAgent@@QAEXHH@Z) pipeline.obj : error LNK2001: unresolved external symbol "public: float __thiscall LLControlGroup::getF32(class LLStringBase const &)" (?getF32@LLControlGroup@@QAEMABV?$LLStringBase@D@@@Z) . . From nicholaz at blueflash.cc Thu Jul 12 03:34:29 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 12 03:34:45 2007 Subject: [sldev] Linker error building viewer from 1.18.0.4 sources under VC8 In-Reply-To: <4695FC10.2010407@videosoft.biz> References: <4695FC10.2010407@videosoft.biz> Message-ID: <469603B5.7060309@blueflash.cc> Fulvio, I think there was a change in the code between 1.18.0.4 and 1.18.0.6 which affects the project files. I guess you will have to do the manual conversion of the projects files (or wait until someone posts them). The manual conversion isn't as bad as it looks. Yes, the instructions are large, but it will most likely not take longer than 10 or 15 minutes (and you have the vsprops file already from the prebuilt solutions). When you're done, you will have to open indra_complete.sln (not indra_complete_vc8.sln). Nick Fulvio Parnigoni wrote: > Hi all, > this is my configuration: > - Visual C++ 2005 Express Edition > - I read the page > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 > - viewer source code 2.1 ver beta 1.18.0.4 > - pre-built solution vc8_1_18_V5.zip (JIRA/Feep Larsson) > - Nicholaz Beresford patch > - project: ReleaseForDownload > > the compiler works ok the linker no, there are two warnings and many > hundreds > of errors, the two warnings: > module llmath: > llrect.obj: warning LNK4221: no public symbols found; archive member > will be > inaccessible > > module llmedia: > llmediaimplquiktime.obj:warning LNK4221: no public symbols found; archive > member will be inaccessible > > I have tried also with: > - viewer source code 1.2 ver 1.17.2.0 > - pre-built solution vc8_1_17_2_V4.zip > but the result is the same. > > Any ideas ? > Any FAQ ? > > Thank you > Fulvio > > this is a little block of errors: > > llviewermenu.obj : error LNK2001: unresolved external symbol "public: > int __thiscall LLPermissions::allowOperationBy(unsigned int,class LLUUID > const &,class LLUUID const &)const " > (?allowOperationBy@LLPermissions@@QBEHIABVLLUUID@@0@Z) > llviewerobject.obj : error LNK2001: unresolved external symbol "public: > int __thiscall LLPermissions::allowOperationBy(unsigned int,class LLUUID > const &,class LLUUID const &)const " > (?allowOperationBy@LLPermissions@@QBEHIABVLLUUID@@0@Z) > . > > . > pipeline.obj : error LNK2001: unresolved external symbol "public: static > bool __cdecl LLError::Log::shouldLog(class LLError::CallSite &)" > (?shouldLog@Log@LLError@@SA_NAAVCallSite@2@@Z) > viewer.obj : error LNK2001: unresolved external symbol "public: static > bool __cdecl LLError::Log::shouldLog(class LLError::CallSite &)" > (?shouldLog@Log@LLError@@SA_NAAVCallSite@2@@Z) > . > > . > llvopartgroup.obj : error LNK2001: unresolved external symbol "public: > static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) > llwearable.obj : error LNK2001: unresolved external symbol "public: > static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) > llwearablelist.obj : error LNK2001: unresolved external symbol "public: > static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) > llworldmapview.obj : error LNK2001: unresolved external symbol "public: > static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) > . > > . > llhudobject.obj : error LNK2001: unresolved external symbol "public: int > __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) > llhudtext.obj : error LNK2001: unresolved external symbol "public: int > __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) > llhudview.obj : error LNK2001: unresolved external symbol "public: int > __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) > . > > . > llvoavatar.obj : error LNK2001: unresolved external symbol "public: void > __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) > llvosky.obj : error LNK2001: unresolved external symbol "public: void > __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) > . > > . > llviewerparceloverlay.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLFrameTimer::reset(void)" > (?reset@LLFrameTimer@@QAEXXZ) > llviewerpartsim.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) > llviewertexteditor.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLFrameTimer::reset(void)" > (?reset@LLFrameTimer@@QAEXXZ) > . > > . > llgesturemgr.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLMessageSystem::nextBlockFast(char const *)" > (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) > llgivemoney.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLMessageSystem::nextBlockFast(char const *)" > (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) > llgroupmgr.obj : error LNK2001: unresolved external symbol "public: void > __thiscall LLMessageSystem::nextBlockFast(char const *)" > (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) > llhudmanager.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLMessageSystem::nextBlockFast(char const *)" > (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) > . > > . > lleventinfo.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLMessageSystem::getU32(char const *,char const > *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) > llfloaterregioninfo.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLMessageSystem::getU32(char const *,char const > *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) > llfloaterreporter.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLMessageSystem::getU32(char const *,char const > *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) > llviewerparcelmgr.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLMessageSystem::getBOOL(char const *,char > const *,int &,int)" (?getBOOL@LLMessageSystem@@QAEXPBD0AAHH@Z) > llviewerregion.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLMessageSystem::getBOOL(char const *,char const *,int > &,int)" (?getBOOL@LLMessageSystem@@QAEXPBD0AAHH@Z) > . > > . > llagent.obj : error LNK2001: unresolved external symbol "public: void > __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" > (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) > llassetuploadresponders.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID > const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) > llcompilequeue.obj : error LNK2001: unresolved external symbol "public: > void __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" > (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) > llinventorymodel.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID > const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) > llwearablelist.obj : error LNK2001: unresolved external symbol "public: > class LLPermissions const & __thiscall > LLInventoryItem::getPermissions(void)const " > (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) > llviewerobject.obj : error LNK2001: unresolved external symbol "public: > class LLPermissions const & __thiscall > LLInventoryItem::getPermissions(void)const " > (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) > llviewertexteditor.obj : error LNK2001: unresolved external symbol > "public: class LLPermissions const & __thiscall > LLInventoryItem::getPermissions(void)const " > (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) > . > > . > llfloatercustomize.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLButton::setToggleState(int)" > (?setToggleState@LLButton@@QAEXH@Z) > llagent.obj : error LNK2019: riferimento al unresolved external symbol > "public: void __thiscall LLCoordFrame::yaw(float)" > (?yaw@LLCoordFrame@@QAEXM@Z) nella funzione "public: void __thiscall > LLAgent::updateLookAt(int,int)" (?updateLookAt@LLAgent@@QAEXHH@Z) > pipeline.obj : error LNK2001: unresolved external symbol "public: float > __thiscall LLControlGroup::getF32(class LLStringBase const &)" > (?getF32@LLControlGroup@@QAEMABV?$LLStringBase@D@@@Z) > . > > . > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From sllists at boroon.dasgupta.ch Thu Jul 12 03:36:43 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu Jul 12 03:36:51 2007 Subject: [sldev] releasefordownload - linux In-Reply-To: <4695D527.6090808@gmail.com> References: <4695D527.6090808@gmail.com> Message-ID: <20070712123643.5t5h03w1s084kw04@datendelphin.net> Jason Giglio : > I had to run cp > ../linden/indra/lib_releasefordownload_client/i686-linux/ lib/ to get > the libraries that it neglected to tar up apparently. might be what Callum found two weeks ago: https://lists.secondlife.com/pipermail/sldev/2007-June/002727.html https://lists.secondlife.com/pipermail/sldev/2007-June/thread.html#2727 I don't think there's a Jira Issue about it, yet. So you might want to create one. Boroondas ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/9d84444e/attachment-0001.htm From dereck at gmail.com Thu Jul 12 04:31:22 2007 From: dereck at gmail.com (Dereck Wonnacott) Date: Thu Jul 12 04:31:24 2007 Subject: [sldev] Log question Message-ID: <2d8148cd0707120431g608ab5feqf393e37281813898@mail.gmail.com> Moving this thread to http://jira.secondlife.com/browse/VWR-1606 ~Dereck From: "Erik Anderson" A quick warning, some DSL modems (i.e. Adaptec) will do a transparent intercept of all packets it things are DNS packets and then process them locally (giving them an IP address of 192.168.x.1). Not sure how your router would be interpreting outgoing packets as destined for a DNS server though. On 7/11/07, Mike Monkowski wrote: > > 192.168.0.1 is a special address used by home routers. Search Google > for details. You probably had something configured wrong. > > Mike > > > Dereck Wonnacott wrote: > > Wewt! I got in, crashed within 10 seconds, but thats progress! > > > > well well well, I'm not sure exaclty why, but I changed my DNS servers > > to OpenDNS, and I can log in JUST FINE! > > > > Is this a bug, or some misconfiguration on my part, I dunno~? > > > > ~Dereck > > > > [https://jira.secondlife.com/browse/VWR-1606] > > > > > > On 7/10/07, *Tateru Nino* > > wrote: > > > > Port 53. That's a DNS response. Why would a DNS packet be being > passed > > to the message decoder? > > > > Dereck Wonnacott wrote: > > > Hi all! > > > > > > I've got the VWR compiled with all x64 libs and not including > FMOD on > > > Ubuntu 7.04 AMD64 today. YAY! When I attempt to connect with > > official > > > or my compiled VWR, I find this in the console: > > > > > > 2007-07-11T01:39:42Z INFO: idle_startup: Verifying message > > template... > > > 2007-07-11T01:39:42Z WARNING: decodeTemplate: Message #0 received > > but > > > not registered! > > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Dump > > > from:192.168.0.1:53 < > http://192.168.0.1:53> > > > 2007-07-11T01:39:42Z WARNING: dumpPacketToLog: Packet Size:230 > > > ...?useless? dump of packet... > > > 2007-07-11T01:39:42Z WARNING: checkMessages: Packet from invalid > > > circuit 192.168.0.1:53 > > > > > > > > > > > Then the VRW goes bye bye. I dont know what that that stuff above > > > means or where to look to fix it. Sorry if it is obvious, I'm still > > > new to this. > > > > > > I'm keeping track of it here: > > https://jira.secondlife.com/browse/VWR-1606 > > > > > > > > > ~Dereck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/3ae31e99/attachment.htm From mattk at electricsheepcompany.com Thu Jul 12 07:15:12 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Jul 12 07:14:53 2007 Subject: [sldev] Linker error building viewer from 1.18.0.4 sources under VC8 In-Reply-To: <469603B5.7060309@blueflash.cc> References: <4695FC10.2010407@videosoft.biz> <469603B5.7060309@blueflash.cc> Message-ID: <46963770.4060700@electricsheepcompany.com> I'll be going through the 1.18.0.6 compile today and uploading some new project files to https://jira.secondlife.com/browse/VWR-1151 when they're ready. I'll post to sldev when I'm done. -Matt Nicholaz Beresford wrote: > > Fulvio, > > I think there was a change in the code between 1.18.0.4 and > 1.18.0.6 which affects the project files. I guess you will > have to do the manual conversion of the projects files (or > wait until someone posts them). > > The manual conversion isn't as bad as it looks. Yes, the > instructions are large, but it will most likely not take > longer than 10 or 15 minutes (and you have the vsprops file > already from the prebuilt solutions). When you're done, > you will have to open indra_complete.sln (not > indra_complete_vc8.sln). > > > Nick > > > Fulvio Parnigoni wrote: >> Hi all, >> this is my configuration: >> - Visual C++ 2005 Express Edition >> - I read the page >> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >> - viewer source code 2.1 ver beta 1.18.0.4 >> - pre-built solution vc8_1_18_V5.zip (JIRA/Feep Larsson) >> - Nicholaz Beresford patch >> - project: ReleaseForDownload >> >> the compiler works ok the linker no, there are two warnings and many >> hundreds >> of errors, the two warnings: >> module llmath: >> llrect.obj: warning LNK4221: no public symbols found; archive member >> will be >> inaccessible >> >> module llmedia: >> llmediaimplquiktime.obj:warning LNK4221: no public symbols found; archive >> member will be inaccessible >> >> I have tried also with: >> - viewer source code 1.2 ver 1.17.2.0 >> - pre-built solution vc8_1_17_2_V4.zip >> but the result is the same. >> >> Any ideas ? >> Any FAQ ? >> >> Thank you >> Fulvio >> >> this is a little block of errors: >> >> llviewermenu.obj : error LNK2001: unresolved external symbol "public: >> int __thiscall LLPermissions::allowOperationBy(unsigned int,class LLUUID >> const &,class LLUUID const &)const " >> (?allowOperationBy@LLPermissions@@QBEHIABVLLUUID@@0@Z) >> llviewerobject.obj : error LNK2001: unresolved external symbol "public: >> int __thiscall LLPermissions::allowOperationBy(unsigned int,class LLUUID >> const &,class LLUUID const &)const " >> (?allowOperationBy@LLPermissions@@QBEHIABVLLUUID@@0@Z) >> . >> >> . >> pipeline.obj : error LNK2001: unresolved external symbol "public: static >> bool __cdecl LLError::Log::shouldLog(class LLError::CallSite &)" >> (?shouldLog@Log@LLError@@SA_NAAVCallSite@2@@Z) >> viewer.obj : error LNK2001: unresolved external symbol "public: static >> bool __cdecl LLError::Log::shouldLog(class LLError::CallSite &)" >> (?shouldLog@Log@LLError@@SA_NAAVCallSite@2@@Z) >> . >> >> . >> llvopartgroup.obj : error LNK2001: unresolved external symbol "public: >> static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) >> llwearable.obj : error LNK2001: unresolved external symbol "public: >> static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) >> llwearablelist.obj : error LNK2001: unresolved external symbol "public: >> static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) >> llworldmapview.obj : error LNK2001: unresolved external symbol "public: >> static class LLUUID const LLUUID::null" (?null@LLUUID@@2V1@B) >> . >> >> . >> llhudobject.obj : error LNK2001: unresolved external symbol "public: int >> __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) >> llhudtext.obj : error LNK2001: unresolved external symbol "public: int >> __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) >> llhudview.obj : error LNK2001: unresolved external symbol "public: int >> __thiscall LLUUID::set(char const *,int)" (?set@LLUUID@@QAEHPBDH@Z) >> . >> >> . >> llvoavatar.obj : error LNK2001: unresolved external symbol "public: void >> __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) >> llvosky.obj : error LNK2001: unresolved external symbol "public: void >> __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) >> . >> >> . >> llviewerparceloverlay.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLFrameTimer::reset(void)" >> (?reset@LLFrameTimer@@QAEXXZ) >> llviewerpartsim.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLFrameTimer::reset(void)" (?reset@LLFrameTimer@@QAEXXZ) >> llviewertexteditor.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLFrameTimer::reset(void)" >> (?reset@LLFrameTimer@@QAEXXZ) >> . >> >> . >> llgesturemgr.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLMessageSystem::nextBlockFast(char const *)" >> (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) >> llgivemoney.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLMessageSystem::nextBlockFast(char const *)" >> (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) >> llgroupmgr.obj : error LNK2001: unresolved external symbol "public: void >> __thiscall LLMessageSystem::nextBlockFast(char const *)" >> (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) >> llhudmanager.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLMessageSystem::nextBlockFast(char const *)" >> (?nextBlockFast@LLMessageSystem@@QAEXPBD@Z) >> . >> >> . >> lleventinfo.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLMessageSystem::getU32(char const *,char const >> *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) >> llfloaterregioninfo.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLMessageSystem::getU32(char const *,char const >> *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) >> llfloaterreporter.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLMessageSystem::getU32(char const *,char const >> *,unsigned int &,int)" (?getU32@LLMessageSystem@@QAEXPBD0AAIH@Z) >> llviewerparcelmgr.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLMessageSystem::getBOOL(char const *,char >> const *,int &,int)" (?getBOOL@LLMessageSystem@@QAEXPBD0AAHH@Z) >> llviewerregion.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLMessageSystem::getBOOL(char const *,char const *,int >> &,int)" (?getBOOL@LLMessageSystem@@QAEXPBD0AAHH@Z) >> . >> >> . >> llagent.obj : error LNK2001: unresolved external symbol "public: void >> __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" >> (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) >> llassetuploadresponders.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID >> const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) >> llcompilequeue.obj : error LNK2001: unresolved external symbol "public: >> void __thiscall LLInventoryItem::setAssetUUID(class LLUUID const &)" >> (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) >> llinventorymodel.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLInventoryItem::setAssetUUID(class LLUUID >> const &)" (?setAssetUUID@LLInventoryItem@@QAEXABVLLUUID@@@Z) >> llwearablelist.obj : error LNK2001: unresolved external symbol "public: >> class LLPermissions const & __thiscall >> LLInventoryItem::getPermissions(void)const " >> (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) >> llviewerobject.obj : error LNK2001: unresolved external symbol "public: >> class LLPermissions const & __thiscall >> LLInventoryItem::getPermissions(void)const " >> (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) >> llviewertexteditor.obj : error LNK2001: unresolved external symbol >> "public: class LLPermissions const & __thiscall >> LLInventoryItem::getPermissions(void)const " >> (?getPermissions@LLInventoryItem@@QBEABVLLPermissions@@XZ) >> . >> >> . >> llfloatercustomize.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLButton::setToggleState(int)" >> (?setToggleState@LLButton@@QAEXH@Z) >> llagent.obj : error LNK2019: riferimento al unresolved external symbol >> "public: void __thiscall LLCoordFrame::yaw(float)" >> (?yaw@LLCoordFrame@@QAEXM@Z) nella funzione "public: void __thiscall >> LLAgent::updateLookAt(int,int)" (?updateLookAt@LLAgent@@QAEXHH@Z) >> pipeline.obj : error LNK2001: unresolved external symbol "public: float >> __thiscall LLControlGroup::getF32(class LLStringBase const &)" >> (?getF32@LLControlGroup@@QAEMABV?$LLStringBase@D@@@Z) >> . >> >> . >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From gigstaggart at gmail.com Thu Jul 12 07:32:27 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 12 07:32:51 2007 Subject: [sldev] releasefordownload - linux In-Reply-To: <20070712123643.5t5h03w1s084kw04@datendelphin.net> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> Message-ID: <46963B7B.9040302@gmail.com> Boroondas Gupte wrote: > Jason Giglio : > > > I had to run cp > > ../linden/indra/lib_releasefordownload_client/i686-linux/ lib/ to get > > the libraries that it neglected to tar up apparently. > > might be what Callum found two weeks ago: > https://lists.secondlife.com/pipermail/sldev/2007-June/002727.html > https://lists.secondlife.com/pipermail/sldev/2007-June/thread.html#2727 > > I don't think there's a Jira Issue about it, yet. So you might want to > create one. > Boroondas Yes it appears to be the same issue. Filed: http://jira.secondlife.com/browse/VWR-1697 Someone poke Tofu. :) From dale at daleglass.net Thu Jul 12 07:39:19 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 12 07:39:30 2007 Subject: [sldev] No source in SVN yet Message-ID: <20070712134902.GA9927@bruno.sbruno> Hi, when is the source going to be uploaded to subversion? It's been on the download page for some time, but doesn't seem to be in SVN yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/4eb45ebd/attachment.pgp From matsuu at gmail.com Thu Jul 12 07:42:01 2007 From: matsuu at gmail.com (MATSUU Takuto) Date: Thu Jul 12 07:42:04 2007 Subject: [sldev] Japanese SDL support. In-Reply-To: <1184230391.3313.2.camel@localhost> References: <4695E639.2050803@gmail.com> <1184230391.3313.2.camel@localhost> Message-ID: hi see VWR-240 and libsdl Bugzilla http://bugzilla.libsdl.org/show_bug.cgi?id=429 2007/7/12, Callum Lerwick : > On Thu, 2007-07-12 at 04:28 -0400, Jason Giglio wrote: > > http://emasaka.blog65.fc2.com/blog-entry-242.html > > > > I have been told by a Japanese user that all Japanese linux users must > > apply this patch to get usable input. > > > > I can't read or write japanese, but can this patch be merged into the > > distribution? I guess the author will need to have a contribution > > agreement if they don't already. > > > > Is this already in Jira and I missed it? > > This belongs upstream at the SDL project. Is there a reason its not? > Language barrier? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From robla at lindenlab.com Thu Jul 12 08:01:59 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 12 08:02:14 2007 Subject: [sldev] No source in SVN yet In-Reply-To: <20070712134902.GA9927@bruno.sbruno> References: <20070712134902.GA9927@bruno.sbruno> Message-ID: <46964267.9060108@lindenlab.com> On 7/12/07 7:39 AM, Dale Glass wrote: > Hi, when is the source going to be uploaded to subversion? > > It's been on the download page for some time, but doesn't seem to be in > SVN yet. > > Sorry about that. Pushing now. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/e1c80dc0/signature-0001.pgp From bos at lindenlab.com Thu Jul 12 08:24:34 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jul 12 08:24:37 2007 Subject: [sldev] Japanese SDL support. In-Reply-To: <4695E639.2050803@gmail.com> References: <4695E639.2050803@gmail.com> Message-ID: <469647B2.8010909@lindenlab.com> Jason Giglio wrote: > http://emasaka.blog65.fc2.com/blog-entry-242.html > > I have been told by a Japanese user that all Japanese linux users must > apply this patch to get usable input. We're aware of this patch. It's been submitted to SDL itself. We'll pick it up in an SDL release, I believe. References: <20070712134902.GA9927@bruno.sbruno> <46964267.9060108@lindenlab.com> Message-ID: <20070712160027.GA21723@bruno.sbruno> On Thu, Jul 12, 2007 at 08:01:59AM -0700, Rob Lanphier wrote: > Sorry about that. Pushing now. Hmm, why is it in branches/Branch_1-18-0 and not in /release? Or maybe I'm not understanding what the directory structure is supposed to work like. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/aa9fcc78/attachment.pgp From nicholaz at blueflash.cc Thu Jul 12 09:35:13 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 12 09:35:21 2007 Subject: [sldev] Scripting errors Message-ID: <46965841.40808@blueflash.cc> Can someone tell me a simple command that generates a scripting error (compiles, but puts an entry into the script runtime errors window)? Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From matthew.dowd at hotmail.co.uk Thu Jul 12 09:39:28 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 12 09:39:29 2007 Subject: [sldev] Scripting errors Message-ID: I'd expect llGiveInventory(NULL_KEY, "I dont exist"); to give at least one of invalid recipient key (or similar) and item not found in inventory (or similar). Matthew ---------------------------------------- > Date: Thu, 12 Jul 2007 18:35:13 +0200 > From: nicholaz@blueflash.cc > To: sldev@lists.secondlife.com > Subject: [sldev] Scripting errors > > > Can someone tell me a simple command that generates a > scripting error (compiles, but puts an entry into > the script runtime errors window)? > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From odysseus654 at gmail.com Thu Jul 12 09:39:43 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Thu Jul 12 09:39:46 2007 Subject: [sldev] Scripting errors In-Reply-To: <46965841.40808@blueflash.cc> References: <46965841.40808@blueflash.cc> Message-ID: <1674f6c70707120939u7af612deg92d6937518717763@mail.gmail.com> lol, the stupid answer would be do to an llSay on DEBUG_CHANNEL or something... On 7/12/07, Nicholaz Beresford wrote: > > > Can someone tell me a simple command that generates a > scripting error (compiles, but puts an entry into > the script runtime errors window)? > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > 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/20070712/4fd2c396/attachment.htm From kerdezixe at gmail.com Thu Jul 12 09:53:13 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jul 12 09:53:15 2007 Subject: [sldev] JIRA and SLDev Fanclub Message-ID: <8a1bfe660707120953k1d2dd9cak21e331d22deefac@mail.gmail.com> Hi, I spent some hours on JIRA today. Here is my tought : 1) The meta-issue is a great idea. We could have some meta-triage session. 2) Some reporter forget to set the componant, i sorted tons (ok... a dozen) of uncategorized bugs and added the correct componant. 3) a lot of bug seems outdated, or "one-time bug" (eg : website down) and are still open. Resolved some. Most of this stuff can be done alone, but it's safer, and more fun to do that in group. So ... so ... i created the "JIRA and SLDev Fanclub" with my alt account (howow Nabob). The draft charter is "For all thoses techno-nerdo-geeky of SLDev enjoying the public secondlife JIRA, meta-issueing, bug-triage and much more... Trying to organize unofficial bug-triage and bogus-bug hunting party !" I was close to call that "Gay 4 JIRA" but... well... no :) It's open enrollment and ... of course... there is no fee :) The group could be used to annonce the official bug-triage session, office hours, as well as unofficial triage session. If we feel the need for a land, that's not a problem, i have tons of land available. (private or mainland) 1st priority : I'm in need of someone following the office-hours to send notices, i always miss them (being in Europe, i'm not always awaken for all office hours). Thx :) -- kerunix Flan From gigstaggart at gmail.com Thu Jul 12 10:12:49 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jul 12 10:13:14 2007 Subject: [sldev] Scripting errors In-Reply-To: <1674f6c70707120939u7af612deg92d6937518717763@mail.gmail.com> References: <46965841.40808@blueflash.cc> <1674f6c70707120939u7af612deg92d6937518717763@mail.gmail.com> Message-ID: <46966111.7030003@gmail.com> Erik Anderson wrote: > lol, the stupid answer would be do to an llSay on DEBUG_CHANNEL or > something... > I wouldn't trust that, there's a whole bunch of quirks regarding the DEBUG_CHANNEL, it's not simply chat on that channel, it actually has a specific flag associated with it also. llSay on the channel may or may not set that "Type" flag. On a comedic note, if you do /2147483647 stuff, it goes to channel 0, a bug. So I tried forcing that chat to have the "error flag" to see if that would fix it. It didn't and it caused my avatar to get a script error over its head (that everyone else could see too). Had a lot of fun doing stuff like /2147483647 Error: Brain overloaded :) -Jason From tateru.nino at gmail.com Thu Jul 12 10:13:12 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jul 12 10:13:38 2007 Subject: [sldev] Scripting errors In-Reply-To: <46965841.40808@blueflash.cc> References: <46965841.40808@blueflash.cc> Message-ID: <46966128.60705@gmail.com> default { state_entry() { llSetTimerEvent(30); } timer() { llSay(DEBUG_CHANNEL, "I am a sad prim, and I despair."); } } Nicholaz Beresford wrote: > > Can someone tell me a simple command that generates a > scripting error (compiles, but puts an entry into > the script runtime errors window)? > > Nick > -- Tateru Nino http://dwellonit.blogspot.com/ From dale at daleglass.net Thu Jul 12 10:17:18 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 12 10:17:23 2007 Subject: [sldev] Wiki seems down, anybody has a link to the source? Message-ID: <20070712171717.GB21723@bruno.sbruno> Hi Wiki seems down ATM, or at least not working. I just realized here that I don't have the libraries and artwork to the 1.18.0.6 source, and can't get them. If anybody has a link to the files it'd be much appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/049ca0df/attachment.pgp From dale at daleglass.net Thu Jul 12 10:30:24 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 12 10:30:33 2007 Subject: [sldev] N/M that, got it working In-Reply-To: <20070712171717.GB21723@bruno.sbruno> References: <20070712171717.GB21723@bruno.sbruno> Message-ID: <20070712173024.GC21723@bruno.sbruno> It just started working on http, so I'm downloading them now. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/308c2cbc/attachment.pgp From nicholaz at blueflash.cc Thu Jul 12 10:32:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 12 10:32:25 2007 Subject: [sldev] Scripting errors In-Reply-To: <46965841.40808@blueflash.cc> References: <46965841.40808@blueflash.cc> Message-ID: <469665A0.2060808@blueflash.cc> Thanks LSL gurus for the suggestions :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford wrote: > > Can someone tell me a simple command that generates a > scripting error (compiles, but puts an entry into > the script runtime errors window)? > > Nick > From sean at lindenlab.com Thu Jul 12 10:33:07 2007 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jul 12 10:33:10 2007 Subject: [sldev] https very slow. In-Reply-To: <20070711210741.GD14142@bruno.sbruno> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> <46951B0A.4030406@gmail.com> <20070711180812.GB14142@bruno.sbruno> <1184187061.11166.1.camel@localhost> <20070711210741.GD14142@bruno.sbruno> Message-ID: <469665D3.7030906@lindenlab.com> Dale Glass wrote: > >> Blowfish? >> > > About the same performance as for AES: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > blowfish cbc 93727.58k 99827.99k 101858.99k 102497.96k 103030.15k > > > BTW, benchmarks are done with "openssl speed" > I would recommend running your test again, without other stuff running on your computer at the same time. Blowfish is a much faster algorithm than AES, particularly for long streams. I would also consider it pretty much equivalent in terms of security; the only reason it wasn't considered to *be* AES (Twofish was one of the top contenders, though) is because of the (IMHO superfluous) blocksize requirement NIST put on the contest. blowfish cbc 66412.75k 71300.08k 73066.62k 73634.66k 73738.25k aes-128 cbc 45696.79k 46712.40k 46989.89k 47077.26k 47035.85k aes-192 cbc 39139.25k 39782.53k 39969.31k 40004.03k 39955.59k aes-256 cbc 34068.63k 34575.53k 34717.30k 34741.87k 34679.98k -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/634319cc/attachment.htm From kelly at lindenlab.com Thu Jul 12 10:46:53 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Thu Jul 12 10:46:56 2007 Subject: [sldev] Scripting errors In-Reply-To: <469665A0.2060808@blueflash.cc> References: <46965841.40808@blueflash.cc> <469665A0.2060808@blueflash.cc> Message-ID: <4696690D.6000004@lindenlab.com> default { state_entry() { string s; while(1) s += s + "1234567890"; } } (Out of memory / stack heap collision). - Kelly Nicholaz Beresford wrote: > Thanks LSL gurus for the suggestions :-) > > > Nick > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Nicholaz Beresford wrote: >> >> Can someone tell me a simple command that generates a >> scripting error (compiles, but puts an entry into >> the script runtime errors window)? >> >> Nick >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robla at lindenlab.com Thu Jul 12 11:31:05 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 12 11:31:12 2007 Subject: [sldev] No source in SVN yet In-Reply-To: <20070712160027.GA21723@bruno.sbruno> References: <20070712134902.GA9927@bruno.sbruno> <46964267.9060108@lindenlab.com> <20070712160027.GA21723@bruno.sbruno> Message-ID: <46967369.1090800@lindenlab.com> On 7/12/07 9:00 AM, Dale Glass wrote: > On Thu, Jul 12, 2007 at 08:01:59AM -0700, Rob Lanphier wrote: > >> Sorry about that. Pushing now. >> > > Hmm, why is it in branches/Branch_1-18-0 and not in /release? > > Or maybe I'm not understanding what the directory structure is supposed > to work like. > I'm keeping things as close as possible to our internal repository structure as possible. I think the fact that 1.17.x (x>0) came straight off of "release" was the actual anomaly from our usual process. See: https://wiki.secondlife.com/wiki/Source_branches ...for an explanation. Additionally, you can look at the source downloads page to see the historical use: https://wiki.secondlife.com/wiki/Source_downloads Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/a0876dda/signature.pgp From dale at daleglass.net Thu Jul 12 12:52:45 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 12 12:52:52 2007 Subject: [sldev] https very slow. In-Reply-To: <469665D3.7030906@lindenlab.com> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> <46951B0A.4030406@gmail.com> <20070711180812.GB14142@bruno.sbruno> <1184187061.11166.1.camel@localhost> <20070711210741.GD14142@bruno.sbruno> <469665D3.7030906@lindenlab.com> Message-ID: <20070712195245.GD21723@bruno.sbruno> On Thu, Jul 12, 2007 at 10:33:07AM -0700, Sean Lynch wrote: > I would recommend running your test again, without other stuff running > on your computer at the same time. Blowfish is a much faster algorithm type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes blowfish cbc 92973.07k 97980.23k 99785.68k 100530.07k 100761.60k aes-128 cbc 104529.05k 108762.79k 107923.90k 109624.93k 110783.43k aes-192 cbc 91465.49k 96388.81k 98216.17k 98378.32k 99205.95k aes-256 cbc 83671.58k 86025.24k 87899.27k 88412.02k 88720.18k I suppose the difference is probably in the hardware. Or maybe optimization. This is running on an Athlon 64 X2 5200+, with a 64 bit Gentoo install. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/87844b66/attachment.pgp From sean at lindenlab.com Thu Jul 12 13:05:24 2007 From: sean at lindenlab.com (Sean Lynch) Date: Thu Jul 12 13:05:28 2007 Subject: [sldev] https very slow. In-Reply-To: <20070712195245.GD21723@bruno.sbruno> References: <46950B45.6080502@blueflash.cc> <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <20070711175653.GA14142@bruno.sbruno> <46951B0A.4030406@gmail.com> <20070711180812.GB14142@bruno.sbruno> <1184187061.11166.1.camel@localhost> <20070711210741.GD14142@bruno.sbruno> <469665D3.7030906@lindenlab.com> <20070712195245.GD21723@bruno.sbruno> Message-ID: <46968984.3000906@lindenlab.com> Weird! Mine was on a MacBook Pro with a 2.16 GHz Intel Core 2 Duo running MacOS 10.4.10. Blowfish is still in general a faster algorithm, but I am guessing AES gets more attention and therefore more optimization effort just because it's AES :) Dale Glass wrote: > On Thu, Jul 12, 2007 at 10:33:07AM -0700, Sean Lynch wrote: > >> I would recommend running your test again, without other stuff running >> on your computer at the same time. Blowfish is a much faster algorithm >> > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > > blowfish cbc 92973.07k 97980.23k 99785.68k 100530.07k 100761.60k > aes-128 cbc 104529.05k 108762.79k 107923.90k 109624.93k 110783.43k > aes-192 cbc 91465.49k 96388.81k 98216.17k 98378.32k 99205.95k > aes-256 cbc 83671.58k 86025.24k 87899.27k 88412.02k 88720.18k > > I suppose the difference is probably in the hardware. Or maybe optimization. > This is running on an Athlon 64 X2 5200+, with a 64 bit Gentoo install. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/25036470/attachment.htm From robla at lindenlab.com Thu Jul 12 13:34:26 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 12 13:35:06 2007 Subject: [sldev] https very slow. In-Reply-To: <469515B0.6030508@blueflash.cc> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> Message-ID: <46969052.2070400@lindenlab.com> There are a lot of issues being conflated in this thread. If anyone is still interested in the performance of wiki.secondlife.com, the best place to discuss that is here: https://jira.secondlife.com/browse/WEB-223 Further discussion of http vs. https on this mailing list needs to be specific (in the subject line of the message) about which system component we're talking about here: * jira.secondlife.com * wiki.secondlife.com * some specific piece of Second Life core infrastructure ....and probably taken off list to jira or wiki soon. With respect to running https on jira and wiki, we've tried to avoid overusing https, but web applications tend to force you to use one or the other for everything for all of the cookies/session management to work properly. Some of our early JIRA login issues were caused in part by us trying to overoptimize on this very problem. As to why we use https in other parts of the infrastructure, I'll leave that to others here at Linden Lab. More benchmarking of https in general is welcome here: https://wiki.secondlife.com/wiki/HTTPS Note, it's a blank page right now, but it doesn't have to stay that way. Rob On 7/11/07 10:38 AM, Nicholaz Beresford wrote: > > Gary Wardell wrote: >> So, given that one can do monetary transaction through the viewer, it >> may need encryption. However, if the transactions are >> actually done on the server, and no sensitive information is in the >> viewer, ... >> >> That being said, encryption would be superfluous for non-monetary >> transactions. >> >> Also, it is more than a few cpu cycles. Actually it can be >> significant. It also balloons the size of the payload so it requires >> more bandwidth. > > I'm sure it's more than that (these were up to a few hundred > per minute as far as I remember). > > It may have something to do with securing copyright (like > limiting the ability to intercept objects or textures through > a proxy), but dunno really ... just remember that I was > wondering about it at that time. > > > Nick > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/9108bf22/signature.pgp From jake at lindenlab.com Thu Jul 12 13:40:01 2007 From: jake at lindenlab.com (Jake Simpson) Date: Thu Jul 12 13:40:10 2007 Subject: [sldev] Re:SVC-85 - friends lists not working Message-ID: <469691A1.4090104@lindenlab.com> Peeps, I'm just going to re post this set of questions I added into the comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 (friends lists not always working to show online presence correctly) just to see if any of you guys have run into this, and if you do, if you could look into the results of the questions. I would like to get this fixed but I need some more data before I can get it done right. Thanks OK, so I'm looking into this since it's obviously a bug of much contention. You can't have much of a second life if you can't see anyone to share it with. Kelly and I have been talking about approaches to fixing this - the code as it stands _should_ work correctly because in many circumstances it does. However, the code behind this is pretty knarly and has many places of potential failure, so Kelly and I have come up with a new way to deal with this (based on how we do group online presence reporting), using our new back bone system the way it should be used. With a view to doing that, I have a couple of questions for you guys. 1) When you know someone is on line, even though the friends list says they are not, do they show up as online in the groups list (assuming you know they are subscribed to one of the same groups as you)? The code that the groups uses to determine online presence is actually different from the code that the friends list uses (it's older code and also the friends list returns a lot more information regarding the friends themselves than the groups list does - that just has enough to say "this person is online or not". The friends list has information about where they are so you can IM them etc). From what we've observed, the groups stuff works when the friends list doesn't - it would be nice of you guys could confirm this. 2) When you initially log on and someone is not reported online (because they aren't), is the system updating when they _do_ log on? What I'm saying if either the friends list says everyone is off line, then a friend logs on and it updates and says they *are* online, or they *were* online, the friends list says they aren't - they relog - does it show up correctly then? Again the code that gets the initial list of friends and interrogates them to see if they are online or not is not the same system that reports a friend has logged on (or off) - it uses some of the same paths but it's not entirely the same. 3) Are we seeing an initial friends list situation where *select* people are not being reported as online, or everyone? 4) What does it take for a friend you know is online to show up as online in the friends list if they are initially not shown? The answers to this will help up determine exactly what's broken and whether we can fix it or whether it'll be easier to just try a new way of doing it. Either way, I want you guys to know we are on this - it's a top priority with LL. Jake From able.whitman at gmail.com Thu Jul 12 13:57:16 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 12 13:57:19 2007 Subject: [sldev] Re: Mute Visibility Preview (Re: More on Mute Visibility) In-Reply-To: <7b3a84fb0707061244p5b8ecfaahcd8aabadd9f7ed0d@mail.gmail.com> References: <7b3a84fb0707061244p5b8ecfaahcd8aabadd9f7ed0d@mail.gmail.com> Message-ID: <7b3a84fb0707121357w4d12d14ai781de49b0503ac38@mail.gmail.com> Howdy, I've got an updated version of my mute visibility preview viewer done, updated to work with the 1.18 release. I think it's ready for public consumption, so if you're interested in trying it out, you can get it here: http://ablewhitman.org/viewer/ As before, it's currently only available for Windows, and only supports the en-us locale. It will install on top of an official 1.18.0.6 installation, but it works side-by-side with the official viewer and should not overwrite any files or clobber any settings. Let me know if you have any questions! Cheers, --Able On 7/6/07, Able Whitman wrote: > > Howdy, > > In between work and occasionally catching some sleep, I've got a preview > of my Mute Visibility feature ready to test. Before I make it generally > available, I'd like a couple people to install it and take a look, to shake > out any "well it works on my machine" problems that I've overlooked. > > My build is available for Windows only, and requires an existing 1.17.2.0install (I have not tried it with > 1.7.3.0, so it may or may not work). If you'd like to give it a go, please > reply just to me, and I'll send it to the first couple folks to reply. > > Once I've got some confidence that the test release is usable, I'll post a > download link here. > > Cheers! > --Able > > > On 6/21/07, Able Whitman wrote: > > > > Howdy, > > > > On and off, I've been investigating the feasibility of implementing " > > Visibility Muting" as Nicholaz describes in VWR-1017 (https://jira.secondlife.com/browse/VWR-1017 ), > > and as discussed in a few threads on this list. I'm pretty close to having a > > proof-of-concept patch ready which adds the ability to mute the > > visibility of objects by their ID, in much the same fashion that the > > existing chat muting function works. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/3b20b582/attachment.htm From joel at ourstillwaters.org Thu Jul 12 14:32:42 2007 From: joel at ourstillwaters.org (Joel Riedesel) Date: Thu Jul 12 14:32:53 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <46969052.2070400@lindenlab.com> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> Message-ID: <46969DFA.6020308@ourstillwaters.org> Hello. The message templates changed to a version 2.0 in the 1.18 update. Message headers appear to have been changed as well allowing for 32 bit sequence numbers instead of 24 bit. I think. I haven't been able to find any documentation on protocol changes for 1.18, is that available somewhere? Has the login data changed at all? My initial login comes back with a circuit code, etc., but my first packet never gets a response (UseCircuitCode) which leads me to believe that I still do not have it constructed properly for the 1.18 update. (Although network sniffing makes me think I have my packet constructed properly as compared against what the SL Viewer is sending.) No problems until the 1.18 update was rolled out. I am not using the SL Viewer source code for my SL client. Thus it is a bit of a pain when the protocol changes without supporting documentation (and if I'm wrong about that please correct me). Joel From labrat.hb at gmail.com Thu Jul 12 14:59:37 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jul 12 14:59:41 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469691A1.4090104@lindenlab.com> References: <469691A1.4090104@lindenlab.com> Message-ID: 1.) Haven't thought to check, but usually their profile page will show the "online" text, and you can query the dataserver for their online status and that does work. 2.) All of the following situations have happened in the week prior to 1.18release Initial Login: Friends List is missing someone who is online. Failed update on logoff: Friend logs off and Friends List does not update Failed update on logon: Friend logs on and Friends List does not update 3.) Select people not showing online 4.) Sometimes sending and recieving an IM will trigger the status refresh On 7/12/07, Jake Simpson wrote: > > Peeps, > > I'm just going to re post this set of questions I added into the > comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 (friends > lists not always working to show online presence correctly) just to see > if any of you guys have run into this, and if you do, if you could look > into the results of the questions. I would like to get this fixed but I > need some more data before I can get it done right. > > Thanks > > OK, so I'm looking into this since it's obviously a bug of much > contention. You can't have much of a second life if you can't see anyone > to share it with. > > Kelly and I have been talking about approaches to fixing this - the code > as it stands _should_ work correctly because in many circumstances it > does. However, the code behind this is pretty knarly and has many places > of potential failure, so Kelly and I have come up with a new way to deal > with this (based on how we do group online presence reporting), using > our new back bone system the way it should be used. > > With a view to doing that, I have a couple of questions for you guys. > > 1) When you know someone is on line, even though the friends list says > they are not, do they show up as online in the groups list (assuming you > know they are subscribed to one of the same groups as you)? The code > that the groups uses to determine online presence is actually different > from the code that the friends list uses (it's older code and also the > friends list returns a lot more information regarding the friends > themselves than the groups list does - that just has enough to say "this > person is online or not". The friends list has information about where > they are so you can IM them etc). From what we've observed, the groups > stuff works when the friends list doesn't - it would be nice of you guys > could confirm this. > > 2) When you initially log on and someone is not reported online (because > they aren't), is the system updating when they _do_ log on? What I'm > saying if either the friends list says everyone is off line, then a > friend logs on and it updates and says they *are* online, or they *were* > online, the friends list says they aren't - they relog - does it show up > correctly then? Again the code that gets the initial list of friends and > interrogates them to see if they are online or not is not the same > system that reports a friend has logged on (or off) - it uses some of > the same paths but it's not entirely the same. > > 3) Are we seeing an initial friends list situation where *select* people > are not being reported as online, or everyone? > > 4) What does it take for a friend you know is online to show up as > online in the friends list if they are initially not shown? > > The answers to this will help up determine exactly what's broken and > whether we can fix it or whether it'll be easier to just try a new way > of doing it. > > Either way, I want you guys to know we are on this - it's a top priority > with LL. > > Jake > _______________________________________________ > 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/20070712/66231ad6/attachment-0001.htm From able.whitman at gmail.com Thu Jul 12 15:03:42 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 12 15:03:44 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469691A1.4090104@lindenlab.com> References: <469691A1.4090104@lindenlab.com> Message-ID: <7b3a84fb0707121503j33f6635eo3e537e5faf6a7a6b@mail.gmail.com> Howdy Jake, I've noticed this problem even with 1.18.0.6, but it affects me only intermittently, I'm afraid I haven't been able to pin down what exact circumstances seem to exacerbate this bug for me, but I've replied to your questions below. On 7/12/07, Jake Simpson wrote: > > With a view to doing that, I have a couple of questions for you guys. > > 1) When you know someone is on line, even though the friends list says > they are not, do they show up as online in the groups list (assuming you > know they are subscribed to one of the same groups as you)? At least in my experience, I can confirm this. The presence information in a groups list consistently reflects the actual presence of people on my friends list. I've also seen that the web site's "Friends Online" page seems to always show the correct presence information, even if my friends list does not. 2) When you initially log on and someone is not reported online (because > they aren't), is the system updating when they _do_ log on? This happens to me "rarely". I wish I could be more precise as to the frequency, but unfortunately I can't. It is usually the case that if I am online when a friend logs in, I will receive notification as to that fact. What I have noticed is that I almost always get notified when a friend goes *offline*, even if my friends list never reflected the fact that they were online in the first place. 3) Are we seeing an initial friends list situation where *select* people > are not being reported as online, or everyone? It's always only a select few friends whose presence information isn't correct in my friends list. But the select few is always different; it's not always the same friends whose presence information is inaccurate, it happens to all of my friends. 4) What does it take for a friend you know is online to show up as > online in the friends list if they are initially not shown? If I IM them or drop them inventory, they will suddenly appear to have come online at that moment. IMing seems to be the simplest and most consistently effective way of "pinging" a friend to see if they're really online or not. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/f2ab3bbb/attachment.htm From secret.argent at gmail.com Thu Jul 12 15:52:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jul 12 15:52:11 2007 Subject: [sldev] Re:SVC-85 - friends lists not working (Jake Simpson) In-Reply-To: <20070712215944.53B0F41AFAB@stupor.lindenlab.com> References: <20070712215944.53B0F41AFAB@stupor.lindenlab.com> Message-ID: <13DA8856-0775-4F27-B901-AAA8A055C824@gmail.com> > 1) When you know someone is on line, even though the friends list says > they are not, do they show up as online in the groups list > (assuming you > know they are subscribed to one of the same groups as you)? Yes, I use this workaround all the time. I really can't say for certain on 2 and 3. Also, I sometimes try sending them an IM. Sometimes that makes them show up, but only after it's actually sent. > 4) What does it take for a friend you know is online to show up as > online in the friends list if they are initially not shown? See above. From matthew.dowd at hotmail.co.uk Thu Jul 12 16:03:22 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Jul 12 16:03:23 2007 Subject: [sldev] Re:SVC-85 - friends lists not working (Jake Simpson) Message-ID: I'm pretty sure that the groups online status is correct - also the status returned by llRequestAgentData is correct. It is hard to tell if you get notified everytime someone logs on and off without a second means of reliably monitoring all you friends. Certainly like others it appears these message do get through. Sending an IM normally gets their status correctly, but not just opening the IM window. I have on occasions had people reported as being online when they aren't (which I only discover when I send them an IM and get back they are offline response). I suspect that these are reported as falsely when I log on rather than that an offline response failed to get through whilst I was online, but couldn't guaranteed that. Matthew ---------------------------------------- > From: secret.argent@gmail.com > Date: Thu, 12 Jul 2007 17:52:23 -0500 > To: sldev@lists.secondlife.com > Subject: [sldev] Re:SVC-85 - friends lists not working (Jake Simpson) > > > 1) When you know someone is on line, even though the friends list says > > they are not, do they show up as online in the groups list > > (assuming you > > know they are subscribed to one of the same groups as you)? > > Yes, I use this workaround all the time. > > I really can't say for certain on 2 and 3. > > Also, I sometimes try sending them an IM. Sometimes that makes them > show up, but only after it's actually sent. > > > 4) What does it take for a friend you know is online to show up as > > online in the friends list if they are initially not shown? > > See above. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From dzonatas at dzonux.net Thu Jul 12 16:07:34 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 12 16:07:30 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <46969DFA.6020308@ourstillwaters.org> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> Message-ID: <4696B436.1050408@dzonux.net> The message template file is pretty well human-readable. A simple "diff" command ran on the current and previous versions is very informative. Joel Riedesel wrote: > Hello. > The message templates changed to a version 2.0 in the 1.18 update. > Message headers appear to have been changed as well allowing for 32 bit > sequence numbers instead of 24 bit. I think. > > I haven't been able to find any documentation on protocol changes for > 1.18, is that available somewhere? Has the login data changed at all? > My initial login comes back with a circuit code, etc., but my first > packet never gets a response (UseCircuitCode) which leads me to believe > that I still do not have it constructed properly for the 1.18 update. > (Although network sniffing makes me think I have my packet constructed > properly as compared against what the SL Viewer is sending.) > > No problems until the 1.18 update was rolled out. > > I am not using the SL Viewer source code for my SL client. Thus it is a > bit of a pain when the protocol changes without supporting documentation > (and if I'm wrong about that please correct me). > > Joel > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- Power to Change the Void From sldev at catznip.com Thu Jul 12 16:14:11 2007 From: sldev at catznip.com (Kitty) Date: Thu Jul 12 16:11:02 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469691A1.4090104@lindenlab.com> References: <469691A1.4090104@lindenlab.com> Message-ID: <008101c7c4da$5fbec180$0501a8c0@devbits.intra> I'm not sure how relevant the number of friends is and I don't have an accurate recent count but mine is probably somewhere between 150-200 with usually 15-40 online at any given time. 1) The groups online/offline seems to be accurate, I've never known it to report wrong anyway even with general presence issues 2) It's very quirky. I've seen all scenarios happen: * friend not reported when logging on, see them log off when them log off * friend not reported when logging on, don't see them log off when they log off but do see them log back on * friend not reported when logging on, don't see them log off when they log off and don't see them log back on either * friend not reported when they're logging off (they did log out; friends says online, the profile says online, group says offline) * friend suddenly reported as logging off when they're not (happens both while IM'ing and when out) and they stay offline The online IM check seems to be rather quirky as well (not sure if it's related or a separate issue). Sometimes you'll be able to IM someone, but they're not able to IM you back (it always go through offline) or vice versa. Usually happens for no reason (noone tp'ed, noone crossed sim borders, nothing user-initiated), one message goes through and the next dozen will fail and go off-line. The viewer can show a wrong offline message in that case, but not always either. 3) Some people show, others don't show. Between (instant) relogs the people who show and those who don't will vary, it's not consistent, but eventually you'll get a relog where everyone shows proper. I did notice that if the friends list doesn't download fast enough (the 'hippos' friends), you end up with an inconsistent list for sure. 4) IM'ing them usually does it, but not always. If they log off, that'll show most of the time although it seems to misfire the log-off message as well. If they relog that can trigger it but it's not consistent either. Another oddness is someone who's reported online, crashes and relogs but you only get an online notice and no offline notice (if they don't relog they stay stuck as online when they're not). From robla at lindenlab.com Thu Jul 12 16:14:52 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 12 16:15:30 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <46969DFA.6020308@ourstillwaters.org> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> Message-ID: <4696B5EC.50302@lindenlab.com> On 7/12/07 2:32 PM, Joel Riedesel wrote: > The message templates changed to a version 2.0 in the 1.18 update. > Message headers appear to have been changed as well allowing for 32 bit > sequence numbers instead of 24 bit. I think. > > I haven't been able to find any documentation on protocol changes for > 1.18, is that available somewhere? Has the login data changed at all? > My initial login comes back with a circuit code, etc., but my first > packet never gets a response (UseCircuitCode) which leads me to believe > that I still do not have it constructed properly for the 1.18 update. > (Although network sniffing makes me think I have my packet constructed > properly as compared against what the SL Viewer is sending.) > > No problems until the 1.18 update was rolled out. > > I am not using the SL Viewer source code for my SL client. Thus it is a > bit of a pain when the protocol changes without supporting documentation > (and if I'm wrong about that please correct me). > Be sure to read this: http://blog.secondlife.com/2007/06/25/dia-de-la-liberacion/ ....and be sure to show up for Zero Linden's office hours if you want to learn more about the protocol, etc. I'll check with Cube regarding updating these pages: http://wiki.secondlife.com/wiki/Category:Messages ....since now it makes sense to update them, and I think he has a script to blast through updating them. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070712/5ee780e6/signature.pgp From dzonatas at dzonux.net Thu Jul 12 17:10:22 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 12 17:10:14 2007 Subject: [sldev] SLDev & QA: Open Source Release-Candidate Repository Message-ID: <4696C2EE.5060200@dzonux.net> Inspired from the Open Source Meeting, I'm making available the Open Second Life Community Code (OSLCC) repository for those that wish to participate in Quality Assurance on contributions from the open source community. What is desired is a refined process to track patches and other changes being made to Second Life from resident developers. OSLCC currently resides on SourceForge, which is powerful but has its limits. I will to host OSLCC upon resolution of my contract, as there exists a ready option to upgrade the immediate bandwidth to my server. Of course, I'll have to be able to cover the cost; hence, a possible resolution to the contract. The OSLCC repository could be used to create auto-builds of resident made patches and further develop Q&A processes to formalize intake to the official build hosted by Linden Lab. This would not be an overnight solution; therefore, we have the SF location for now. I can grant developer access to post releases and further grant svn access, if desired. Just e-mail back if you are interested to work together on this process. =) Perhaps, if successful with the repository, we can have a new mail-list for residents that don't code but would like to help test new versions of Second Life that are posted to the repository. -- Power to Change the Void From dale at daleglass.net Thu Jul 12 18:32:21 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 12 18:32:27 2007 Subject: [sldev] Very experimental viewer released (updated) In-Reply-To: <20070711022937.GE7685@bruno.sbruno> References: <20070711022937.GE7685@bruno.sbruno> Message-ID: <20070713013221.GE21723@bruno.sbruno> New version of the installer: http://daleglass.net/installer/sl_1.18.0.6_rev_44.exe Not very tested yet, feedback will be very appreciated. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070713/13cdfed1/attachment-0001.pgp From joel at ourstillwaters.org Thu Jul 12 19:35:27 2007 From: joel at ourstillwaters.org (Joel Riedesel) Date: Thu Jul 12 19:35:38 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <4696B5EC.50302@lindenlab.com> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> <4696B5EC.50302@lindenlab.com> Message-ID: <4696E4EF.9060405@ourstillwaters.org> Yeah and the main protocol description page as well if the sequence numbers really have changed from 24 bits to 32 bits. I didn't get the blog post the first time around, thanks. But it doesn't give me anything of substance other than identifying why all the packets are now numbered - makes sense. But anything about the login change? If not great. Must be something amiss on my end. Cheers, Joel Rob Lanphier wrote: > On 7/12/07 2:32 PM, Joel Riedesel wrote: >> The message templates changed to a version 2.0 in the 1.18 update. >> Message headers appear to have been changed as well allowing for 32 bit >> sequence numbers instead of 24 bit. I think. >> >> I haven't been able to find any documentation on protocol changes for >> 1.18, is that available somewhere? Has the login data changed at all? >> My initial login comes back with a circuit code, etc., but my first >> packet never gets a response (UseCircuitCode) which leads me to believe >> that I still do not have it constructed properly for the 1.18 update. >> (Although network sniffing makes me think I have my packet constructed >> properly as compared against what the SL Viewer is sending.) >> >> No problems until the 1.18 update was rolled out. >> >> I am not using the SL Viewer source code for my SL client. Thus it is a >> bit of a pain when the protocol changes without supporting documentation >> (and if I'm wrong about that please correct me). >> > > Be sure to read this: > http://blog.secondlife.com/2007/06/25/dia-de-la-liberacion/ > > ....and be sure to show up for Zero Linden's office hours if you want to > learn more about the protocol, etc. > > I'll check with Cube regarding updating these pages: > http://wiki.secondlife.com/wiki/Category:Messages > > ....since now it makes sense to update them, and I think he has a script > to blast through updating them. > > Rob > > From joel at ourstillwaters.org Thu Jul 12 19:37:49 2007 From: joel at ourstillwaters.org (Joel Riedesel) Date: Thu Jul 12 19:37:56 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <4696B436.1050408@dzonux.net> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> <4696B436.1050408@dzonux.net> Message-ID: <4696E57D.4060100@ourstillwaters.org> Indeed a diff is normally useful. Except when every packet has changed. And the template system doesn't describe the login xml rpc request. And the template message file does not talk about the headers. (not to mention compressed data blocks where the parsing isn't described in the template file) Cheers, Joel Dzonatas wrote: > The message template file is pretty well human-readable. A simple "diff" > command ran on the current and previous versions is very informative. > > Joel Riedesel wrote: >> Hello. >> The message templates changed to a version 2.0 in the 1.18 update. >> Message headers appear to have been changed as well allowing for 32 bit >> sequence numbers instead of 24 bit. I think. >> >> I haven't been able to find any documentation on protocol changes for >> 1.18, is that available somewhere? Has the login data changed at all? >> My initial login comes back with a circuit code, etc., but my first >> packet never gets a response (UseCircuitCode) which leads me to believe >> that I still do not have it constructed properly for the 1.18 update. >> (Although network sniffing makes me think I have my packet constructed >> properly as compared against what the SL Viewer is sending.) >> >> No problems until the 1.18 update was rolled out. >> >> I am not using the SL Viewer source code for my SL client. Thus it is a >> bit of a pain when the protocol changes without supporting documentation >> (and if I'm wrong about that please correct me). >> >> Joel >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > From able.whitman at gmail.com Thu Jul 12 19:53:56 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 12 19:53:58 2007 Subject: [sldev] Re: Mute Visibility Preview (Re: More on Mute Visibility) In-Reply-To: <7b3a84fb0707121357w4d12d14ai781de49b0503ac38@mail.gmail.com> References: <7b3a84fb0707061244p5b8ecfaahcd8aabadd9f7ed0d@mail.gmail.com> <7b3a84fb0707121357w4d12d14ai781de49b0503ac38@mail.gmail.com> Message-ID: <7b3a84fb0707121953k3ced71e4m9d3bbbfb04cd17f0@mail.gmail.com> I've posted a diff for the 41571 build of my private viewer, based on the official 1.18.0.6 source release. It also includes the 3 custom XML files, and the files needed to create a standalone Windows installer using NSIS. The patch is here: http://ablewhitman.org/viewer/aw-41571.patch.zip Cheers, --Able On 7/12/07, Able Whitman wrote: > > Howdy, > > I've got an updated version of my mute visibility preview viewer done, > updated to work with the 1.18 release. I think it's ready for public > consumption, so if you're interested in trying it out, you can get it here: > > http://ablewhitman.org/viewer/ > > As before, it's currently only available for Windows, and only supports > the en-us locale. It will install on top of an official 1.18.0.6installation, but it works side-by-side with the official viewer and should > not overwrite any files or clobber any settings. > > Let me know if you have any questions! > > Cheers, > --Able > > > On 7/6/07, Able Whitman < able.whitman@gmail.com> wrote: > > > > Howdy, > > > > In between work and occasionally catching some sleep, I've got a preview > > of my Mute Visibility feature ready to test. Before I make it generally > > available, I'd like a couple people to install it and take a look, to shake > > out any "well it works on my machine" problems that I've overlooked. > > > > My build is available for Windows only, and requires an existing > > 1.17.2.0 install (I have not tried it with 1.7.3.0, so it may or may not > > work). If you'd like to give it a go, please reply just to me, and I'll send > > it to the first couple folks to reply. > > > > Once I've got some confidence that the test release is usable, I'll post > > a download link here. > > > > Cheers! > > --Able > > > > > > On 6/21/07, Able Whitman wrote: > > > > > > Howdy, > > > > > > On and off, I've been investigating the feasibility of implementing " > > > Visibility Muting" as Nicholaz describes in VWR-1017 (https://jira.secondlife.com/browse/VWR-1017 ), > > > and as discussed in a few threads on this list. I'm pretty close to having a > > > proof-of-concept patch ready which adds the ability to mute the > > > visibility of objects by their ID, in much the same fashion that the > > > existing chat muting function works. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070712/f1bc8ffe/attachment.htm From tateru.nino at gmail.com Thu Jul 12 21:01:23 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jul 12 21:01:55 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469691A1.4090104@lindenlab.com> References: <469691A1.4090104@lindenlab.com> Message-ID: <4696F913.3090105@gmail.com> 3) Specific simulators generally tend to be at fault. If simulator A begins to exhibit the problem behaviour, then no presence information is received from people logging in to simulator A, nor do people in simulator A receive presence information, until the sim restarts. Caveat: It's a little more likely that a logoff notification will be received than a login notification. When the issue has been at its worst, perhaps 15% of simulators have been affected. There seems to be more than one issue, and given simulators (some seem more prone to it than others) getting themselves in a bunch seems to be one of them. Jake Simpson wrote: > Peeps, > > I'm just going to re post this set of questions I added into the > comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 > (friends lists not always working to show online presence correctly) > just to see if any of you guys have run into this, and if you do, if > you could look into the results of the questions. I would like to get > this fixed but I need some more data before I can get it done right. > > Thanks > > OK, so I'm looking into this since it's obviously a bug of much > contention. You can't have much of a second life if you can't see > anyone to share it with. > > Kelly and I have been talking about approaches to fixing this - the > code as it stands _should_ work correctly because in many > circumstances it does. However, the code behind this is pretty knarly > and has many places of potential failure, so Kelly and I have come up > with a new way to deal with this (based on how we do group online > presence reporting), using our new back bone system the way it should > be used. > > With a view to doing that, I have a couple of questions for you guys. > > 1) When you know someone is on line, even though the friends list says > they are not, do they show up as online in the groups list (assuming > you know they are subscribed to one of the same groups as you)? The > code that the groups uses to determine online presence is actually > different from the code that the friends list uses (it's older code > and also the friends list returns a lot more information regarding the > friends themselves than the groups list does - that just has enough to > say "this person is online or not". The friends list has information > about where they are so you can IM them etc). From what we've > observed, the groups stuff works when the friends list doesn't - it > would be nice of you guys could confirm this. > > 2) When you initially log on and someone is not reported online > (because they aren't), is the system updating when they _do_ log on? > What I'm saying if either the friends list says everyone is off line, > then a friend logs on and it updates and says they *are* online, or > they *were* online, the friends list says they aren't - they relog - > does it show up correctly then? Again the code that gets the initial > list of friends and interrogates them to see if they are online or not > is not the same system that reports a friend has logged on (or off) - > it uses some of the same paths but it's not entirely the same. > > 3) Are we seeing an initial friends list situation where *select* > people are not being reported as online, or everyone? > > 4) What does it take for a friend you know is online to show up as > online in the friends list if they are initially not shown? > > The answers to this will help up determine exactly what's broken and > whether we can fix it or whether it'll be easier to just try a new way > of doing it. > > Either way, I want you guys to know we are on this - it's a top > priority with LL. > > Jake > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From adam at gwala.net Thu Jul 12 21:37:40 2007 From: adam at gwala.net (Adam Frisby) Date: Thu Jul 12 21:37:55 2007 Subject: [sldev] SLDev & QA: Open Source Release-Candidate Repository In-Reply-To: <4696C2EE.5060200@dzonux.net> References: <4696C2EE.5060200@dzonux.net> Message-ID: <46970194.6070404@gwala.net> Sounds like a great idea. Adam Dzonatas wrote: > Inspired from the Open Source Meeting, I'm making available the Open > Second Life Community Code (OSLCC) repository for those that wish to > participate in Quality Assurance on contributions from the open source > community. > > What is desired is a refined process to track patches and other changes > being made to Second Life from resident developers. > > OSLCC currently resides on SourceForge, which is powerful but has its > limits. I will to host OSLCC upon resolution of my contract, as there > exists a ready option to upgrade the immediate bandwidth to my server. > Of course, I'll have to be able to cover the cost; hence, a possible > resolution to the contract. > > The OSLCC repository could be used to create auto-builds of resident > made patches and further develop Q&A processes to formalize intake to > the official build hosted by Linden Lab. > > This would not be an overnight solution; therefore, we have the SF > location for now. I can grant developer access to post releases and > further grant svn access, if desired. > > Just e-mail back if you are interested to work together on this process. =) > > Perhaps, if successful with the repository, we can have a new mail-list > for residents that don't code but would like to help test new versions > of Second Life that are posted to the repository. > From jhurliman at wsu.edu Fri Jul 13 00:23:16 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Jul 13 00:24:59 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <4696E57D.4060100@ourstillwaters.org> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> <4696B436.1050408@dzonux.net> <4696E57D.4060100@ourstillwaters.org> Message-ID: <46972864.2040504@wsu.edu> Although our (libsecondlife's) main protocol documentation page has not been updated yet, there is a bit of info at http://www.libsecondlife.org/wiki/New_Protocol. Beyond that the next best source of documentation might be the latest libsecondlife source code, specifically the code in _Packets_.cs that parses packet headers. The compression on the rest of the packet hasn't changed, except that 6 bytes of the header are preserved (never zerocoded) now instead of the previous 4. You are correct about the "binary buckets" or undocumented struct fields. If you have any questions on a specific packet or field someone might be able to answer it. And yes, this diff is not useful at all: http://www.libsecondlife.org/template/release/diff-1.18.0.5.txt, not to mention that diffing message_template.msg will not tell you anything about changes in the packet headers. John Hurliman Joel Riedesel wrote: > Indeed a diff is normally useful. Except when every packet has changed. > And the template system doesn't describe the login xml rpc request. > And the template message file does not talk about the headers. > > (not to mention compressed data blocks where the parsing isn't > described in the template file) > > Cheers, > Joel > > > Dzonatas wrote: >> The message template file is pretty well human-readable. A simple >> "diff" command ran on the current and previous versions is very >> informative. >> >> Joel Riedesel wrote: >>> Hello. >>> The message templates changed to a version 2.0 in the 1.18 update. >>> Message headers appear to have been changed as well allowing for 32 bit >>> sequence numbers instead of 24 bit. I think. >>> >>> I haven't been able to find any documentation on protocol changes for >>> 1.18, is that available somewhere? Has the login data changed at all? >>> My initial login comes back with a circuit code, etc., but my first >>> packet never gets a response (UseCircuitCode) which leads me to believe >>> that I still do not have it constructed properly for the 1.18 update. >>> (Although network sniffing makes me think I have my packet constructed >>> properly as compared against what the SL Viewer is sending.) >>> >>> No problems until the 1.18 update was rolled out. >>> >>> I am not using the SL Viewer source code for my SL client. Thus it >>> is a >>> bit of a pain when the protocol changes without supporting >>> documentation >>> (and if I'm wrong about that please correct me). >>> >>> Joel >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >>> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From alissa_sabre at yahoo.co.jp Fri Jul 13 03:54:37 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jul 13 03:54:50 2007 Subject: [sldev] Japanese SDL support. Message-ID: <20070713105437.88763.qmail@web2201.mail.yahoo.co.jp> > I have been told by a Japanese user that all Japanese linux users must > apply this patch to get usable input. Yes. > Is this already in Jira and I missed it? It is in JIRA. VWR-240. > can this patch be merged into the > distribution? I guess the author will need to have a contribution > agreement if they don't already. I wrote the patch, and I have signed the SL contribution agreement. However, the patch is against SDL, not SL viewer. I have sent the patch to SDL developpers and is already merged in the latest SVN repository (of SDL.) The SDL team is about to release the next version, SDL 1.2.12, hopefully on this weekend. The patch will be a part of the version. The plan is, in my understanding, that we will wait for the official release of SDL 1.2.12, then replace the libSDL.so distributed with the SL Viewer with that of SDL 1.2.12. I've been running SDL 1.2.12 code with SL Viewer 1.17.* series for about two weeks and with 1.18.0.6 recently, and having no problem. The PRERELEASE of SDL 1.2.12 is waiting for you to test at http://www.libsdl.org/tmp/sdl-1.2.12.tar.gz BTW, I'm receiving a same report from several Japanese Ubuntu users. I don't know the cause. If anyone has a clue, please let me know. They say something like this: Downloaded and expanded LL official viewer distribution for Linux, fixed unicode.ttf symbolic link, then started the secondlife. It run fine (except that Japanese input is impossible.) Downloaded the latest SDL source (containing my patch) and built. Copied the resulting libSDL-1.2.so.0 to the Second Life viewer's lib directory, overwriting the one come with the viewer. Started the viewer. It didn't work! Then, downloaded the Ubuntu SDL-1.2 package with apt-get. Also downloaded all packages listed as "build-depends" on SDL-1.2 and installed them. Started the viewer. It now worked fine. Japanese input is OK. Based on the reports, I guess the problem is a package that my patched version of SDL depends but the original SDL doesn't. What I'm not sure is what package it is. The behaviour seems strange, since I believe my patch didn't add any additinal dependency... -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From gigstaggart at gmail.com Fri Jul 13 04:50:29 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jul 13 04:50:55 2007 Subject: [sldev] Japanese SDL support. In-Reply-To: <20070713105437.88763.qmail@web2201.mail.yahoo.co.jp> References: <20070713105437.88763.qmail@web2201.mail.yahoo.co.jp> Message-ID: <46976705.9030900@gmail.com> Alissa Sabre wrote: > > Started the viewer. It didn't work! It didn't work meaning what? I was helping a japanese user and he was getting a "black screen" with nothing, before the login screen was displayed. Moving KDU out of the way and letting OpenJPEG take over fixed that for him, but he reports it's still crashy. -Jason From hud at zurich.ibm.com Fri Jul 13 01:40:21 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Fri Jul 13 05:39:08 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: <20070630152148.B4C7A41B023@stupor.lindenlab.com> <75DB08AE-BC2C-4353-A148-C7DC9C092D9B@gmail.com> <2925011a0707020835g11e25342oc1e73f3ed8b19058@mail.gmail.com> <7b3a84fb0707020958s1e6d3e6vc2d5b62cfaa0980e@mail.gmail.com> <5A01C0A2-D226-4B56-A057-9956D289C3C1@gmail.com> <46894878.9040307@dzonux.net> Message-ID: <46973A75.1020300@zurich.ibm.com> Argent Stonecutter wrote: > [...] > Right now I get the closest thing to "complete ownership of land" on > the sims that Linden Labs most closely controls. Where Linden Labs > control is weaker, my ability to own land is weaker... that is, on a > private island even if I buy land it's only rented. > > Why would you expect a private server owner to provide me more > "ownership" of land than a private sim owner? > > Or are you equating "owning land" to "owning a sim"? > > Even there you're beholden to Linden Labs for the access to the grid, > to an ISP for access to the Internet, and to a hosting site for power > and maintenance. if you can run your own sim on your own server(s) --- and that includes all the necessary sub-services --- then you are more independent, in the worst case it would just be your sim. sure you still have to pay for power, etc. we are looking at scenarios where our customers would like to have a (completely?) detached grid with very high reliability. would that help Linden Lab? perhaps not directly. then there are scenarios where you'd like to have your own grid but connect that to the linden grid because of its huge wealth of content --- and that will probably mean some kind of interconnect fee or certification fee or at the very least a legally binding contract if you want "fully trusted" status. > > "Land" in SL is the thing that seems hardest to treat as something you > "own" rather than "rent". Land is processor time that you rent, that's > all. > > The *configuration* of that land and the *contents* of that land, > maybe, but there you run into the property rights problem that I > started with: when you buy some asset in SL you're rarely buying > unlimited rights to that asset. If you can take that out of SL you're > taking more rights than you're entitled to. IMHO, you are right about that --- the DRM "solution" is *not* going to work, as the assets need to be "played" on the sims they are being used on. so, obviously we are going to have situations where assets will not be exportable unless you have full rights to them or the grid you are exporting to is trusted by the originating grid. let's look at the situation where you have untrusted grids that you want to export to: we only have problems with that for restricted rights assets (RRAs); full right assets (FRAs) are no problem, i can already copy/modify/transfer those to my hearts content. so, what's going to happen is that * the FRA version of an asset is going to be quite a bit more expensive than the non-exportable RRA version (you pay for the exportability) * the FRA version is not going to be available (the RIAA/DRM "solution") * the FRA version is going to be available for free with no RRA version being available (the open source way of life) > [...] > That's what I'm going on about, here. What kinds of things could be > done to accommodate people who want to control their "real estate" in > Second Life without wrecking the economy of Second Life. we don't really need to look that far: we have all of that already in RL. i've bought very little SW in the last 10 years (and i'm very careful about adhering to the licenses of SW i'm using), likewise i've only bought music in the last 10 years that i've full control over (i.e., no DRM-ed stuff). is the economy suffering from me? looking at how fast my monthly pay check disappears: don't think so. one thing is certain: we will have non-linden operated grids. period. it's just a question of how those grid will inter-connect. cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070713/52cf811e/signature.pgp From hud at zurich.ibm.com Fri Jul 13 02:22:44 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Fri Jul 13 05:39:15 2007 Subject: XML Re: [sldev] Opening the server source? In-Reply-To: <20070706190741.GA21402@bruno.sbruno> References: <002901c7bf4b$73d9e260$08061f52@tomhome> <468E4826.1010705@dzonux.net> <20070706190741.GA21402@bruno.sbruno> Message-ID: <46974464.5040201@zurich.ibm.com> dale@daleglass.net wrote: > On Fri, Jul 06, 2007 at 06:48:22AM -0700, Dzonatas wrote: > > [...] > The nice thing about XML is that it's extensible -- it takes serious > work to design such a format that you can add something extra without > breaking backwards compatibility. > didn't certain encodings of ASN.1 support skipping over unknown types? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070713/d941445c/signature.pgp From dzonatas at dzonux.net Fri Jul 13 06:58:23 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 13 06:58:14 2007 Subject: [sldev] "Tim Lister on Project Sluts and Strawmen" - Slashdotted Q&A bits Message-ID: <469784FF.6030900@dzonux.net> How can you blame anybody when you know your working with a strawman project to help people articulate? For those into Q&A and missed or didn't see the slashdotted article: / "Tim Lister, principal of Atlantic Systems Guild and co-author of 'Waltzing with Bears: Managing Software Project Risk,' and 'Peopleware: Productive Projects and Teams' talks about the patterns that help determine software success or failure . Patterns good and bad include project sluts, Brownian motion, the strawman, and the safety valve."/ ---- July 12, 2007 From project sluts to strawmen: An interview with Tim Lister Tim Lister is a principal of Atlantic Systems Guild and co-author of the acclaimed books, /Waltzing with Bears: Managing Software Project Risk/, and /Peopleware: Productive Projects and Teams. /Freelance writer Bob Cramblitt spoke with Lister about the patterns that help determine software success or failure. *Cramblitt: /You're working on a new book. Tell us a bit about it./* *Lister:* Actually I'm working on it with the five other principals of Atlantic Systems Guild. The book is tentatively titled /Project Patterns: From Adrenalin Junkies to Template Zombies/. It's a series of nearly 100 short essays on project patterns for good and bad. If they are healthy patterns, we talk about how you promote them within the organization. If they are dysfunctional, we tell you how to stop them. *Cramblitt: /Let's start with the bad ones. What are three things that project teams can do to ensure failure?/* *Lister:* One is what we call /Brownian Motion/, based on the physics term defining a constant state of random motion. In our definition, it means loading a project with people when you still haven't decided what you are actually going to do. Another pattern is /project sluts/ -- organizations that can't say no; they have far too many projects for the staff they have, and things never get done. We also see a pattern called /dead fish/. This is a project that is doomed from the start because the schedule is outrageously unrealistic. *Cramblitt: /What are some good patterns?/* *Lister:* One of the best is /strawman/: building low-fidelity, low-cost prototypes for projects even if you know the approach isn't right. Strawman projects help you discover where you are going wrong early on, and help people articulate what they want and need. /Seasons for change/ is a pattern that specifies that changes will be made only during certain windows of time, avoiding problems with constant tinkering. /Testing before testing/ describes a pattern of doing quality assurance in parallel with the project, instead of waiting until the end. This helps everyone understand project specs in the early stages of the project. /Safety valve/ is another one. People involved in projects need to blow off steam and do goofy things like jump up in the afternoon and go bowling. There are other things related to this that are important too, such as sharing food, and setting up opportunities for people to get to know one another outside of work. My dad once said, "it's hard to hate someone when you know their name." *Cramblitt: /Has project management improved in the 20 years since you co-wrote /Peopleware/?/* *Lister:* Yes, I think so. More organizations realize that system building is a deeply human activity, rather than a high-tech, engineering effort. People are looking at bigger projects differently. Good organizations aren't doing things in a ballistic way -- where you aim a gun, shoot, and the bullet goes where it goes. The new approach is more like driving a car: you drive a bit and if don't like where you are going, you steer in a different direction. I think the agile development people have a tiger by the tail. They don't attempt to build a perfect spec that will be the bible for the next two years of development. Instead, the approach is to spec a little, build a little, run it by people and get some feedback, then get another cycle going, continuing until you hit the moving target. Larger projects are much riskier, and agile development is a way to minimize risk. *Cramblitt: /What do you think about the reliance on best practices?/* *Lister:* I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development. All projects are related to the domain they're in. A best practice for defibrillator software is not the best practice in another domain. I'd like people to think about patterns -- abstracting their work and recognizing the patterns they're in, good and bad, and making informed decisions to promote those patterns or replace them. /Tim Lister will talk about project sluts, strawmen, safety valves and much more at the Business of Software 2007 conference, October 29-30 in San Jose. / -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070713/060fb965/attachment-0001.htm From sl at phoca.com Fri Jul 13 09:20:05 2007 From: sl at phoca.com (Second Life) Date: Fri Jul 13 09:20:18 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469691A1.4090104@lindenlab.com> References: <469691A1.4090104@lindenlab.com> Message-ID: <4074C793DF5C4B1093F716C3705348E5@SanMiguel> Although I've yet to do any specific analysis, the MAIN thing that very obviously fails most often is that upon initial log-on the friends list does not completely show the true state of friends on line. It may be empty or have one or two or half or 3/4 of the correct list. HEN as people come and go or you IM them "Ping" blindly, they get added to the list. One thing that might help is if there was some way to "refresh" the list (Obviously at a frequency that didn't overload things). Logging off and back on will sometimes fix it. It seems like the initial request of all friends is done once upon login and if that fails you are screwed till you relog or ping everyone you want to talk to. However... there are also obvious cases where log-ins and log-outs of friends goes unnoticed by the client. Someone will log in with no notice, then IM you later and THEN you get the "XXX has just connected" message even though they have been on line for 10 minutes already. As well as the reverse: trying to map someone that shows on line but then the map cant find them because they are actually off line. So in general it just seems like the information gets lost somewhere. Some days never and some days up to 100%. BTW, Although the mantra is "use the website friends list" I have also found THAT to be unreliable. Showing maybe 3/4 of who is on at times. Though it does seem /more/ accurate than the client when there are problems, it is definitely 100% reliable though. Farallon ----- Original Message ----- From: "Jake Simpson" To: Sent: Thursday, July 12, 2007 1:40 PM Subject: [sldev] Re:SVC-85 - friends lists not working > Peeps, > > I'm just going to re post this set of questions I added into the comments > of SVC-85 - https://jira.secondlife.com/browse/SVC-85 (friends lists not > always working to show online presence correctly) just to see if any of > you guys have run into this, and if you do, if you could look into the > results of the questions. I would like to get this fixed but I need some > more data before I can get it done right. > > Thanks > > OK, so I'm looking into this since it's obviously a bug of much > contention. You can't have much of a second life if you can't see anyone > to share it with. > > Kelly and I have been talking about approaches to fixing this - the code > as it stands _should_ work correctly because in many circumstances it > does. However, the code behind this is pretty knarly and has many places > of potential failure, so Kelly and I have come up with a new way to deal > with this (based on how we do group online presence reporting), using our > new back bone system the way it should be used. > > With a view to doing that, I have a couple of questions for you guys. > > 1) When you know someone is on line, even though the friends list says > they are not, do they show up as online in the groups list (assuming you > know they are subscribed to one of the same groups as you)? The code that > the groups uses to determine online presence is actually different from > the code that the friends list uses (it's older code and also the friends > list returns a lot more information regarding the friends themselves than > the groups list does - that just has enough to say "this person is online > or not". The friends list has information about where they are so you can > IM them etc). From what we've observed, the groups stuff works when the > friends list doesn't - it would be nice of you guys could confirm this. > > 2) When you initially log on and someone is not reported online (because > they aren't), is the system updating when they _do_ log on? What I'm > saying if either the friends list says everyone is off line, then a friend > logs on and it updates and says they *are* online, or they *were* online, > the friends list says they aren't - they relog - does it show up correctly > then? Again the code that gets the initial list of friends and > interrogates them to see if they are online or not is not the same system > that reports a friend has logged on (or off) - it uses some of the same > paths but it's not entirely the same. > > 3) Are we seeing an initial friends list situation where *select* people > are not being reported as online, or everyone? > > 4) What does it take for a friend you know is online to show up as online > in the friends list if they are initially not shown? > > The answers to this will help up determine exactly what's broken and > whether we can fix it or whether it'll be easier to just try a new way of > doing it. > > Either way, I want you guys to know we are on this - it's a top priority > with LL. > > Jake > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Fri Jul 13 09:34:14 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 13 09:34:27 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <4074C793DF5C4B1093F716C3705348E5@SanMiguel> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> Message-ID: <4697A986.2080202@blueflash.cc> One thing that I observe frequently is that I'm getting IM's into email while I have been logged in. Sometimes even a conversation ends in the middle over IM and I later found that the other person continued to talk but their stuff ended up in my email rather than in my window. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Second Life wrote: > Although I've yet to do any specific analysis, the MAIN thing that very > obviously fails most often is that upon initial log-on the friends list > does not completely show the true state of friends on line. It may be > empty or have one or two or half or 3/4 of the correct list. HEN as > people come and go or you IM them "Ping" blindly, they get added to the > list. > > One thing that might help is if there was some way to "refresh" the list > (Obviously at a frequency that didn't overload things). Logging off and > back on will sometimes fix it. It seems like the initial request of all > friends is done once upon login and if that fails you are screwed till > you relog or ping everyone you want to talk to. > > However... there are also obvious cases where log-ins and log-outs of > friends goes unnoticed by the client. Someone will log in with no > notice, then IM you later and THEN you get the "XXX has just connected" > message even though they have been on line for 10 minutes already. As > well as the reverse: trying to map someone that shows on line but then > the map cant find them because they are actually off line. > > So in general it just seems like the information gets lost somewhere. > Some days never and some days up to 100%. > > BTW, Although the mantra is "use the website friends list" I have also > found THAT to be unreliable. Showing maybe 3/4 of who is on at times. > Though it does seem /more/ accurate than the client when there are > problems, it is definitely 100% reliable though. > > Farallon > > ----- Original Message ----- From: "Jake Simpson" > To: > Sent: Thursday, July 12, 2007 1:40 PM > Subject: [sldev] Re:SVC-85 - friends lists not working > > >> Peeps, >> >> I'm just going to re post this set of questions I added into the >> comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 >> (friends lists not always working to show online presence correctly) >> just to see if any of you guys have run into this, and if you do, if >> you could look into the results of the questions. I would like to get >> this fixed but I need some more data before I can get it done right. >> >> Thanks >> >> OK, so I'm looking into this since it's obviously a bug of much >> contention. You can't have much of a second life if you can't see >> anyone to share it with. >> >> Kelly and I have been talking about approaches to fixing this - the >> code as it stands _should_ work correctly because in many >> circumstances it does. However, the code behind this is pretty knarly >> and has many places of potential failure, so Kelly and I have come up >> with a new way to deal with this (based on how we do group online >> presence reporting), using our new back bone system the way it should >> be used. >> >> With a view to doing that, I have a couple of questions for you guys. >> >> 1) When you know someone is on line, even though the friends list says >> they are not, do they show up as online in the groups list (assuming >> you know they are subscribed to one of the same groups as you)? The >> code that the groups uses to determine online presence is actually >> different from the code that the friends list uses (it's older code >> and also the friends list returns a lot more information regarding the >> friends themselves than the groups list does - that just has enough to >> say "this person is online or not". The friends list has information >> about where they are so you can IM them etc). From what we've >> observed, the groups stuff works when the friends list doesn't - it >> would be nice of you guys could confirm this. >> >> 2) When you initially log on and someone is not reported online >> (because they aren't), is the system updating when they _do_ log on? >> What I'm saying if either the friends list says everyone is off line, >> then a friend logs on and it updates and says they *are* online, or >> they *were* online, the friends list says they aren't - they relog - >> does it show up correctly then? Again the code that gets the initial >> list of friends and interrogates them to see if they are online or not >> is not the same system that reports a friend has logged on (or off) - >> it uses some of the same paths but it's not entirely the same. >> >> 3) Are we seeing an initial friends list situation where *select* >> people are not being reported as online, or everyone? >> >> 4) What does it take for a friend you know is online to show up as >> online in the friends list if they are initially not shown? >> >> The answers to this will help up determine exactly what's broken and >> whether we can fix it or whether it'll be easier to just try a new way >> of doing it. >> >> Either way, I want you guys to know we are on this - it's a top >> priority with LL. >> >> Jake >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Fri Jul 13 10:08:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 13 10:08:38 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <4697B02E.2090800@lindenlab.com> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> <4697A986.2080202@blueflash.cc> <4697B02E.2090800@lindenlab.com> Message-ID: <4697B18B.4000603@blueflash.cc> Another think, if that is relevant, I know a person who makes a friends hud. This seem to work reliably. Can try to dig out the name if you want to contact her to check how she gets the online info. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Jake Simpson wrote: > Thanks > I have a feeling that's a different issue (although some messaging does > use some of the same code paths as the system we are investigating) - > it's worth me having a quick peek at though. Good thinking. > > Jake > > Nicholaz Beresford wrote: >> >> One thing that I observe frequently is that I'm getting >> IM's into email while I have been logged in. Sometimes >> even a conversation ends in the middle over IM and I later >> found that the other person continued to talk but their >> stuff ended up in my email rather than in my window. >> >> >> Nick >> >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Second Life wrote: >>> Although I've yet to do any specific analysis, the MAIN thing that >>> very obviously fails most often is that upon initial log-on the >>> friends list does not completely show the true state of friends on >>> line. It may be empty or have one or two or half or 3/4 of the >>> correct list. HEN as people come and go or you IM them "Ping" >>> blindly, they get added to the list. >>> >>> One thing that might help is if there was some way to "refresh" the >>> list (Obviously at a frequency that didn't overload things). Logging >>> off and back on will sometimes fix it. It seems like the initial >>> request of all friends is done once upon login and if that fails you >>> are screwed till you relog or ping everyone you want to talk to. >>> >>> However... there are also obvious cases where log-ins and log-outs of >>> friends goes unnoticed by the client. Someone will log in with no >>> notice, then IM you later and THEN you get the "XXX has just >>> connected" message even though they have been on line for 10 minutes >>> already. As well as the reverse: trying to map someone that shows on >>> line but then the map cant find them because they are actually off line. >>> >>> So in general it just seems like the information gets lost somewhere. >>> Some days never and some days up to 100%. >>> >>> BTW, Although the mantra is "use the website friends list" I have >>> also found THAT to be unreliable. Showing maybe 3/4 of who is on at >>> times. Though it does seem /more/ accurate than the client when there >>> are problems, it is definitely 100% reliable though. >>> >>> Farallon >>> >>> ----- Original Message ----- From: "Jake Simpson" >>> To: >>> Sent: Thursday, July 12, 2007 1:40 PM >>> Subject: [sldev] Re:SVC-85 - friends lists not working >>> >>> >>>> Peeps, >>>> >>>> I'm just going to re post this set of questions I added into the >>>> comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 >>>> (friends lists not always working to show online presence correctly) >>>> just to see if any of you guys have run into this, and if you do, if >>>> you could look into the results of the questions. I would like to >>>> get this fixed but I need some more data before I can get it done >>>> right. >>>> >>>> Thanks >>>> >>>> OK, so I'm looking into this since it's obviously a bug of much >>>> contention. You can't have much of a second life if you can't see >>>> anyone to share it with. >>>> >>>> Kelly and I have been talking about approaches to fixing this - the >>>> code as it stands _should_ work correctly because in many >>>> circumstances it does. However, the code behind this is pretty >>>> knarly and has many places of potential failure, so Kelly and I have >>>> come up with a new way to deal with this (based on how we do group >>>> online presence reporting), using our new back bone system the way >>>> it should be used. >>>> >>>> With a view to doing that, I have a couple of questions for you guys. >>>> >>>> 1) When you know someone is on line, even though the friends list >>>> says they are not, do they show up as online in the groups list >>>> (assuming you know they are subscribed to one of the same groups as >>>> you)? The code that the groups uses to determine online presence is >>>> actually different from the code that the friends list uses (it's >>>> older code and also the friends list returns a lot more information >>>> regarding the friends themselves than the groups list does - that >>>> just has enough to say "this person is online or not". The friends >>>> list has information about where they are so you can IM them etc). >>>> From what we've observed, the groups stuff works when the friends >>>> list doesn't - it would be nice of you guys could confirm this. >>>> >>>> 2) When you initially log on and someone is not reported online >>>> (because they aren't), is the system updating when they _do_ log on? >>>> What I'm saying if either the friends list says everyone is off >>>> line, then a friend logs on and it updates and says they *are* >>>> online, or they *were* online, the friends list says they aren't - >>>> they relog - does it show up correctly then? Again the code that >>>> gets the initial list of friends and interrogates them to see if >>>> they are online or not is not the same system that reports a friend >>>> has logged on (or off) - it uses some of the same paths but it's not >>>> entirely the same. >>>> >>>> 3) Are we seeing an initial friends list situation where *select* >>>> people are not being reported as online, or everyone? >>>> >>>> 4) What does it take for a friend you know is online to show up as >>>> online in the friends list if they are initially not shown? >>>> >>>> The answers to this will help up determine exactly what's broken and >>>> whether we can fix it or whether it'll be easier to just try a new >>>> way of doing it. >>>> >>>> Either way, I want you guys to know we are on this - it's a top >>>> priority with LL. >>>> >>>> Jake >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jake at lindenlab.com Fri Jul 13 10:09:43 2007 From: jake at lindenlab.com (Jake Simpson) Date: Fri Jul 13 10:09:52 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <4074C793DF5C4B1093F716C3705348E5@SanMiguel> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> Message-ID: <4697B1D7.4090208@lindenlab.com> "One thing that might help is if there was some way to "refresh" the list (Obviously at a frequency that didn't overload things)." We looked at this - the trouble is the way that the system says "Give me that list of people" is also the same system that says - at the same time - "I am logged on all you wonderful people - please update your friends lists" to all those people who are logged on. Without knowing if this problem is both ways (ie those people you can't see the correct status of can't see you), it may be a bit much to ask of the system. To be honest, I'd rather fix the issue at root so we don't have to refresh the list, and that it just work as it's supposed to? Jake Second Life wrote: > Although I've yet to do any specific analysis, the MAIN thing that > very obviously fails most often is that upon initial log-on the > friends list does not completely show the true state of friends on > line. It may be empty or have one or two or half or 3/4 of the correct > list. HEN as people come and go or you IM them "Ping" blindly, they > get added to the list. > > One thing that might help is if there was some way to "refresh" the > list (Obviously at a frequency that didn't overload things). Logging > off and back on will sometimes fix it. It seems like the initial > request of all friends is done once upon login and if that fails you > are screwed till you relog or ping everyone you want to talk to. > > However... there are also obvious cases where log-ins and log-outs of > friends goes unnoticed by the client. Someone will log in with no > notice, then IM you later and THEN you get the "XXX has just > connected" message even though they have been on line for 10 minutes > already. As well as the reverse: trying to map someone that shows on > line but then the map cant find them because they are actually off line. > > So in general it just seems like the information gets lost somewhere. > Some days never and some days up to 100%. > > BTW, Although the mantra is "use the website friends list" I have also > found THAT to be unreliable. Showing maybe 3/4 of who is on at times. > Though it does seem /more/ accurate than the client when there are > problems, it is definitely 100% reliable though. > > Farallon > > ----- Original Message ----- From: "Jake Simpson" > To: > Sent: Thursday, July 12, 2007 1:40 PM > Subject: [sldev] Re:SVC-85 - friends lists not working > > >> Peeps, >> >> I'm just going to re post this set of questions I added into the >> comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 >> (friends lists not always working to show online presence correctly) >> just to see if any of you guys have run into this, and if you do, if >> you could look into the results of the questions. I would like to get >> this fixed but I need some more data before I can get it done right. >> >> Thanks >> >> OK, so I'm looking into this since it's obviously a bug of much >> contention. You can't have much of a second life if you can't see >> anyone to share it with. >> >> Kelly and I have been talking about approaches to fixing this - the >> code as it stands _should_ work correctly because in many >> circumstances it does. However, the code behind this is pretty knarly >> and has many places of potential failure, so Kelly and I have come up >> with a new way to deal with this (based on how we do group online >> presence reporting), using our new back bone system the way it should >> be used. >> >> With a view to doing that, I have a couple of questions for you guys. >> >> 1) When you know someone is on line, even though the friends list >> says they are not, do they show up as online in the groups list >> (assuming you know they are subscribed to one of the same groups as >> you)? The code that the groups uses to determine online presence is >> actually different from the code that the friends list uses (it's >> older code and also the friends list returns a lot more information >> regarding the friends themselves than the groups list does - that >> just has enough to say "this person is online or not". The friends >> list has information about where they are so you can IM them etc). >> From what we've observed, the groups stuff works when the friends >> list doesn't - it would be nice of you guys could confirm this. >> >> 2) When you initially log on and someone is not reported online >> (because they aren't), is the system updating when they _do_ log on? >> What I'm saying if either the friends list says everyone is off line, >> then a friend logs on and it updates and says they *are* online, or >> they *were* online, the friends list says they aren't - they relog - >> does it show up correctly then? Again the code that gets the initial >> list of friends and interrogates them to see if they are online or >> not is not the same system that reports a friend has logged on (or >> off) - it uses some of the same paths but it's not entirely the same. >> >> 3) Are we seeing an initial friends list situation where *select* >> people are not being reported as online, or everyone? >> >> 4) What does it take for a friend you know is online to show up as >> online in the friends list if they are initially not shown? >> >> The answers to this will help up determine exactly what's broken and >> whether we can fix it or whether it'll be easier to just try a new >> way of doing it. >> >> Either way, I want you guys to know we are on this - it's a top >> priority with LL. >> >> Jake >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From jake at lindenlab.com Fri Jul 13 10:03:32 2007 From: jake at lindenlab.com (Jake Simpson) Date: Fri Jul 13 10:20:24 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <4696F913.3090105@gmail.com> References: <469691A1.4090104@lindenlab.com> <4696F913.3090105@gmail.com> Message-ID: <4697B064.2040400@lindenlab.com> Thats an interesting take on it. That would mean this is timing out on a local CPU, not at the presence level. Yes, that make sense. If the backbone was the problem then *everyone* would see this issue. Thanks - all good information and thinking here. SL Devs rock! Jake Tateru Nino wrote: > 3) Specific simulators generally tend to be at fault. If simulator A > begins to exhibit the problem behaviour, then no presence information is > received from people logging in to simulator A, nor do people in > simulator A receive presence information, until the sim restarts. > Caveat: It's a little more likely that a logoff notification will be > received than a login notification. When the issue has been at its > worst, perhaps 15% of simulators have been affected. There seems to be > more than one issue, and given simulators (some seem more prone to it > than others) getting themselves in a bunch seems to be one of them. > > Jake Simpson wrote: > >> Peeps, >> >> I'm just going to re post this set of questions I added into the >> comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 >> (friends lists not always working to show online presence correctly) >> just to see if any of you guys have run into this, and if you do, if >> you could look into the results of the questions. I would like to get >> this fixed but I need some more data before I can get it done right. >> >> Thanks >> >> OK, so I'm looking into this since it's obviously a bug of much >> contention. You can't have much of a second life if you can't see >> anyone to share it with. >> >> Kelly and I have been talking about approaches to fixing this - the >> code as it stands _should_ work correctly because in many >> circumstances it does. However, the code behind this is pretty knarly >> and has many places of potential failure, so Kelly and I have come up >> with a new way to deal with this (based on how we do group online >> presence reporting), using our new back bone system the way it should >> be used. >> >> With a view to doing that, I have a couple of questions for you guys. >> >> 1) When you know someone is on line, even though the friends list says >> they are not, do they show up as online in the groups list (assuming >> you know they are subscribed to one of the same groups as you)? The >> code that the groups uses to determine online presence is actually >> different from the code that the friends list uses (it's older code >> and also the friends list returns a lot more information regarding the >> friends themselves than the groups list does - that just has enough to >> say "this person is online or not". The friends list has information >> about where they are so you can IM them etc). From what we've >> observed, the groups stuff works when the friends list doesn't - it >> would be nice of you guys could confirm this. >> >> 2) When you initially log on and someone is not reported online >> (because they aren't), is the system updating when they _do_ log on? >> What I'm saying if either the friends list says everyone is off line, >> then a friend logs on and it updates and says they *are* online, or >> they *were* online, the friends list says they aren't - they relog - >> does it show up correctly then? Again the code that gets the initial >> list of friends and interrogates them to see if they are online or not >> is not the same system that reports a friend has logged on (or off) - >> it uses some of the same paths but it's not entirely the same. >> >> 3) Are we seeing an initial friends list situation where *select* >> people are not being reported as online, or everyone? >> >> 4) What does it take for a friend you know is online to show up as >> online in the friends list if they are initially not shown? >> >> The answers to this will help up determine exactly what's broken and >> whether we can fix it or whether it'll be easier to just try a new way >> of doing it. >> >> Either way, I want you guys to know we are on this - it's a top >> priority with LL. >> >> Jake >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > From phoenix at secondlife.com Fri Jul 13 10:59:14 2007 From: phoenix at secondlife.com (Phoenix) Date: Fri Jul 13 10:59:23 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <46969DFA.6020308@ourstillwaters.org> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> Message-ID: <0CD7DD4F-35C6-4E5A-AA5D-EE25958D35FB@secondlife.com> I have documented the new packet layout. Apologies for the lack of coordination with the release. Briefly, flags is 1 byte, sequence is 4 bytes, there's a skip byte and then as many bytes as found in the skip byte before the start of the payload. For details: https://wiki.secondlife.com/wiki/Packet_Layout On 2007/07/12, at 14:32, Joel Riedesel wrote: > Hello. > The message templates changed to a version 2.0 in the 1.18 update. > Message headers appear to have been changed as well allowing for 32 > bit > sequence numbers instead of 24 bit. I think. > > I haven't been able to find any documentation on protocol changes for > 1.18, is that available somewhere? Has the login data changed at all? > My initial login comes back with a circuit code, etc., but my first > packet never gets a response (UseCircuitCode) which leads me to > believe > that I still do not have it constructed properly for the 1.18 update. > (Although network sniffing makes me think I have my packet constructed > properly as compared against what the SL Viewer is sending.) > > No problems until the 1.18 update was rolled out. > > I am not using the SL Viewer source code for my SL client. Thus it > is a > bit of a pain when the protocol changes without supporting > documentation > (and if I'm wrong about that please correct me). > > Joel > _______________________________________________ > 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/20070713/ad0136b7/PGP.pgp From rdw at lindenlab.com Fri Jul 13 11:03:28 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Fri Jul 13 11:05:54 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <4696E4EF.9060405@ourstillwaters.org> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> <4696B5EC.50302@lindenlab.com> <4696E4EF.9060405@ourstillwaters.org> Message-ID: <4697BE70.8020107@lindenlab.com> Joel Riedesel wrote: > Yeah and the main protocol description page as well if the sequence > numbers really have changed from 24 bits to 32 bits. > > I didn't get the blog post the first time around, thanks. But it > doesn't give me anything of substance other than identifying why all > the packets are now numbered - makes sense. > > But anything about the login change? If not great. Must be something > amiss on my end. > There shouldn't be anything changed about login. If you're logging in with a version and channel string for a pre-1.18 viewer, then it'll get rejected, of course. The startup process used to contact the userserver, but now there is no userserver. It has been replaced by a very small python script. -RYaN From joel at ourstillwaters.org Fri Jul 13 11:42:32 2007 From: joel at ourstillwaters.org (Joel Riedesel) Date: Fri Jul 13 11:42:44 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <0CD7DD4F-35C6-4E5A-AA5D-EE25958D35FB@secondlife.com> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> <0CD7DD4F-35C6-4E5A-AA5D-EE25958D35FB@secondlife.com> Message-ID: <4697C798.9030105@ourstillwaters.org> Thanks! Turns out that my login problems were all due to this change which had some code impacts in a number of places (for my client code - not based on the SL Viewer code). Cheers, Joel Phoenix wrote: > I have documented the new packet layout. Apologies for the lack of > coordination with the release. > > Briefly, flags is 1 byte, sequence is 4 bytes, there's a skip byte and > then as many bytes as found in the skip byte before the start of the > payload. For details: > > https://wiki.secondlife.com/wiki/Packet_Layout > > > On 2007/07/12, at 14:32, Joel Riedesel wrote: > >> Hello. >> The message templates changed to a version 2.0 in the 1.18 update. >> Message headers appear to have been changed as well allowing for 32 bit >> sequence numbers instead of 24 bit. I think. >> >> I haven't been able to find any documentation on protocol changes for >> 1.18, is that available somewhere? Has the login data changed at all? >> My initial login comes back with a circuit code, etc., but my first >> packet never gets a response (UseCircuitCode) which leads me to believe >> that I still do not have it constructed properly for the 1.18 update. >> (Although network sniffing makes me think I have my packet constructed >> properly as compared against what the SL Viewer is sending.) >> >> No problems until the 1.18 update was rolled out. >> >> I am not using the SL Viewer source code for my SL client. Thus it is a >> bit of a pain when the protocol changes without supporting documentation >> (and if I'm wrong about that please correct me). >> >> Joel >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tateru.nino at gmail.com Fri Jul 13 12:16:43 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jul 13 12:16:55 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <4697B18B.4000603@blueflash.cc> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> <4697A986.2080202@blueflash.cc> <4697B02E.2090800@lindenlab.com> <4697B18B.4000603@blueflash.cc> Message-ID: <4697CF9B.8070605@gmail.com> llRequestAgentData() is rarely fooled. It is _sometimes_ fooled, but not very often compared to other notification. Nicholaz Beresford wrote: > > Another think, if that is relevant, I know a person > who makes a friends hud. This seem to work reliably. > Can try to dig out the name if you want to contact > her to check how she gets the online info. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Jake Simpson wrote: >> Thanks >> I have a feeling that's a different issue (although some messaging >> does use some of the same code paths as the system we are >> investigating) - it's worth me having a quick peek at though. Good >> thinking. >> >> Jake >> >> Nicholaz Beresford wrote: >>> >>> One thing that I observe frequently is that I'm getting >>> IM's into email while I have been logged in. Sometimes >>> even a conversation ends in the middle over IM and I later >>> found that the other person continued to talk but their >>> stuff ended up in my email rather than in my window. >>> >>> >>> Nick >>> >>> >>> >>> Second Life from the inside out: >>> http://nicholaz-beresford.blogspot.com/ >>> >>> >>> Second Life wrote: >>>> Although I've yet to do any specific analysis, the MAIN thing that >>>> very obviously fails most often is that upon initial log-on the >>>> friends list does not completely show the true state of friends on >>>> line. It may be empty or have one or two or half or 3/4 of the >>>> correct list. HEN as people come and go or you IM them "Ping" >>>> blindly, they get added to the list. >>>> >>>> One thing that might help is if there was some way to "refresh" the >>>> list (Obviously at a frequency that didn't overload things). >>>> Logging off and back on will sometimes fix it. It seems like the >>>> initial request of all friends is done once upon login and if that >>>> fails you are screwed till you relog or ping everyone you want to >>>> talk to. >>>> >>>> However... there are also obvious cases where log-ins and log-outs >>>> of friends goes unnoticed by the client. Someone will log in with >>>> no notice, then IM you later and THEN you get the "XXX has just >>>> connected" message even though they have been on line for 10 >>>> minutes already. As well as the reverse: trying to map someone that >>>> shows on line but then the map cant find them because they are >>>> actually off line. >>>> >>>> So in general it just seems like the information gets lost >>>> somewhere. Some days never and some days up to 100%. >>>> >>>> BTW, Although the mantra is "use the website friends list" I have >>>> also found THAT to be unreliable. Showing maybe 3/4 of who is on at >>>> times. Though it does seem /more/ accurate than the client when >>>> there are problems, it is definitely 100% reliable though. >>>> >>>> Farallon >>>> >>>> ----- Original Message ----- From: "Jake Simpson" >>>> To: >>>> Sent: Thursday, July 12, 2007 1:40 PM >>>> Subject: [sldev] Re:SVC-85 - friends lists not working >>>> >>>> >>>>> Peeps, >>>>> >>>>> I'm just going to re post this set of questions I added into the >>>>> comments of SVC-85 - https://jira.secondlife.com/browse/SVC-85 >>>>> (friends lists not always working to show online presence >>>>> correctly) just to see if any of you guys have run into this, and >>>>> if you do, if you could look into the results of the questions. I >>>>> would like to get this fixed but I need some more data before I >>>>> can get it done right. >>>>> >>>>> Thanks >>>>> >>>>> OK, so I'm looking into this since it's obviously a bug of much >>>>> contention. You can't have much of a second life if you can't see >>>>> anyone to share it with. >>>>> >>>>> Kelly and I have been talking about approaches to fixing this - >>>>> the code as it stands _should_ work correctly because in many >>>>> circumstances it does. However, the code behind this is pretty >>>>> knarly and has many places of potential failure, so Kelly and I >>>>> have come up with a new way to deal with this (based on how we do >>>>> group online presence reporting), using our new back bone system >>>>> the way it should be used. >>>>> >>>>> With a view to doing that, I have a couple of questions for you guys. >>>>> >>>>> 1) When you know someone is on line, even though the friends list >>>>> says they are not, do they show up as online in the groups list >>>>> (assuming you know they are subscribed to one of the same groups >>>>> as you)? The code that the groups uses to determine online >>>>> presence is actually different from the code that the friends list >>>>> uses (it's older code and also the friends list returns a lot more >>>>> information regarding the friends themselves than the groups list >>>>> does - that just has enough to say "this person is online or not". >>>>> The friends list has information about where they are so you can >>>>> IM them etc). From what we've observed, the groups stuff works >>>>> when the friends list doesn't - it would be nice of you guys could >>>>> confirm this. >>>>> >>>>> 2) When you initially log on and someone is not reported online >>>>> (because they aren't), is the system updating when they _do_ log >>>>> on? What I'm saying if either the friends list says everyone is >>>>> off line, then a friend logs on and it updates and says they *are* >>>>> online, or they *were* online, the friends list says they aren't - >>>>> they relog - does it show up correctly then? Again the code that >>>>> gets the initial list of friends and interrogates them to see if >>>>> they are online or not is not the same system that reports a >>>>> friend has logged on (or off) - it uses some of the same paths but >>>>> it's not entirely the same. >>>>> >>>>> 3) Are we seeing an initial friends list situation where *select* >>>>> people are not being reported as online, or everyone? >>>>> >>>>> 4) What does it take for a friend you know is online to show up as >>>>> online in the friends list if they are initially not shown? >>>>> >>>>> The answers to this will help up determine exactly what's broken >>>>> and whether we can fix it or whether it'll be easier to just try a >>>>> new way of doing it. >>>>> >>>>> Either way, I want you guys to know we are on this - it's a top >>>>> priority with LL. >>>>> >>>>> Jake >>>>> _______________________________________________ >>>>> Click here to unsubscribe or manage your list subscription: >>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From labrat.hb at gmail.com Fri Jul 13 12:33:27 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Jul 13 12:33:28 2007 Subject: [sldev] Another odd problem Message-ID: I've had these types of messages in the past. Haven't looked into why I get them before, figured now is a good time to bring it up :) They've always been from people I don't know... and as I'm obviously not online (since it went to my e-mail) I wasn't sending them a message to begin with. ---------- Forwarded message ---------- From: astrid Bekkers < ganu3fsn3sexdpmi5cwn3l2jtwovdkgiyfqvq6cgnyda5qhpr7dfcua2zbakec4e@im.agni.lindenlab.com > Date: Jul 13, 2007 10:53 AM Subject: Message From Second Life To: Thraxis Epsilon The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. The Resident you messaged is in 'busy mode' which means they have requested not to be disturbed. Your message will still be shown in their IM panel for later viewing. --- To stop receiving these emails, log in to Second Life and uncheck "Send IM to Email" in the General tab of the Preferences window or visit: http://secondlife.com/account/im_off.php?k=ganu3fsn3sexdpmi5cwn3l2jtwovdkgiyfqvq6cgnyda5qhpr7dfcua2zbakec4e -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070713/1acbcf4e/attachment.htm From nicholaz at blueflash.cc Fri Jul 13 13:48:40 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 13 13:48:49 2007 Subject: [sldev] performance with LLPointer Message-ID: <4697E528.6070104@blueflash.cc> Does anyone know if using LLPointers over regular C++ pointers will cause performance issues? I have an area (LLFace*) where I'm considering to rewrite the viewer to pointers, but these seem heavily performance related. Comments? Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Fri Jul 13 13:52:58 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 13 13:52:46 2007 Subject: [sldev] OSLCC SecondLife-1.18.0.6.OS.0 released Message-ID: <4697E62A.4060103@dzonux.net> Last file release on OSLCC did pretty well with over 200 downloads in an early June week. Here is an update: http://sourceforge.net/project/showfiles.php?group_id=191214 It contains the same VWR-1110 patch as before but with the updated source to 1.18. Instead of naming scheme like MyPopularNameEdition, I decided to go with something more anonymous like OS for Open Source editions. That way we all can get fair credit for the team effort! SecondLife-1.18.0.6.OS.0 is a debug enabled build. Hopefully, with the new dia de la liberacion, we are able to switch more easily between the aditi and agni grids to be more productive with the open source movements and testing. Hehe... instead of OS... I was thinking of calling this ThirdLife. Let me know what patches you want included in the next build. An installer for the Windows version that sets up a separate main directory and settings file would be awesome, so it doesn't have to depend on the official SecondLife install. =) Dz -- Power to Change the Void From nicholaz at blueflash.cc Fri Jul 13 14:01:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 13 14:02:10 2007 Subject: [sldev] OSLCC SecondLife-1.18.0.6.OS.0 released In-Reply-To: <4697E62A.4060103@dzonux.net> References: <4697E62A.4060103@dzonux.net> Message-ID: <4697E847.3070109@blueflash.cc> Hi Dzon, I can send you the whole set from my build (sans the cosmetic ones) if you like. They're all running live out there (and a few brand new ones). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dzonatas wrote: > Last file release on OSLCC did pretty well with over 200 downloads in an > early June week. > > Here is an update: > http://sourceforge.net/project/showfiles.php?group_id=191214 > > It contains the same VWR-1110 patch as before but with the updated > source to 1.18. > > Instead of naming scheme like MyPopularNameEdition, I decided to go with > something more anonymous like OS for Open Source editions. That way we > all can get fair credit for the team effort! > > SecondLife-1.18.0.6.OS.0 is a debug enabled build. Hopefully, with the > new dia de la liberacion, we are able to switch more easily between the > aditi and agni grids to be more productive with the open source > movements and testing. > > Hehe... instead of OS... I was thinking of calling this ThirdLife. > > Let me know what patches you want included in the next build. > > An installer for the Windows version that sets up a separate main > directory and settings file would be awesome, so it doesn't have to > depend on the official SecondLife install. =) > > Dz > From bos at lindenlab.com Fri Jul 13 14:08:00 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Jul 13 14:08:03 2007 Subject: [sldev] performance with LLPointer In-Reply-To: <4697E528.6070104@blueflash.cc> References: <4697E528.6070104@blueflash.cc> Message-ID: <4697E9B0.7000509@lindenlab.com> Nicholaz Beresford wrote: > Does anyone know if using LLPointers over regular C++ > pointers will cause performance issues? It can, because of the need to constantly update refcounts. That imposes a small compute overhead and has something of a cache impact. How measurable is hard to say, but I wouldn't want to be fiddling with LLPointers in a place I knew was an inner loop. At least sometimes, you can amortise this cost by using an LLPointer& instead of a plain LLPointer. However, the more scary potential problem is of objects being kept alive by references when they would not otherwise be. There are two ways this can happen: one is circular references, which are extremely hard to track down in the code. The other is objects with LLPointer members not nulling them out when they're really done with them, thus keeping the pointed-to objects alive. So be very, very careful in this area. It's a fertile source of bugs, including some recent killer memory leaks from the past few months. References: <4697E528.6070104@blueflash.cc> <4697E9B0.7000509@lindenlab.com> Message-ID: <4697EBC4.6030106@blueflash.cc> > It can, because of the need to constantly update refcounts. That > imposes a small compute overhead and has something of a cache impact. > How measurable is hard to say, but I wouldn't want to be fiddling with > LLPointers in a place I knew was an inner loop. I'd approach this in the way like with the LLDrawInfo, that is changing vector/list members to LLPointer but leaving function calls off those members (or pointers inside functions) regular C++. Will probably give it a grep to see how many they are, just wanted to know upfront if anyone says that it would be an undesired thing to do with the faces (given that there's even an llface.inl file with inlines for these. > including some recent killer memory leaks from the past few months. :-) Thanks Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Fri Jul 13 14:24:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 13 14:24:34 2007 Subject: [sldev] OSLCC SecondLife-1.18.0.6.OS.0 released In-Reply-To: <4697EAC5.20009@dzonux.net> References: <4697E62A.4060103@dzonux.net> <4697E847.3070109@blueflash.cc> <4697EAC5.20009@dzonux.net> Message-ID: <4697ED86.8060604@blueflash.cc> I'm attaching a ZIP ... the files have JIRA numbers and descriptive filenames. I excluded a few cosmetic or specific ones and you might want to skip those with numbers under 1000 (especially 418 and 733). The ones starting with "x" are my "best of JIRA", i.e. from other contributors (Gigs et al). Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dzonatas wrote: > Sure, I was looking for the list and thumbing through you blog pages... > can you send me the list? > > > Nicholaz Beresford wrote: >> >> Hi Dzon, >> >> I can send you the whole set from my build (sans the >> cosmetic ones) if you like. They're all running live >> out there (and a few brand new ones). >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Dzonatas wrote: >>> Last file release on OSLCC did pretty well with over 200 downloads in >>> an early June week. >>> >>> Here is an update: >>> http://sourceforge.net/project/showfiles.php?group_id=191214 >>> >>> It contains the same VWR-1110 patch as before but with the updated >>> source to 1.18. >>> >>> Instead of naming scheme like MyPopularNameEdition, I decided to go >>> with something more anonymous like OS for Open Source editions. That >>> way we all can get fair credit for the team effort! >>> >>> SecondLife-1.18.0.6.OS.0 is a debug enabled build. Hopefully, with >>> the new dia de la liberacion, we are able to switch more easily >>> between the aditi and agni grids to be more productive with the open >>> source movements and testing. >>> >>> Hehe... instead of OS... I was thinking of calling this ThirdLife. >>> >>> Let me know what patches you want included in the next build. >>> >>> An installer for the Windows version that sets up a separate main >>> directory and settings file would be awesome, so it doesn't have to >>> depend on the official SecondLife install. =) >>> >>> Dz >>> >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: patches.zip Type: application/zip Size: 23526 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070713/2cd2f7db/patches-0001.zip From odysseus654 at gmail.com Fri Jul 13 14:35:22 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Fri Jul 13 14:35:24 2007 Subject: [sldev] performance with LLPointer In-Reply-To: <4697EBC4.6030106@blueflash.cc> References: <4697E528.6070104@blueflash.cc> <4697E9B0.7000509@lindenlab.com> <4697EBC4.6030106@blueflash.cc> Message-ID: <1674f6c70707131435v5b25ecb9i4873f3f37eab4aeb@mail.gmail.com> On 7/13/07, Nicholaz Beresford wrote: > > > > It can, because of the need to constantly update refcounts. That > > imposes a small compute overhead and has something of a cache impact. > > How measurable is hard to say, but I wouldn't want to be fiddling with > > LLPointers in a place I knew was an inner loop. > > I'd approach this in the way like with the LLDrawInfo, that is changing > vector/list members to LLPointer but leaving function calls off those > members (or pointers inside functions) regular C++. FWIW, This is the only way I ever figured out how to use the STL auto_ptr<> classes without going half crazy. Just make sure that the functions you call don't do side effects like storing the pointers somewhere else or using deferred processing or something weird that could affect lifetime. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070713/7a8c1353/attachment.htm From ettore_pasquini at 3dconnexion.com Fri Jul 13 16:48:28 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Fri Jul 13 16:48:33 2007 Subject: [sldev] 1.18.0.6 system unresponsiveness on linux after login Message-ID: Just built the 1.18.0.6 release on debian etch (i386) following the instruction on the wiki and in particular: % scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no % export LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_P ATH}:/usr/local/lib After completing the build I noticed a few libraries missing: libllmath.so libllvfs.so llibllimagej2coj.so libllimage.so libfmod-3.75.so libllcommon.so I noticed they actually were built under indra/lib_release_client/ so I copied them over to the main libraries location. Soon after login the screen becomes all black, the mouse and the entire system gets unresponsive. Only way to revive it is to reset it. I must say this is the first time for me building SL on linux, so there might be something I missed? Any suggestion is welcome, Thanks. Ettore From ettore_pasquini at 3dconnexion.com Fri Jul 13 17:46:26 2007 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Fri Jul 13 17:46:26 2007 Subject: [sldev] 1.18.0.6 system unresponsiveness on linux after login In-Reply-To: Message-ID: On 7/13/07 4:48 PM, "Ettore Pasquini" wrote: > Just built the 1.18.0.6 release on debian etch (i386) following the > instruction on the wiki and in particular: > % scons DISTCC=no BTARGET=client BUILD=release MOZLIB=no > > Soon after login the screen becomes all black, the mouse and the entire > system gets unresponsive. Only way to revive it is to reset it. update: Building with BUILD=releasefordownload removed the problem. Don't know what's wrong with the "release" build setting though. Ettore From tateru.nino at gmail.com Fri Jul 13 23:14:47 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jul 13 23:14:58 2007 Subject: [sldev] Another odd problem In-Reply-To: References: Message-ID: <469869D7.1050602@gmail.com> That's an easy one. Someone is interacting with something of yours that is using llGiveInventory() (a notecard giver or vendor or whatever) while they are in BUSY mode. Harold Brown wrote: > I've had these types of messages in the past. Haven't looked into why > I get them before, figured now is a good time to bring it up :) > > They've always been from people I don't know... and as I'm obviously > not online (since it went to my e-mail) I wasn't sending them a > message to begin with. > > ---------- Forwarded message ---------- > From: *astrid Bekkers* > > > Date: Jul 13, 2007 10:53 AM > Subject: Message From Second Life > To: Thraxis Epsilon > > > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > The Resident you messaged is in 'busy mode' which means they have > requested not to be disturbed. Your message will still be shown in > their IM panel for later viewing. > > > --- > To stop receiving these emails, log in to Second Life and uncheck > "Send IM to Email" in the General tab of the Preferences window or visit: > http://secondlife.com/account/im_off.php?k=ganu3fsn3sexdpmi5cwn3l2jtwovdkgiyfqvq6cgnyda5qhpr7dfcua2zbakec4e > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From gigstaggart at gmail.com Sat Jul 14 01:15:26 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jul 14 01:15:33 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <469869D7.1050602@gmail.com> References: <469869D7.1050602@gmail.com> Message-ID: <4698861E.90905@gmail.com> Tateru Nino wrote: > That's an easy one. Someone is interacting with something of yours that > is using llGiveInventory() (a notecard giver or vendor or whatever) > while they are in BUSY mode. That's not as bad as one guy who tried to buy something from one of my vendors when he had me muted for some reason. That caused a lot of "human induced spam". I got the following offline IMs, all at once when I checked them: (Note that was a 99L object) [15:06] him: i [15:07] him: was buying at armory island...but nothing received [15:07] him: can you help me please [15:09] him: hello [15:10] him: gigs [16:59] him: hello [16:59] him: hey [17:00] him: i bout you gpt the money but i got nothin no object [17:02] him: Date: 2007-06-13 15:05:36 Type: Payment Desc: Region: Armory Island Destination: Gigs Taggart [17:02] him: i didnt receive nothin [17:03] him: im gonna call linden lab if you do nothin [17:06] him: hello [17:07] him: what kind of merchant are you [17:31] him: es tu la [17:31] him: parle tu francais [17:31] him: ou anglais [17:33] him: ineed to get what i paid for it Once I got on, and he was IMing me, and he couldn't see what I was saying in reply apparently, I figured out he had me muted. I had to ask someone else to IM him for me to get him straightened out. Lessons from this comedic incident? A) I think it's too easy to accidentally mute someone. Right click, move down a little and mash the button 3 times and you've muted someone or an object. I know I've accidentally muted things before. B) If there is some way mute can be overridden when they have recently paid the object giving the inventory, might help alleviate this problem. Maybe remove object/person from mute list when you pay them. -Jason From kerdezixe at gmail.com Sat Jul 14 01:43:58 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sat Jul 14 01:43:59 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <4698861E.90905@gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> Message-ID: <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> I have this problem every week and it caps my IM :( And you're lucky he explained the problem. some time i just get : - kerunix - kerunix ? - Hello ? - online ? - kerunix - hi ! - kerunix ? IM me - Are you online ? - kerunix - ... On 7/14/07, Jason Giglio wrote: > Tateru Nino wrote: > > That's an easy one. Someone is interacting with something of yours that > > is using llGiveInventory() (a notecard giver or vendor or whatever) > > while they are in BUSY mode. > > That's not as bad as one guy who tried to buy something from one of my > vendors when he had me muted for some reason. > > That caused a lot of "human induced spam". > > I got the following offline IMs, all at once when I checked them: > > (Note that was a 99L object) > > [15:06] him: i > [15:07] him: was buying at armory island...but nothing received > [15:07] him: can you help me please > > [15:09] him: hello > > [15:10] him: gigs > > [16:59] him: hello > [16:59] him: hey > > [17:00] him: i bout you gpt the money but i got nothin no object > > [17:02] him: Date: 2007-06-13 15:05:36 Type: Payment Desc: > Region: Armory Island Destination: Gigs Taggart > [17:02] him: i didnt receive nothin > [17:03] him: im gonna call linden lab if you do nothin > > [17:06] him: hello > [17:07] him: what kind of merchant are you > > [17:31] him: es tu la > [17:31] him: parle tu francais > [17:31] him: ou anglais > [17:33] him: ineed to get what i paid for it > > Once I got on, and he was IMing me, and he couldn't see what I was > saying in reply apparently, I figured out he had me muted. I had to ask > someone else to IM him for me to get him straightened out. > > > Lessons from this comedic incident? > > A) I think it's too easy to accidentally mute someone. Right click, > move down a little and mash the button 3 times and you've muted someone > or an object. I know I've accidentally muted things before. > > B) If there is some way mute can be overridden when they have recently > paid the object giving the inventory, might help alleviate this problem. > Maybe remove object/person from mute list when you pay them. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tateru.nino at gmail.com Sat Jul 14 02:29:14 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jul 14 02:29:23 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> Message-ID: <4698976A.4060502@gmail.com> Perhaps the thing to do is to generate an UNMUTE event if you IM someone on your Mute list or pay them. Laurent Laborde wrote: > I have this problem every week and it caps my IM :( > And you're lucky he explained the problem. > some time i just get : > - kerunix > - kerunix ? > - Hello ? > - online ? > - kerunix > - hi ! > - kerunix ? IM me > - Are you online ? > - kerunix > - ... > > On 7/14/07, Jason Giglio wrote: >> Tateru Nino wrote: >> > That's an easy one. Someone is interacting with something of yours >> that >> > is using llGiveInventory() (a notecard giver or vendor or whatever) >> > while they are in BUSY mode. >> >> That's not as bad as one guy who tried to buy something from one of my >> vendors when he had me muted for some reason. >> >> That caused a lot of "human induced spam". >> >> I got the following offline IMs, all at once when I checked them: >> >> (Note that was a 99L object) >> >> [15:06] him: i >> [15:07] him: was buying at armory island...but nothing received >> [15:07] him: can you help me please >> >> [15:09] him: hello >> >> [15:10] him: gigs >> >> [16:59] him: hello >> [16:59] him: hey >> >> [17:00] him: i bout you gpt the money but i got nothin no object >> >> [17:02] him: Date: 2007-06-13 15:05:36 Type: Payment Desc: >> Region: Armory Island Destination: Gigs Taggart >> [17:02] him: i didnt receive nothin >> [17:03] him: im gonna call linden lab if you do nothin >> >> [17:06] him: hello >> [17:07] him: what kind of merchant are you >> >> [17:31] him: es tu la >> [17:31] him: parle tu francais >> [17:31] him: ou anglais >> [17:33] him: ineed to get what i paid for it >> >> Once I got on, and he was IMing me, and he couldn't see what I was >> saying in reply apparently, I figured out he had me muted. I had to ask >> someone else to IM him for me to get him straightened out. >> >> >> Lessons from this comedic incident? >> >> A) I think it's too easy to accidentally mute someone. Right click, >> move down a little and mash the button 3 times and you've muted someone >> or an object. I know I've accidentally muted things before. >> >> B) If there is some way mute can be overridden when they have recently >> paid the object giving the inventory, might help alleviate this problem. >> Maybe remove object/person from mute list when you pay them. >> >> -Jason >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From makosoft at googlemail.com Sat Jul 14 07:10:58 2007 From: makosoft at googlemail.com (Aidan Thornton) Date: Sat Jul 14 07:11:00 2007 Subject: [sldev] message template updates, logging in change? In-Reply-To: <0CD7DD4F-35C6-4E5A-AA5D-EE25958D35FB@secondlife.com> References: <041e01c7c3dd$bf5117e0$a4689943@gwsystems2.com> <469515B0.6030508@blueflash.cc> <46969052.2070400@lindenlab.com> <46969DFA.6020308@ourstillwaters.org> <0CD7DD4F-35C6-4E5A-AA5D-EE25958D35FB@secondlife.com> Message-ID: On 7/13/07, Phoenix wrote: > I have documented the new packet layout. Apologies for the lack of > coordination with the release. > > Briefly, flags is 1 byte, sequence is 4 bytes, there's a skip byte > and then as many bytes as found in the skip byte before the start of > the payload. For details: > > https://wiki.secondlife.com/wiki/Packet_Layout Ah, so that's what the 6th byte is used for. (It was zero in all the packets I looked at.) I suppose the libsecondlife packet decoding code needs fixing sometime... preferably before someone starts sending packets with extra header information. From sllists at boroon.dasgupta.ch Sat Jul 14 07:18:07 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat Jul 14 07:18:09 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <4698976A.4060502@gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> Message-ID: <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> What about a warning in the style of those that come when entering a password while caps lock is on? "Mute Warning You are trying to . However is on your mute list so you won't recieve any answers or goods from him/her. [unmute and ] [ but don't unmute] [skip] [ ] remember this choice" where is one of IM, pay, give Inventory to, or whatever else might qualify for unmuting. Zitat von Tateru Nino : > Perhaps the thing to do is to generate an UNMUTE event if you IM someone > on your Mute list or pay them. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070714/6247c84b/attachment.htm From gigstaggart at gmail.com Sat Jul 14 07:21:26 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jul 14 07:21:33 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> Message-ID: <4698DBE6.6060008@gmail.com> Boroondas Gupte wrote: > What about a warning in the style of those that come when entering a > password while caps lock is on? > > "Mute Warning > You are trying to . However is > on your mute list so you won't recieve any answers or goods from him/her. > > [unmute and ] [ but don't unmute] [skip] > [ ] remember this choice" > > where is one of IM, pay, give Inventory to, or whatever else > might qualify for unmuting. Nah, that seems like "preference bloat" to me. (Not to mention, pop-upitis) I think having mute disengage when you make direct contact with the mutee would be the best course of action. -Jason From robin.cornelius at gmail.com Sat Jul 14 07:36:51 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Jul 14 07:36:59 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <4698DBE6.6060008@gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> <4698DBE6.6060008@gmail.com> Message-ID: <4698DF83.4080705@gmail.com> Jason Giglio wrote: > Boroondas Gupte wrote: >> What about a warning in the style of those that come when entering a >> password while caps lock is on? >> >> "Mute Warning >> You are trying to . However >> is on your mute list so you won't recieve any answers or goods from >> him/her. >> >> [unmute and ] [ but don't unmute] [skip] >> [ ] remember this choice" >> >> where is one of IM, pay, give Inventory to, or whatever else >> might qualify for unmuting. > > Nah, that seems like "preference bloat" to me. (Not to mention, > pop-upitis) I think having mute disengage when you make direct contact > with the mutee would be the best course of action. > I think there are very few reasons for sending a message to someone you have muted. The most likely is the situation described, ie a mistake. The only other two reasons I can think of are if a land owner etc has muted a greifer and is issuing a warning/ban (and this can simply be done in a different order) or some one being childish by muting someone and then sending abuse (which is not really a good situation to have). So i think this is a great idea. I think there is no need for this to be a preference. Either the warning or the automatic unmute (or both?) -- Robin Cornelius http://www.byteme.org.uk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070714/63885de1/signature.pgp From able.whitman at gmail.com Sat Jul 14 08:11:55 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sat Jul 14 08:11:59 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <4698DF83.4080705@gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> <4698DBE6.6060008@gmail.com> <4698DF83.4080705@gmail.com> Message-ID: <7b3a84fb0707140811v5a56b0fape92ba6e1901349b1@mail.gmail.com> Ah, people discussing the mute list makes my ears burn! :) I like this idea very much, and I've created a JIRA entry for it: https://jira.secondlife.com/browse/VWR-1735 (Directly interacting with a muted resident should unmute them). I will try to implement this change in an upcoming release of my mute visibility browser, although the changes to implement VWR-1735 should be entirely independent of the other mute list changes, so I will be able to submit a patch for this separately. I think I will also change the location of the "Mute" pie menu item, to make it a little more difficult to accidentally mute a resident. --Able On 7/14/07, Robin Cornelius wrote: > > Jason Giglio wrote: > > Boroondas Gupte wrote: > >> What about a warning in the style of those that come when entering a > >> password while caps lock is on? > >> > >> "Mute Warning > >> You are trying to . However > >> is on your mute list so you won't recieve any answers or goods from > >> him/her. > >> > >> [unmute and ] [ but don't unmute] [skip] > >> [ ] remember this choice" > >> > >> where is one of IM, pay, give Inventory to, or whatever else > >> might qualify for unmuting. > > > > Nah, that seems like "preference bloat" to me. (Not to mention, > > pop-upitis) I think having mute disengage when you make direct contact > > with the mutee would be the best course of action. > > > > I think there are very few reasons for sending a message to someone you > have muted. The most likely is the situation described, ie a mistake. > The only other two reasons I can think of are if a land owner etc has > muted a greifer and is issuing a warning/ban (and this can simply be > done in a different order) or some one being childish by muting someone > and then sending abuse (which is not really a good situation to have). > > So i think this is a great idea. I think there is no need for this to be > a preference. Either the warning or the automatic unmute (or both?) > > > > -- > Robin Cornelius > http://www.byteme.org.uk > > > _______________________________________________ > 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/20070714/c5e6b3b0/attachment.htm From matthew.dowd at hotmail.co.uk Sat Jul 14 09:42:28 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 09:42:30 2007 Subject: [sldev] Group Invite Suggestion--add 'view profile' to invite dialog box Message-ID: I've just posted what I think is a fairly simple patch to addess this Jira issue: http://jira.secondlife.com/browse/MISC-178 (I thought I'd better say thin it is fairly simple just in case, I've made some stupid error ;-) ) Basically adds a third button "Info" to the You have been invited to a group popup which opens the group details floater Matthew _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From dzonatas at dzonux.net Sat Jul 14 09:43:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 14 09:43:45 2007 Subject: [sldev] Open Source Viewer, 1.18.0.6.OS.1 released Message-ID: <4698FD4F.8010703@dzonux.net> Download here: http://sourceforge.net/project/showfiles.php?group_id=191214 We may need to sub-task QA issues for a few of these on PJIRA. Here are the included patch files (and the version of the OSV they were applied to). Patches may be modified from the version posted on JIRA, and the version applied is included in the download above. svc-371.1.18.0.6.os.1.patch.txt vwr-349.1.18.0.6.os.1.patch.txt vwr-353.1.18.0.6.os.1.patch.txt vwr-777.1.18.0.6.os.0.patch.txt vwr-779.1.18.0.6.os.1.patch.txt vwr-1110.1.18.0.6.os.1.patch.txt vwr-1270.1.18.0.6.os.1.patch.txt vwr-1289.1.18.0.6.os.1.patch.txt vwr-1294.1.18.0.6.os.1.patch.txt vwr-1352.1.18.0.6.os.1.patch.txt vwr-1406.1.18.0.6.os.1.patch.txt vwr-1420.1.18.0.6.os.1.patch.txt vwr-1434.1.18.0.6.os.1.patch.txt vwr-1465.1.18.0.6.os.1.patch.txt vwr-1470.1.18.0.6.os.1.patch.txt vwr-1471.1.18.0.6.os.1.patch.txt vwr-1578.1.18.0.6.os.1.patch.txt vwr-1603.1.18.0.6.os.1.patch.txt vwr-1612.1.18.0.6.os.1.patch.txt vwr-1613.1.18.0.6.os.1.patch.txt vwr-1626.1.18.0.6.os.1.patch.txt vwr-1646.1.18.0.6.os.1.patch.txt vwr-1655.1.18.0.6.os.1.patch.txt vwr-1704.1.18.0.6.os.0.patch.txt vwr-1705.1.18.0.6.os.0.patch.txt vwr-1721.1.18.0.6.os.1.patch.txt vwr-1723.1.18.0.6.os.1.patch.txt vwr-1729.1.18.0.6.os.0.patch.txt -- Power to Change the Void From nicholaz at blueflash.cc Sat Jul 14 10:00:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jul 14 10:00:28 2007 Subject: [sldev] Group Invite Suggestion--add 'view profile' to invite dialog box In-Reply-To: References: Message-ID: <46990120.8070505@blueflash.cc> That's a really neat idea ... I like that! Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matthew Dowd wrote: > I've just posted what I think is a fairly simple patch to addess this Jira issue: http://jira.secondlife.com/browse/MISC-178 > > (I thought I'd better say thin it is fairly simple just in case, I've made some stupid error ;-) ) > > Basically adds a third button "Info" to the You have been invited to a group popup which opens the group details floater > > Matthew > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From Paul.Hampson at Pobox.com Sat Jul 14 11:00:01 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jul 14 11:00:10 2007 Subject: [sldev] Re: shared objects output during standalone build (Was: releasefordownload - linux) In-Reply-To: <46963B7B.9040302@gmail.com> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> Message-ID: <20070714180001.GA20761@keitarou> On Thu, Jul 12, 2007 at 10:32:27AM -0400, Jason Giglio wrote: > Boroondas Gupte wrote: > >Jason Giglio : > > > I had to run cp > > > ../linden/indra/lib_releasefordownload_client/i686-linux/ lib/ to get > > > the libraries that it neglected to tar up apparently. > >might be what Callum found two weeks ago: > >https://lists.secondlife.com/pipermail/sldev/2007-June/002727.html > >https://lists.secondlife.com/pipermail/sldev/2007-June/thread.html#2727 > >I don't think there's a Jira Issue about it, yet. So you might want to create one. > >Boroondas > Yes it appears to be the same issue. > Filed: > http://jira.secondlife.com/browse/VWR-1697 I see Sardonyx Linden has marked this as fixed internally. What was the fix? I'm hoping it wasn't unsharing the shared objects, because I'm pretty sure building those as shared objects cut my build time by about an hour (from three to two), unless someone else can suggest a different 1.17 to 1.18 change that would cause that? (My measurement of 'two hours' is a little unscientific, mind you, but the three hours was measured before, to within 10 minutes over the last three versions I've packaged) I'm particularly interested to know what the fix was so I can apply it to the 1.18 packages I'm trying to prepare. My first instinct was to organise an rpath in slviewer for /usr/lib/slviewer/ to put those .so files in, but if upstream is going to instead either change the create_cond_macro function or not use it for the client components, then I can make _that_ change here and save myself some work later. I note that in the indra/lib_release_client/powerpc-linux or equivalent directory: for d in *.so; do objdump -T $d --demangle | grep UND |grep -v -E '(PNG12_0|GLIBC_|GLIBCXX_|GCC_|CXXABI_| jpeg_| apr_| XML_| gz| opj_| cio_)' | grep -v '^00000000 w' | cut -c 46- |sort -u > $d.missing; done for d in *.so; do objdump -T $d --demangle | grep -v UND |cut -dB -f 2- |grep '^ase' |cut -c 12- |sort -u > $d.have; done for d in *.so; do cat *.have | grep -v -F -f - $d.missing ; done indicates that the .so files don't have any unresolved dependancies on the static linked objects. Further, sort *.have | uniq -dc |grep LL indicates the overlap in exported interfaces is small: 5 guard variable for LLStringBase::null 4 LLStringBase::assign(char const*) 4 LLStringBase::assign(LLStringBase const&) 4 LLStringBase::LLStringBase(char const*) 5 LLStringBase::null 2 LLStringBase::toLower(std::string&) 2 LLStringBase::toUpper(std::string&) 2 LLStringOps::toLower(char) 2 LLStringOps::toUpper(char) 4 std::ostream& operator<< (std::ostream&, LLStringBase const&) 5 typeinfo for LLError::NoClassInfo 5 typeinfo name for LLError::NoClassInfo which I'm guessing is the result of inlining, so unless there's some kind of performance penalty for using shared libraries, I'm all for this state of affairs continuing and even encompassing more. I believe there was a Jira issue around for .soing more of the client... The only issue then is convincing SCons to put an rpath into the client. (Side note. Searching for shared object in Jira didn't come up with anything useful on the first page of forty. Searing for .so came up with a similarly large number of pages, and the first report on the first page was "JIRA's navigation is so nonintuitive as to be useless".) I haven't shipped it yet, awaiting feedback. I note with slight amusement that llcommon and llmath have a circular dependancy relationship. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070715/78ccf671/attachment-0001.pgp From matthew.dowd at hotmail.co.uk Sat Jul 14 11:01:45 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 11:01:46 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu Message-ID: OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 This adds a new option to the avatar pie menu of invite to group. Also added a few new internal features which may be useful elsehwhere: LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). Matthew _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From matthew.dowd at hotmail.co.uk Sat Jul 14 11:03:52 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 11:03:54 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu Message-ID: P.S. this was much more involved than the other patches I've submitted which was good in that it helped my knowledge of the source code. On the other hand, in reusing various dialogs, I may have introduced new issues, so peer review would be welcome!! Matthew ---------------------------------------- > From: matthew.dowd@hotmail.co.uk > To: sldev@lists.secondlife.com > Date: Sat, 14 Jul 2007 18:01:45 +0000 > Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > > OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 > > This adds a new option to the avatar pie menu of invite to group. > > Also added a few new internal features which may be useful elsehwhere: > > LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). > > This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). > > Matthew > > > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From matthew.dowd at hotmail.co.uk Sat Jul 14 11:04:43 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 11:04:45 2007 Subject: [sldev] Group Invite Suggestion--add 'view profile' to invite dialog box Message-ID: I can't claim credit for the idea - just the dozen or so lines of code to implement it. Matthew ---------------------------------------- > Date: Sat, 14 Jul 2007 19:00:16 +0200 > From: nicholaz@blueflash.cc > To: matthew.dowd@hotmail.co.uk > CC: sldev@lists.secondlife.com > Subject: Re: [sldev] Group Invite Suggestion--add 'view profile' to invite dialog box > > > That's a really neat idea ... I like that! > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Matthew Dowd wrote: > > I've just posted what I think is a fairly simple patch to addess this Jira issue: http://jira.secondlife.com/browse/MISC-178 > > > > (I thought I'd better say thin it is fairly simple just in case, I've made some stupid error ;-) ) > > > > Basically adds a third button "Info" to the You have been invited to a group popup which opens the group details floater > > > > Matthew > > _________________________________________________________________ > > Feel like a local wherever you go with BackOfMyHand.com > > http://www.backofmyhand.com_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From dzonatas at dzonux.net Sat Jul 14 11:17:56 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 14 11:17:41 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu In-Reply-To: References: Message-ID: <46991354.3060101@dzonux.net> Sweet! I've been wanting an easier way to invite people to group! Matthew Dowd wrote: > OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 > > This adds a new option to the avatar pie menu of invite to group. > > Also added a few new internal features which may be useful elsehwhere: > > LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). > > This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). > > Matthew > > > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- Power to Change the Void From nicholaz at blueflash.cc Sat Jul 14 11:23:50 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jul 14 11:24:02 2007 Subject: [sldev] Group Invite Suggestion--add 'view profile' to invite dialog box In-Reply-To: References: Message-ID: <469914B6.2000902@blueflash.cc> Well, but it takes the idea AND the coding :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matthew Dowd wrote: > I can't claim credit for the idea - just the dozen or so lines of code to implement it. > > Matthew > > > > > ---------------------------------------- >> Date: Sat, 14 Jul 2007 19:00:16 +0200 >> From: nicholaz@blueflash.cc >> To: matthew.dowd@hotmail.co.uk >> CC: sldev@lists.secondlife.com >> Subject: Re: [sldev] Group Invite Suggestion--add 'view profile' to invite dialog box >> >> >> That's a really neat idea ... I like that! >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Matthew Dowd wrote: >>> I've just posted what I think is a fairly simple patch to addess this Jira issue: http://jira.secondlife.com/browse/MISC-178 >>> >>> (I thought I'd better say thin it is fairly simple just in case, I've made some stupid error ;-) ) >>> >>> Basically adds a third button "Info" to the You have been invited to a group popup which opens the group details floater >>> >>> Matthew >>> _________________________________________________________________ >>> Feel like a local wherever you go with BackOfMyHand.com >>> http://www.backofmyhand.com_______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com From matthew.dowd at hotmail.co.uk Sat Jul 14 11:32:43 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 11:32:45 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu Message-ID: Can't claim this idea either ;-) ( http://forums.secondlife.com/showthread.php?p=1586402 ) Matthew ---------------------------------------- > Date: Sat, 14 Jul 2007 11:17:56 -0700 > From: dzonatas@dzonux.net > To: matthew.dowd@hotmail.co.uk > CC: sldev@lists.secondlife.com > Subject: Re: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > Sweet! > > I've been wanting an easier way to invite people to group! > > Matthew Dowd wrote: > > OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 > > > > This adds a new option to the avatar pie menu of invite to group. > > > > Also added a few new internal features which may be useful elsehwhere: > > > > LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions > > > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. > > > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). > > > > This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). > > > > Matthew > > > > > > _________________________________________________________________ > > Feel like a local wherever you go with BackOfMyHand.com > > http://www.backofmyhand.com_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > -- > Power to Change the Void _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From matthew.dowd at hotmail.co.uk Sat Jul 14 13:24:57 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 13:24:58 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu Message-ID: Mmmm, I've just realised that there may be a mistake in my code which throws up a mistake in the LLFloaterGroups code. Basically the description for show says // Call this with an agent id and AGENT_GROUPS for an agent's // groups, otherwise, call with an object id and SET_OBJECT_GROUP // when modifying an object. // static LLFloaterGroups* LLFloaterGroups::show(const LLUUID& id, EGroupDialog type, U64 powers_mask) Now in my code where I've realise I'm calling it with id set to the id at the agent you've just selected - now from the above description you'd expect it to display the groups of the agent with UUID id, however it actually gives your own groups due to code later down. void LLFloaterGroups::initAgentGroups(const LLUUID& highlight_id) { S32 count = gAgent.mGroups.count(); So although technically, I'm passing the wrong parameter, it didn't show up in my testing as LLFloaterGroups will only display your own groups never anyone elses. Looking through the rest of the codebase LLFloaterGroups::show is only ever called with gAgent.getId() so the problem has never occured. What's the best way forward - raise a jira issue with a patch? Assuming that is that my understanding of LLFloaterGroups::show is correct? Matthew ---------------------------------------- > From: matthew.dowd@hotmail.co.uk > To: sldev@lists.secondlife.com > Subject: RE: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > Date: Sat, 14 Jul 2007 18:03:52 +0000 > > > P.S. this was much more involved than the other patches I've submitted which was good in that it helped my knowledge of the source code. On the other hand, in reusing various dialogs, I may have introduced new issues, so peer review would be welcome!! > > Matthew > > > > > ---------------------------------------- > > From: matthew.dowd@hotmail.co.uk > > To: sldev@lists.secondlife.com > > Date: Sat, 14 Jul 2007 18:01:45 +0000 > > Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > > > > > OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 > > > > This adds a new option to the avatar pie menu of invite to group. > > > > Also added a few new internal features which may be useful elsehwhere: > > > > LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions > > > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. > > > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). > > > > This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). > > > > Matthew > > > > > > _________________________________________________________________ > > Feel like a local wherever you go with BackOfMyHand.com > > http://www.backofmyhand.com_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Celeb spotting ? Play CelebMashup and win cool prizes > https://www.celebmashup.com/index2.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From able.whitman at gmail.com Sat Jul 14 13:35:40 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sat Jul 14 13:35:42 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu In-Reply-To: <7b3a84fb0707141335l2240faf1h298c987228f1a16f@mail.gmail.com> References: <7b3a84fb0707141335l2240faf1h298c987228f1a16f@mail.gmail.com> Message-ID: <7b3a84fb0707141335g573ea71chadd2ad11d7047435@mail.gmail.com> If you patch initAgentGroups() to use the ID you pass in to the show() method, does it actually work as the comments for show() describe? That is, does it correctly show the group list for another resident? If it does, then I'd say the right thing to do is to patch initAgentGroups() so that it respects the ID provided to the show() method. On 7/14/07, Matthew Dowd wrote: > > > Mmmm, I've just realised that there may be a mistake in my code which > throws up a mistake in the LLFloaterGroups code. > > Basically the description for show says > > // Call this with an agent id and AGENT_GROUPS for an agent's > // groups, otherwise, call with an object id and SET_OBJECT_GROUP > // when modifying an object. > // static > LLFloaterGroups* LLFloaterGroups::show(const LLUUID& id, EGroupDialog > type, U64 powers_mask) > > Now in my code where I've realise I'm calling it with id set to the id at > the agent you've just selected - now from the above description you'd expect > it to display the groups of the agent with UUID id, however it actually > gives your own groups due to code later down. > > void LLFloaterGroups::initAgentGroups(const LLUUID& highlight_id) > { > S32 count = gAgent.mGroups.count(); > > So although technically, I'm passing the wrong parameter, it didn't show > up in my testing as LLFloaterGroups will only display your own groups never > anyone elses. > > Looking through the rest of the codebase LLFloaterGroups::show is only > ever called with gAgent.getId() so the problem has never occured. > > What's the best way forward - raise a jira issue with a patch? Assuming > that is that my understanding of LLFloaterGroups::show is correct? > > Matthew > > > > > ---------------------------------------- > > From: matthew.dowd@hotmail.co.uk > > To: sldev@lists.secondlife.com > > Subject: RE: [sldev] Slightly more involved patch - Added Invite to > Group to avatar pie menu > > Date: Sat, 14 Jul 2007 18:03:52 +0000 > > > > > > P.S. this was much more involved than the other patches I've submitted > which was good in that it helped my knowledge of the source code. On the > other hand, in reusing various dialogs, I may have introduced new issues, so > peer review would be welcome!! > > > > Matthew > > > > > > > > > > ---------------------------------------- > > > From: matthew.dowd@hotmail.co.uk > > > To: sldev@lists.secondlife.com > > > Date: Sat, 14 Jul 2007 18:01:45 +0000 > > > Subject: [sldev] Slightly more involved patch - Added Invite to Group > to avatar pie menu > > > > > > > > > OK, I've posted a somewhat more involved patch than the one earlier > today at http://jira.secondlife.com/browse/VWR-1736 > > > > > > This adds a new option to the avatar pie menu of invite to group. > > > > > > Also added a few new internal features which may be useful elsehwhere: > > > > > > > LLFloaterGroups::show - now take a third optional parameter allowing > you to list only groups with specified permissions > > > > > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids > which get automatically added to the invitee list. > > > > > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite > assume that the Group Information dialog has already cached the group > information. This has the effect in the current browser that if you are > quick enough (or if the group is large and/or SL is running slowly), if you > press the Invite button in the Members and Group tab in Group Information, > the roles dropdown list can remain blank (until you close and reopen the > invite dialog). > > > > > > This is because an attempt to populate the dropdown list is only made > when the dialog is first opened. The patch modifies LLPanelGroupInvite so > that it keeps retrying to see if the data has been cached until it can > populate the drop down list. (I've jira'd this seperately at > http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this > out as a seperate patch file unless requested - it isn't difficult to do > from the hints I've given in jira anyway). > > > > > > Matthew > > > > > > > > > _________________________________________________________________ > > > Feel like a local wherever you go with BackOfMyHand.com > > > > http://www.backofmyhand.com_______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _________________________________________________________________ > > Celeb spotting ? Play CelebMashup and win cool prizes > > https://www.celebmashup.com/index2.html_______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > > 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/20070714/2b97304c/attachment.htm From gigstaggart at gmail.com Sat Jul 14 14:45:29 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jul 14 14:45:36 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <7b3a84fb0707140811v5a56b0fape92ba6e1901349b1@mail.gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> <4698DBE6.6060008@gmail.com> <4698DF83.4080705@gmail.com> <7b3a84fb0707140811v5a56b0fape92ba6e1901349b1@mail.gmail.com> Message-ID: <469943F9.1020006@gmail.com> Able Whitman wrote: > Ah, people discussing the mute list makes my ears burn! :) I like this > idea very much, and I've created a JIRA entry for it: > https://jira.secondlife.com/browse/VWR-1735 > (Directly interacting with > a muted resident should unmute them). > > I will try to implement this change in an upcoming release of my mute > visibility browser, although the changes to implement VWR-1735 should be > entirely independent of the other mute list changes, so I will be able > to submit a patch for this separately. Thanks Able. I'm glad you didn't see through our thinly veiled plan to entice you into implementing this. :) -Jason From matthew.dowd at hotmail.co.uk Sat Jul 14 15:15:47 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 15:15:49 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu Message-ID: Ok, this is actually a real can of worms, I think I will put the top back on! Currently, the value of id passed to show(id, type) is only used as an identifier within a map so that a previous instance can be retrieved and reused, although as id is always equal to gAgent.getID() in all the calls that are actually made to this function, this seems pretty redundant! initAgentGroups however pulls the groups list from gAgent (i.e. your group lists) and ignores the value of mID (the property in which the value passed in on show is stored). I suspect that whoever wrote the code originally intended to pull the groups belong to mID down but then hit the same problem I realised when looking at this. pulling groups from gAgent is easy since they've already been cached. pulling groups for anyone else requires sending a request avatar groups message to the server, the problem is that the current messaging implementation passes the avater group response to the avatar profile window, so there's a major plumbing rewrite in order to get this to display an other avatar's groups. As far as I can tell, show is only ever called with the value gAgent.getID() - including the case when the comment suggests you should call it with an Object's ID (incidently the value for type is wrong as well in the comment: SET_OBJECT_GROUP doesn't exist, and it should read CHOOSE_ONE). Actually there is one exception - it appears that the code which handles the View | Groups... menu i.e. this bit from from menu_viewer.xml was also meant to handle (xxxx-xxxx-xxxx-xxxx being an avatar's UUID), but as far as I can tell this code path is never called. I'll change my code to call LLFloaterGroups::show with a value of gAgent.getID(), but I'll just jira the other concerns. Matthew ________________________________ > Date: Sat, 14 Jul 2007 16:35:40 -0400 > From: able.whitman@gmail.com > To: matthew.dowd@hotmail.co.uk; SLDev@lists.secondlife.com > Subject: Re: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > If you patch initAgentGroups() to use the ID you pass in to the show() method, does it actually work as the comments for show() describe? That is, does it correctly show the group list for another resident? > If it does, then I'd say the right thing to do is to patch initAgentGroups() so that it respects the ID provided to the show() method. > On 7/14/07, Matthew Dowd < matthew.dowd@hotmail.co.uk> wrote: > Mmmm, I've just realised that there may be a mistake in my code which throws up a mistake in the LLFloaterGroups code. > Basically the description for show says > // Call this with an agent id and AGENT_GROUPS for an agent's > // groups, otherwise, call with an object id and SET_OBJECT_GROUP > // when modifying an object. > // static > LLFloaterGroups* LLFloaterGroups::show(const LLUUID& id, EGroupDialog type, U64 powers_mask) > Now in my code where I've realise I'm calling it with id set to the id at the agent you've just selected - now from the above description you'd expect it to display the groups of the agent with UUID id, however it actually gives your own groups due to code later down. > void LLFloaterGroups::initAgentGroups(const LLUUID& highlight_id) > { > S32 count = gAgent.mGroups.count(); > So although technically, I'm passing the wrong parameter, it didn't show up in my testing as LLFloaterGroups will only display your own groups never anyone elses. > Looking through the rest of the codebase LLFloaterGroups::show is only ever called with gAgent.getId() so the problem has never occured. > What's the best way forward - raise a jira issue with a patch? Assuming that is that my understanding of LLFloaterGroups::show is correct? > Matthew > ---------------------------------------- > > From: matthew.dowd@hotmail.co.uk > > To: sldev@lists.secondlife.com > > Subject: RE: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > Date: Sat, 14 Jul 2007 18:03:52 +0000 > > > > > > P.S. this was much more involved than the other patches I've submitted which was good in that it helped my knowledge of the source code. On the other hand, in reusing various dialogs, I may have introduced new issues, so peer review would be welcome!! > > > > Matthew > > > > > > > > > > ---------------------------------------- > > > From: matthew.dowd@hotmail.co.uk > > > To: sldev@lists.secondlife.com > > > Date: Sat, 14 Jul 2007 18:01:45 +0000 > > > Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > > > > > > > > OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 > > > > > > This adds a new option to the avatar pie menu of invite to group. > > > > > > Also added a few new internal features which may be useful elsehwhere: > > > > > > LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions > > > > > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. > > > > > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). > > > > > > This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). > > > > > > Matthew > > > > > > > > > _________________________________________________________________ > > > Feel like a local wherever you go with BackOfMyHand.com > > > http://www.backofmyhand.com_______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _________________________________________________________________ > > Celeb spotting ? Play CelebMashup and win cool prizes > > https://www.celebmashup.com/index2.html_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From hawk.carter at unix-dev.de Sat Jul 14 15:40:12 2007 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Sat Jul 14 15:40:27 2007 Subject: [sldev] Just another Homebrew. Message-ID: <000e01c7c667$f121e510$0301a8c0@main1> Hello all, here some SSE2 and P4 optimized viewers, including many patches, patches and features from Nicholaz 18a version and Ables nice visual mute feature build into one viewer. The linux viewer lacks ables feature, but will be included soon. All Viewers are Experimental even, i used as installer Installjammer for linux and windows. Have Fun and test it out. Hawk Carter Windows Installer : http://www.unix-dev.de/files/opensl-setup.exe Linux (tar.bz2) http://www.unix-dev.de/files/OpenSL.tar.bz2 Linux Installer (experimental) http://www.unix-dev.de/files/OpenSL-1.18.0.16-Linux-x86-Install From matthew.dowd at hotmail.co.uk Sat Jul 14 15:48:57 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jul 14 15:48:58 2007 Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu Message-ID: Mmmmm, hotmail garbled the xml in the original the but from menu_viewer.xml was on_click function="ShowAgentGroups" userdata="agent" there is code in llviewermenu.cpp in class LLShowAgentGroups which implies that you can also set userdata to a UUID but this is never actually used (afaict). I've written this all up in jire at http://jira.secondlife.com/browse/VWR-1743 Matthew ---------------------------------------- > From: matthew.dowd@hotmail.co.uk > To: able.whitman@gmail.com; sldev@lists.secondlife.com > Subject: RE: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > Date: Sat, 14 Jul 2007 22:15:47 +0000 > > > Ok, this is actually a real can of worms, I think I will put the top back on! > > Currently, the value of id passed to show(id, type) is only used as an identifier within a map so that a previous instance can be retrieved and reused, although as id is always equal to gAgent.getID() in all the calls that are actually made to this function, this seems pretty redundant! > > initAgentGroups however pulls the groups list from gAgent (i.e. your group lists) and ignores the value of mID (the property in which the value passed in on show is stored). I suspect that whoever wrote the code originally intended to pull the groups belong to mID down but then hit the same problem I realised when looking at this. > > pulling groups from gAgent is easy since they've already been cached. > > pulling groups for anyone else requires sending a request avatar groups message to the server, the problem is that the current messaging implementation passes the avater group response to the avatar profile window, so there's a major plumbing rewrite in order to get this to display an other avatar's groups. > > As far as I can tell, show is only ever called with the value gAgent.getID() - including the case when the comment suggests you should call it with an Object's ID (incidently the value for type is wrong as well in the comment: SET_OBJECT_GROUP doesn't exist, and it should read CHOOSE_ONE). > > Actually there is one exception - it appears that the code which handles the View | Groups... menu i.e. this bit from from menu_viewer.xml > > > > > > was also meant to handle > > > > (xxxx-xxxx-xxxx-xxxx being an avatar's UUID), but as far as I can tell this code path is never called. > > I'll change my code to call LLFloaterGroups::show with a value of gAgent.getID(), but I'll just jira the other concerns. > > Matthew > > > > > > > ________________________________ > > Date: Sat, 14 Jul 2007 16:35:40 -0400 > > From: able.whitman@gmail.com > > To: matthew.dowd@hotmail.co.uk; SLDev@lists.secondlife.com > > Subject: Re: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > > > If you patch initAgentGroups() to use the ID you pass in to the show() method, does it actually work as the comments for show() describe? That is, does it correctly show the group list for another resident? > > If it does, then I'd say the right thing to do is to patch initAgentGroups() so that it respects the ID provided to the show() method. > > On 7/14/07, Matthew Dowd < matthew.dowd@hotmail.co.uk> wrote: > > Mmmm, I've just realised that there may be a mistake in my code which throws up a mistake in the LLFloaterGroups code. > > Basically the description for show says > > // Call this with an agent id and AGENT_GROUPS for an agent's > > // groups, otherwise, call with an object id and SET_OBJECT_GROUP > > // when modifying an object. > > // static > > LLFloaterGroups* LLFloaterGroups::show(const LLUUID& id, EGroupDialog type, U64 powers_mask) > > Now in my code where I've realise I'm calling it with id set to the id at the agent you've just selected - now from the above description you'd expect it to display the groups of the agent with UUID id, however it actually gives your own groups due to code later down. > > void LLFloaterGroups::initAgentGroups(const LLUUID& highlight_id) > > { > > S32 count = gAgent.mGroups.count(); > > So although technically, I'm passing the wrong parameter, it didn't show up in my testing as LLFloaterGroups will only display your own groups never anyone elses. > > Looking through the rest of the codebase LLFloaterGroups::show is only ever called with gAgent.getId() so the problem has never occured. > > What's the best way forward - raise a jira issue with a patch? Assuming that is that my understanding of LLFloaterGroups::show is correct? > > Matthew > > ---------------------------------------- > > > From: matthew.dowd@hotmail.co.uk > > > To: sldev@lists.secondlife.com > > > Subject: RE: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > > Date: Sat, 14 Jul 2007 18:03:52 +0000 > > > > > > > > > P.S. this was much more involved than the other patches I've submitted which was good in that it helped my knowledge of the source code. On the other hand, in reusing various dialogs, I may have introduced new issues, so peer review would be welcome!! > > > > > > Matthew > > > > > > > > > > > > > > > ---------------------------------------- > > > > From: matthew.dowd@hotmail.co.uk > > > > To: sldev@lists.secondlife.com > > > > Date: Sat, 14 Jul 2007 18:01:45 +0000 > > > > Subject: [sldev] Slightly more involved patch - Added Invite to Group to avatar pie menu > > > > > > > > > > > > OK, I've posted a somewhat more involved patch than the one earlier today at http://jira.secondlife.com/browse/VWR-1736 > > > > > > > > This adds a new option to the avatar pie menu of invite to group. > > > > > > > > Also added a few new internal features which may be useful elsehwhere: > > > > > > > > LLFloaterGroups::show - now take a third optional parameter allowing you to list only groups with specified permissions > > > > > > > > LLFloaterGroupInvite::showForGroup - now takes a vector of avatar_ids which get automatically added to the invitee list. > > > > > > > > There's also a quirk in that llFloaterGroupInvite/LLPanelGroupInvite assume that the Group Information dialog has already cached the group information. This has the effect in the current browser that if you are quick enough (or if the group is large and/or SL is running slowly), if you press the Invite button in the Members and Group tab in Group Information, the roles dropdown list can remain blank (until you close and reopen the invite dialog). > > > > > > > > This is because an attempt to populate the dropdown list is only made when the dialog is first opened. The patch modifies LLPanelGroupInvite so that it keeps retrying to see if the data has been cached until it can populate the drop down list. (I've jira'd this seperately at http://jira.secondlife.com/browse/VWR-1737 but won't try to seperate this out as a seperate patch file unless requested - it isn't difficult to do from the hints I've given in jira anyway). > > > > > > > > Matthew > > > > > > > > > > > > _________________________________________________________________ > > > > Feel like a local wherever you go with BackOfMyHand.com > > > > http://www.backofmyhand.com_______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _________________________________________________________________ > > > Celeb spotting ? Play CelebMashup and win cool prizes > > > https://www.celebmashup.com/index2.html_______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > > Feel like a local wherever you go with BackOfMyHand.com > > http://www.backofmyhand.com_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > http://www.live.com/?mkt=en-gb _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From dzonatas at dzonux.net Sat Jul 14 17:55:27 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 14 17:55:12 2007 Subject: [sldev] Just another Homebrew. In-Reply-To: <000e01c7c667$f121e510$0301a8c0@main1> References: <000e01c7c667$f121e510$0301a8c0@main1> Message-ID: <4699707F.6090904@dzonux.net> By chance, are there any PJIRA issues for the SSE2 and P4 optimizations? Hawk Carter wrote: > Hello all, here some SSE2 and P4 optimized viewers, including many > patches, patches and features from Nicholaz 18a version and Ables nice > visual mute feature build into one viewer. > > The linux viewer lacks ables feature, but will be included soon. > > All Viewers are Experimental even, i used as installer Installjammer > for linux and windows. > > > Have Fun and test it out. > > Hawk Carter > > > Windows Installer : > http://www.unix-dev.de/files/opensl-setup.exe > > Linux (tar.bz2) > http://www.unix-dev.de/files/OpenSL.tar.bz2 > > Linux Installer (experimental) > > http://www.unix-dev.de/files/OpenSL-1.18.0.16-Linux-x86-Install > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From seg at haxxed.com Sun Jul 15 00:00:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jul 14 23:59:54 2007 Subject: [sldev] Re: shared objects output during standalone build (Was: releasefordownload - linux) In-Reply-To: <20070714180001.GA20761@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> Message-ID: <1184482831.3313.5.camel@localhost> On Sun, 2007-07-15 at 04:00 +1000, Paul TBBle Hampson wrote: > The only issue then is convincing SCons to put an rpath into the client. Bad idea: http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544 http://wiki.debian.org/RpathIssue http://people.debian.org/~che/personal/rpath-considered-harmful -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070715/a7021846/attachment.pgp From labrat.hb at gmail.com Sun Jul 15 01:51:38 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sun Jul 15 01:51:40 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <469943F9.1020006@gmail.com> References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> <4698DBE6.6060008@gmail.com> <4698DF83.4080705@gmail.com> <7b3a84fb0707140811v5a56b0fape92ba6e1901349b1@mail.gmail.com> <469943F9.1020006@gmail.com> Message-ID: OK... once more.. this time to the whole list: I'd prefer the "If you have muted someone you can not give them money in any fashion, including payments to scripted items" On 7/14/07, Jason Giglio wrote: > > Able Whitman wrote: > > Ah, people discussing the mute list makes my ears burn! :) I like this > > idea very much, and I've created a JIRA entry for it: > > https://jira.secondlife.com/browse/VWR-1735 > > (Directly interacting with > > a muted resident should unmute them). > > > > I will try to implement this change in an upcoming release of my mute > > visibility browser, although the changes to implement VWR-1735 should be > > entirely independent of the other mute list changes, so I will be able > > to submit a patch for this separately. > > Thanks Able. I'm glad you didn't see through our thinly veiled plan to > entice you into implementing this. :) > > -Jason > _______________________________________________ > 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/20070715/42cb177b/attachment.htm From tateru.nino at gmail.com Sun Jul 15 03:35:10 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jul 15 03:35:17 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: References: <469869D7.1050602@gmail.com> <4698861E.90905@gmail.com> <8a1bfe660707140143x55709b70lcb77fac9a639ce43@mail.gmail.com> <4698976A.4060502@gmail.com> <20070714161807.b5cqfh4vswg4sk84@datendelphin.net> <4698DBE6.6060008@gmail.com> <4698DF83.4080705@gmail.com> <7b3a84fb0707140811v5a56b0fape92ba6e1901349b1@mail.gmail.com> <469943F9.1020006@gmail.com> Message-ID: <4699F85E.3070306@gmail.com> What happens when they IM you to ask why they can't? Harold Brown wrote: > OK... once more.. this time to the whole list: > > > I'd prefer the "If you have muted someone you can not give them money > in any fashion, including payments to scripted items" > > > On 7/14/07, *Jason Giglio* > wrote: > > Able Whitman wrote: > > Ah, people discussing the mute list makes my ears burn! :) I > like this > > idea very much, and I've created a JIRA entry for it: > > https://jira.secondlife.com/browse/VWR-1735 > > (Directly > interacting with > > a muted resident should unmute them). > > > > I will try to implement this change in an upcoming release of my > mute > > visibility browser, although the changes to implement VWR-1735 > should be > > entirely independent of the other mute list changes, so I will > be able > > to submit a patch for this separately. > > Thanks Able. I'm glad you didn't see through our thinly veiled > plan to > entice you into implementing this. :) > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From matthew.dowd at hotmail.co.uk Sun Jul 15 03:40:50 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jul 15 03:40:51 2007 Subject: [sldev] llGiveInventory comedy Message-ID: Even they, they may get a message saying they can't give x whatever because they have muted x, they would probably try to IM x (or find another way of communicating with x) to ask why x had muted *them* Probably would become a frequent post on the forums ;-) Matthew ---------------------------------------- > Date: Sun, 15 Jul 2007 20:35:10 +1000 > To: labrat.hb@gmail.com > Subject: Re: [sldev] llGiveInventory comedy > From: tateru.nino@gmail.com > CC: sldev@lists.secondlife.com > > What happens when they IM you to ask why they can't? > > Harold Brown wrote: > > OK... once more.. this time to the whole list: > > > > > > I'd prefer the "If you have muted someone you can not give them money > > in any fashion, including payments to scripted items" > > > > > > On 7/14/07, *Jason Giglio* > > wrote: > > > > Able Whitman wrote: > > > Ah, people discussing the mute list makes my ears burn! :) I > > like this > > > idea very much, and I've created a JIRA entry for it: > > > https://jira.secondlife.com/browse/VWR-1735 > > > (Directly > > interacting with > > > a muted resident should unmute them). > > > > > > I will try to implement this change in an upcoming release of my > > mute > > > visibility browser, although the changes to implement VWR-1735 > > should be > > > entirely independent of the other mute list changes, so I will > > be able > > > to submit a patch for this separately. > > > > Thanks Able. I'm glad you didn't see through our thinly veiled > > plan to > > entice you into implementing this. :) > > > > -Jason > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From tateru.nino at gmail.com Sun Jul 15 03:44:34 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jul 15 03:44:40 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: References: Message-ID: <4699FA92.2030509@gmail.com> I've already gotten that. Person X has accidentally muted me. Sends me messages. I can't reply. I contact person Y to tell person X that they've accidentally muted me, and I can't answer them. Get more messages like "Why did u mut me? Wat I do rong?" Matthew Dowd wrote: > Even they, they may get a message saying they can't give x whatever because they have muted x, they would probably try to IM x (or find another way of communicating with x) to ask why x had muted *them* > > Probably would become a frequent post on the forums ;-) > > Matthew > > > > ---------------------------------------- > >> Date: Sun, 15 Jul 2007 20:35:10 +1000 >> To: labrat.hb@gmail.com >> Subject: Re: [sldev] llGiveInventory comedy >> From: tateru.nino@gmail.com >> CC: sldev@lists.secondlife.com >> >> What happens when they IM you to ask why they can't? >> >> Harold Brown wrote: >> >>> OK... once more.. this time to the whole list: >>> >>> >>> I'd prefer the "If you have muted someone you can not give them money >>> in any fashion, including payments to scripted items" >>> >>> >>> On 7/14/07, *Jason Giglio* > > wrote: >>> >>> Able Whitman wrote: >>> > Ah, people discussing the mute list makes my ears burn! :) I >>> like this >>> > idea very much, and I've created a JIRA entry for it: >>> > https://jira.secondlife.com/browse/VWR-1735 >>> > (Directly >>> interacting with >>> > a muted resident should unmute them). >>> > >>> > I will try to implement this change in an upcoming release of my >>> mute >>> > visibility browser, although the changes to implement VWR-1735 >>> should be >>> > entirely independent of the other mute list changes, so I will >>> be able >>> > to submit a patch for this separately. >>> >>> Thanks Able. I'm glad you didn't see through our thinly veiled >>> plan to >>> entice you into implementing this. :) >>> >>> -Jason >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> -- >> Tateru Nino >> http://dwellonit.blogspot.com/ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _________________________________________________________________ > Celeb spotting ? Play CelebMashup and win cool prizes > https://www.celebmashup.com/index2.html > -- Tateru Nino http://dwellonit.blogspot.com/ From gigstaggart at gmail.com Sun Jul 15 07:04:45 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jul 15 07:04:51 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <4699FA92.2030509@gmail.com> References: <4699FA92.2030509@gmail.com> Message-ID: <469A297D.5070703@gmail.com> Tateru Nino wrote: > I've already gotten that. Person X has accidentally muted me. Sends me > messages. I can't reply. I contact person Y to tell person X that > they've accidentally muted me, and I can't answer them. Get more > messages like "Why did u mut me? Wat I do rong?" Either method would work equally well I think. It's really down to what is easier to implement: 1. Auto unmute on pay or contact 2. Error messages when they try to pay or contact you. I have a small preference for the first one, because it doesn't require any new UI strings to translate into a dozen languages, putting it in chat history might get missed, and more pop-ups are never a good thing. How many people are trained to hit "OK" without reading popups after sending group IMs now? That "Error messaging group" pop-up has trained people to ignore errors when sending an IM. But really either way works in the end, and would effectively fix the issue. -Jason From tateru.nino at gmail.com Sun Jul 15 07:12:44 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jul 15 07:12:50 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <469A297D.5070703@gmail.com> References: <4699FA92.2030509@gmail.com> <469A297D.5070703@gmail.com> Message-ID: <469A2B5C.6050308@gmail.com> Despite having suggested it, I'm most in favour of option (1). Intuitively it makes the most sense. You're initiating contact explicitly or implicitly, and making sure that communication is possible would seem to be a part of that. It doesn't involve confusing messages. In short, it behaves like people would expect, if they thought it through. Now if we can disable busy mode when someone pays an object.... :) Jason Giglio wrote: > Tateru Nino wrote: >> I've already gotten that. Person X has accidentally muted me. Sends me >> messages. I can't reply. I contact person Y to tell person X that >> they've accidentally muted me, and I can't answer them. Get more >> messages like "Why did u mut me? Wat I do rong?" > > Either method would work equally well I think. > > It's really down to what is easier to implement: > > 1. Auto unmute on pay or contact > 2. Error messages when they try to pay or contact you. > > I have a small preference for the first one, because it doesn't > require any new UI strings to translate into a dozen languages, > putting it in chat history might get missed, and more pop-ups are > never a good thing. > > How many people are trained to hit "OK" without reading popups after > sending group IMs now? That "Error messaging group" pop-up has > trained people to ignore errors when sending an IM. > > But really either way works in the end, and would effectively fix the > issue. > > -Jason > -- Tateru Nino http://dwellonit.blogspot.com/ From dzonatas at dzonux.net Sun Jul 15 07:25:08 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 15 07:24:51 2007 Subject: [sldev] Open Source Viewer, 1.18.0.6.OS.2 released Message-ID: <469A2E44.6050703@dzonux.net> Look here for the new release: http://sourceforge.net/project/showfiles.php?group_id=191214 Download SecondLife-1.18.0.6.OS.2.zip It is still just a Windows only build as we gather-up all these patches. There are a bunch now. You'll notice the Mute Visibility, Partner View-Profile, improved CPU Detection, inlined fasttimer, pie-menu group invite, and more! Here is the list: 1.18.0.6.OS.2 adds these patches: svn.llcontroldef.cpp.release.r51-r61.1.18.0.6.os.2.patch.txt svn.llpreprocessor.h.release.r10-r61.1.18.0.6.os.2.patch.txt svn.llprocessor.cpp.release.r51-r61.1.18.0.6.os.2.patch.txt svn.llprocessor.h.release.r5-r61.1.18.0.6.os.2.patch.txt svn.llviewerjointmesh.h.release.r5-r61.1.18.0.6.os.2.patch.txt svn.viewer.cpp.release.r51-r61.1.18.0.6.os.2.patch.txt vwr-940.1.18.0.6.os.2.patch.txt vwr-962.1.18.0.6.os.2.patch.txt vwr-1017.1.18.0.6.os.2.patch.txt vwr-1062.AND.svn.llsys.release.r10-r61.1.18.0.6.os.2.patch.txt vwr-1651.1.18.0.6.os.2.patch.txt vwr-1736.1.18.0.6.os.2.patch.txt vwr-1748.1.18.0.6.os.2.patch.txt misc-178.1.18.0.6.os.2.patch.txt ---- Patches still applied: svc-371.1.18.0.6.os.1.patch.txt vwr-349.1.18.0.6.os.1.patch.txt vwr-353.1.18.0.6.os.1.patch.txt vwr-777.1.18.0.6.os.0.patch.txt vwr-779.1.18.0.6.os.1.patch.txt vwr-1110.1.18.0.6.os.1.patch.txt vwr-1270.1.18.0.6.os.1.patch.txt vwr-1289.1.18.0.6.os.1.patch.txt vwr-1294.1.18.0.6.os.1.patch.txt vwr-1352.1.18.0.6.os.1.patch.txt vwr-1406.1.18.0.6.os.1.patch.txt vwr-1420.1.18.0.6.os.1.patch.txt vwr-1434.1.18.0.6.os.1.patch.txt vwr-1465.1.18.0.6.os.1.patch.txt vwr-1470.1.18.0.6.os.1.patch.txt vwr-1471.1.18.0.6.os.1.patch.txt vwr-1578.1.18.0.6.os.1.patch.txt vwr-1603.1.18.0.6.os.1.patch.txt vwr-1612.1.18.0.6.os.1.patch.txt vwr-1613.1.18.0.6.os.1.patch.txt vwr-1626.1.18.0.6.os.1.patch.txt vwr-1646.1.18.0.6.os.1.patch.txt vwr-1655.1.18.0.6.os.1.patch.txt vwr-1704.1.18.0.6.os.0.patch.txt vwr-1705.1.18.0.6.os.0.patch.txt vwr-1721.1.18.0.6.os.1.patch.txt vwr-1723.1.18.0.6.os.1.patch.txt vwr-1729.1.18.0.6.os.0.patch.txt Source for the patches are included in the zip file. The "patches" directory contains individual patches while "indra.all.patches.*" contains them all as a single "svn diff". -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070715/80eed017/attachment.htm From nicholaz at blueflash.cc Sun Jul 15 09:00:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 15 09:00:27 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <469A2B5C.6050308@gmail.com> References: <4699FA92.2030509@gmail.com> <469A297D.5070703@gmail.com> <469A2B5C.6050308@gmail.com> Message-ID: <469A448B.1020405@blueflash.cc> I'd also support the first version (auto unmute). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Tateru Nino wrote: > Despite having suggested it, I'm most in favour of option (1). > Intuitively it makes the most sense. You're initiating contact > explicitly or implicitly, and making sure that communication is possible > would seem to be a part of that. It doesn't involve confusing messages. > In short, it behaves like people would expect, if they thought it through. From dzonatas at dzonux.net Sun Jul 15 09:08:22 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 15 09:08:05 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <469A448B.1020405@blueflash.cc> References: <4699FA92.2030509@gmail.com> <469A297D.5070703@gmail.com> <469A2B5C.6050308@gmail.com> <469A448B.1020405@blueflash.cc> Message-ID: <469A4676.2030408@dzonux.net> Yep. Auto-unmute should be the default, but allow the option to turn off auto-unmute. Everybody wins! Nicholaz Beresford wrote: > > I'd also support the first version (auto unmute). > > > Nick > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Tateru Nino wrote: >> Despite having suggested it, I'm most in favour of option (1). >> Intuitively it makes the most sense. You're initiating contact >> explicitly or implicitly, and making sure that communication is possible >> would seem to be a part of that. It doesn't involve confusing messages. >> In short, it behaves like people would expect, if they thought it >> through. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From matthew.dowd at hotmail.co.uk Sun Jul 15 09:26:37 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jul 15 09:26:39 2007 Subject: [sldev] llGiveInventory comedy Message-ID: Except according to Soft the UI guys at LL want to cut down on the number of configuration options not increase them - I suggest making the setting accessible through debug settings only? Matthew ---------------------------------------- > Date: Sun, 15 Jul 2007 09:08:22 -0700 > From: dzonatas@dzonux.net > To: nicholaz@blueflash.cc > Subject: Re: [sldev] llGiveInventory comedy > CC: sldev@lists.secondlife.com > > Yep. Auto-unmute should be the default, but allow the option to turn off > auto-unmute. Everybody wins! > > Nicholaz Beresford wrote: > > > > I'd also support the first version (auto unmute). > > > > > > Nick > > > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > > > > > Tateru Nino wrote: > >> Despite having suggested it, I'm most in favour of option (1). > >> Intuitively it makes the most sense. You're initiating contact > >> explicitly or implicitly, and making sure that communication is possible > >> would seem to be a part of that. It doesn't involve confusing messages. > >> In short, it behaves like people would expect, if they thought it > >> through. > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From nicholaz at blueflash.cc Sun Jul 15 09:28:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jul 15 09:28:34 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: References: Message-ID: <469A4B23.4040500@blueflash.cc> Probably nobody will find find this option (or, speaking from experience of my own software, understand what it is for, even if they find it). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matthew Dowd wrote: > Except according to Soft the UI guys at LL want to cut down on the number of configuration options not increase them - I suggest making the setting accessible through debug settings only? > > Matthew > > > > > ---------------------------------------- >> Date: Sun, 15 Jul 2007 09:08:22 -0700 >> From: dzonatas@dzonux.net >> To: nicholaz@blueflash.cc >> Subject: Re: [sldev] llGiveInventory comedy >> CC: sldev@lists.secondlife.com >> >> Yep. Auto-unmute should be the default, but allow the option to turn off >> auto-unmute. Everybody wins! >> >> Nicholaz Beresford wrote: >>> I'd also support the first version (auto unmute). >>> >>> >>> Nick >>> >>> Second Life from the inside out: >>> http://nicholaz-beresford.blogspot.com/ >>> >>> >>> Tateru Nino wrote: >>>> Despite having suggested it, I'm most in favour of option (1). >>>> Intuitively it makes the most sense. You're initiating contact >>>> explicitly or implicitly, and making sure that communication is possible >>>> would seem to be a part of that. It doesn't involve confusing messages. >>>> In short, it behaves like people would expect, if they thought it >>>> through. >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > The next generation of MSN Hotmail has arrived - Windows Live Hotmail > http://www.newhotmail.co.uk From dzonatas at dzonux.net Sun Jul 15 09:36:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 15 09:36:42 2007 Subject: UI Re: [sldev] llGiveInventory comedy In-Reply-To: References: Message-ID: <469A4D2B.5060601@dzonux.net> Which of course, brings up the question of how to make a configurable UI with less options. Given there is this: https://wiki.secondlife.com/wiki/User_Interface_Roadmap I know one... scripts. Matthew Dowd wrote: > Except according to Soft the UI guys at LL want to cut down on the number of configuration options not increase them - I suggest making the setting accessible through debug settings only? > > Matthew > > > > > ---------------------------------------- > >> Date: Sun, 15 Jul 2007 09:08:22 -0700 >> From: dzonatas@dzonux.net >> To: nicholaz@blueflash.cc >> Subject: Re: [sldev] llGiveInventory comedy >> CC: sldev@lists.secondlife.com >> >> Yep. Auto-unmute should be the default, but allow the option to turn off >> auto-unmute. Everybody wins! >> >> Nicholaz Beresford wrote: >> >>> I'd also support the first version (auto unmute). >>> >>> >>> Nick >>> >>> Second Life from the inside out: >>> http://nicholaz-beresford.blogspot.com/ >>> >>> >>> Tateru Nino wrote: >>> >>>> Despite having suggested it, I'm most in favour of option (1). >>>> Intuitively it makes the most sense. You're initiating contact >>>> explicitly or implicitly, and making sure that communication is possible >>>> would seem to be a part of that. It doesn't involve confusing messages. >>>> In short, it behaves like people would expect, if they thought it >>>> through. >>>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >>> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _________________________________________________________________ > The next generation of MSN Hotmail has arrived - Windows Live Hotmail > http://www.newhotmail.co.uk > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070715/1cd5ea7f/attachment.htm From alvargi at hotmail.com Sun Jul 15 10:38:52 2007 From: alvargi at hotmail.com (Alvargi) Date: Sun Jul 15 10:38:52 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: Message-ID: It's been my experience that when people have problems with a product they will contact the seller/creator via the name listed in the Creator attribute of the object in question. Suggestions: Detect when the profile dialog has been invoked from the creator "Profile..." button on the edit object dialog. When a user clicks on the IM button in the profile dialog, it checks to see if the creator is on the mute list and presents a dialog to that effect. Or... to further simplify this you could always warn when a person is muted when any UI action to IM them is performed. No need to detect if someone has purchased anything etc. Alv -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Matthew Dowd Sent: Sunday, July 15, 2007 9:27 AM To: Dzonatas; Nicholaz Beresford Cc: Second Life Developer Mailing List Subject: RE: [sldev] llGiveInventory comedy Except according to Soft the UI guys at LL want to cut down on the number of configuration options not increase them - I suggest making the setting accessible through debug settings only? Matthew ---------------------------------------- > Date: Sun, 15 Jul 2007 09:08:22 -0700 > From: dzonatas@dzonux.net > To: nicholaz@blueflash.cc > Subject: Re: [sldev] llGiveInventory comedy > CC: sldev@lists.secondlife.com > > Yep. Auto-unmute should be the default, but allow the option to turn off > auto-unmute. Everybody wins! > > Nicholaz Beresford wrote: > > > > I'd also support the first version (auto unmute). > > > > > > Nick > > > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > > > > > Tateru Nino wrote: > >> Despite having suggested it, I'm most in favour of option (1). > >> Intuitively it makes the most sense. You're initiating contact > >> explicitly or implicitly, and making sure that communication is possible > >> would seem to be a part of that. It doesn't involve confusing messages. > >> In short, it behaves like people would expect, if they thought it > >> through. > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk_______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From sldev at catznip.com Sun Jul 15 11:44:42 2007 From: sldev at catznip.com (Kitty) Date: Sun Jul 15 11:41:00 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <469A2B5C.6050308@gmail.com> References: <4699FA92.2030509@gmail.com> <469A297D.5070703@gmail.com> <469A2B5C.6050308@gmail.com> Message-ID: <001801c7c710$381123c0$0501a8c0@devbits.intra> > Despite having suggested it, I'm most in favour of option (1). > Intuitively it makes the most sense. You're initiating > contact explicitly or implicitly, and making sure that > communication is possible would seem to be a part of that. It > doesn't involve confusing messages. > In short, it behaves like people would expect, if they > thought it through. If it's too easy to accidently mute someone, then that's the actual problem that should be addressed I'd think. If you accidently muted someone and you pay them then the unmuting is helpful, but if that person was supposed to be on mute then unmuting is not what people would expect (not every transaction is about vendors). Upon opening an IM, seeing a "You have (Name Here) muted, you will not be able to receive inventory or see any responses." should be sufficient and it follows the current "is offline" feature when IM'ing someone on your friends list who's offline. Kitty From Paul.Hampson at Pobox.com Sun Jul 15 11:45:27 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sun Jul 15 11:45:37 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <1184482831.3313.5.camel@localhost> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <1184482831.3313.5.camel@localhost> Message-ID: <20070715184527.GA881@keitarou> On Sun, Jul 15, 2007 at 02:00:31AM -0500, Callum Lerwick wrote: > On Sun, 2007-07-15 at 04:00 +1000, Paul TBBle Hampson wrote: >> The only issue then is convincing SCons to put an rpath into the client. > Bad idea: In short, rpath has its uses. The issue arises because 90% of rpath usage used to come from libtool's "make install" handler rpathing everthing to the prefix, which is not what most packagers want. Everything below this point is explanation of the above. Something to keep in mind while looking at the below, is that the shared objects being created at the moment by the SConstruct script don't have SONAME or NEEDED headers (except llimage got a NEEDED header for llimagej2coj) so ld.so _can't_ do any better than load the first one it finds in its search path. (Which rpaths appear at the front of) > http://fedoraproject.org/wiki/Packaging/Guidelines#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544 "Often, rpath is used because a binary is looking for libraries in a non-standard location (standard locations are /lib, /usr/lib, /lib64, /usr/lib64). If you are storing a library in a non-standard location (e.g. /usr/lib/foo/), you should include a custom config file in /etc/ld.so.conf.d/." This is daft, as I'm not trying to make these .so files available to anything that isn't part of the same package build, let alone other packages on the system. Still if Fedora forbids rpath, then don't use it for Fedora. They provide an alternative above, faulty as it may be. Just don't put anything in the upstream install script that assumes adding things to /etc/ld.so.conf.d/ is a generally good idea, without going ahead and doing proper SONAMEing first. If you want to be treated like a first-class .so file, you have to act like one first. > http://wiki.debian.org/RpathIssue "Currently, the only valid use of this feature in Debian is to add non-standard library path (like /usr/lib/) to libraries that are only intended to be used by the executables (or other libraries) within the package." This is what I'm trying to do. I've edited the page to make this a seperate paragraph, since you seem to have missed this on your first reading. > http://people.debian.org/?che/personal/rpath-considered-harmful "The use of the -R or -rpath linker options to hard code a dynamic library search path into a binary is considered harmful for all cases except for a user linking against a library installed in their own home directory." Again, this is talking about rpaths to libraries that come with the operating system. Neither of the issues described here apply to libraries which _must_ be upgraded along with all their dependants simultaneously. This is also talking about rpaths set at 'make install' time to be the directory being installed into. His description is a little dodgey though, historically PREFIX works that way, DESTDIR does not, as DESTDIR is there for redirecting the install location _without_ affecting the prefix (assumed top-level path). If it helps you keep the issue clear, pretend private libraries are like dynamically-loadable modules, not .so files. You wouldn't expect to find your program's modules in /usr/lib, that'd be daft. You'd have to scan every file in /usr/lib for the appropriate exported structure to tell you that it was a module, and hope you were the only program that thought "struct module_ops" was a good way of telling your modules apart from random chunks of code. Instead, you pick module directory (or let the user specificy one) and assume everything in there that exports a struct module_ops is a module, exporting _your_ module_ops, and you therefore dlopen it, get the address of module_ops, and start using the function pointers therein. That's all we're doing here, except we don't have to use dlopen, we declare the modules we want at build-time, and ld.so takes that plus our build-time declared module path, and does the load-time equivalent of dlopen + filling in the undefined references in the executable. And in case you think this is academic, FreeRADIUS uses rpath to point to its modules directory, and then dlopens rlm_[modname].so knowing that the only way a random could drop rlm_[modname].so into /usr/lib and have FreeRADIUS use that by accident, is if rlm_[modname].so didn't exist in the rpath. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070716/a717ca74/attachment.pgp From dale at daleglass.net Sun Jul 15 17:41:24 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Jul 15 17:41:42 2007 Subject: [sldev] Doxygen docs updated Message-ID: <20070716004124.GA26145@bruno.sbruno> Hi! Previously I mentioned I had doxygen docs here: http://doc.daleglass.net/index.html And people seemed to find the idea useful. The docs out of date though, as they were generated from rather ancient source. I just fixed the script to regenerate them daily against my "release" branch daily. This should be reasonably up to date as it's what I use as my normal viewer. So, if anybody has an use for this, feel free to use the copy hosted on my server. The hierarchy of my repository is explained here, if anybody is interested: https://wiki.secondlife.com/wiki/User:Dale_Glass#Subversion_Repository -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070716/71b2b03d/attachment.pgp From dale at daleglass.net Sun Jul 15 18:03:42 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Jul 15 18:03:48 2007 Subject: [sldev] Checking for updates for third party viewers via HTTP Message-ID: <20070716010342.GB26145@bruno.sbruno> I've been passing my custom viewer around a bit, but a problem with that was that I have a very active development ATM, and poking everybody to download a new installer is a pain. And since the grid doesn't know about my release process, the normal mechanism won't work. So I made my own. It works by doing an HTTP request and parsing the results. To get a patch for my implementation, diff these files between my buildfixes-1-18-0 and branding branches: See this for details on my repository: https://wiki.secondlife.com/wiki/User:Dale_Glass#Subversion_Repository indra/llcommon/llversion.h indra/newview/llstartup.h indra/newview/llstartup.cpp The code requests http://daleglass.net/viewer_update_check, with these arguments: server, major, minor, patch, build, rev, and digest. Server is the user server and used to determine the viewer needed for the specific grid. major, minor, patch and build are components of the SL version number. revision is my SVN revision number. digest is the viewer digest and used as insurance in case I distribute two different binaries under the same version number by mistake. The result it outputs is the XML form of LLSD: update_available true update_required true last_version 1.18.0.6.64 message message to viewer Format should be self-explanatory. If no update is available, the update_required, last_version and message fields will be missing. If anybody wants to play with it, try this as arguments: major=1&minor=18&patch=0&build=6&rev=64 rev < 64 will result in an "update required" response. server and digest aren't currently used by the script. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070716/ee50da32/attachment.pgp From alissa_sabre at yahoo.co.jp Sun Jul 15 19:19:42 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun Jul 15 19:20:02 2007 Subject: [sldev] Local variable names in llwindowmacosx.cpp Message-ID: <8Qdsbds8G07ds4ds4dwQLzmc.alissa_sabre@yahoo.co.jp> I have a question on coding standards. I'm now tweaking linden/indra/llwindow/llwindowmacosx.cpp, and found that most of the local variable names in this file are in camel case. It apparently violates the LL coding standards. Should I (1) report it as an issue on JIRA (with a patch) or (2) just leave it? Assuming the answer to the above question is (2), what naming convention should variables in my new code added to the file look like? A camel case or a all lowercase with underlines? Opinions? Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From dzonatas at dzonux.net Sun Jul 15 19:52:54 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 15 19:52:57 2007 Subject: [sldev] Local variable names in llwindowmacosx.cpp In-Reply-To: <8Qdsbds8G07ds4ds4dwQLzmc.alissa_sabre@yahoo.co.jp> References: <8Qdsbds8G07ds4ds4dwQLzmc.alissa_sabre@yahoo.co.jp> Message-ID: <469ADD86.3060709@dzonux.net> We accept code clean-up. With every change made it still needs to be tested. That's why most code doesn't get cleaned-up -- to avoid another costly test phase. Alissa Sabre wrote: > I have a question on coding standards. > > I'm now tweaking linden/indra/llwindow/llwindowmacosx.cpp, and found > that most of the local variable names in this file are in camel case. > It apparently violates the LL coding standards. > > Should I > > (1) report it as an issue on JIRA (with a patch) > > or > > (2) just leave it? > > Assuming the answer to the above question is (2), what naming > convention should variables in my new code added to the file look > like? A camel case or a all lowercase with underlines? > > Opinions? > > Alissa Sabre > -------------------------------------- > Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar > http://pr.mail.yahoo.co.jp/toolbar/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- Power to Change the Void From hud at zurich.ibm.com Mon Jul 16 00:18:58 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Jul 16 05:43:10 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <4697B1D7.4090208@lindenlab.com> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> <4697B1D7.4090208@lindenlab.com> Message-ID: <469B1BE2.9000309@zurich.ibm.com> Jake Simpson wrote: > "One thing that might help is if there was some way to "refresh" the > list (Obviously at a frequency that didn't overload things)." > > We looked at this - the trouble is the way that the system says "Give > me that list of people" is also the same system that says - at the > same time - "I am logged on all you wonderful people - please update > your friends lists" to all those people who are logged on. Without > knowing if this problem is both ways (ie those people you can't see > the correct status of can't see you), it may be a bit much to ask of > the system. > > To be honest, I'd rather fix the issue at root so we don't have to > refresh the list, and that it just work as it's supposed to? > > Jake i'm not sure whether that's related but sometimes when we retrieve group listings (for our automated group management tool), the grid will give us incomplete lists --- incomplete in that the list will not contain all members of the group (we end up sending out an invite to those members who then are rather surprised because they've been and are members of that group for ages); for example, the grid will tell us that there are 2778 members in the group, we do get 2778 entries, but in reality there are more than that. cheers, dirk From dzonatas at dzonux.net Mon Jul 16 08:18:43 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 16 08:18:44 2007 Subject: [sldev] About the Open Source Viewer Message-ID: <469B8C53.9040605@dzonux.net> I wrote up a wiki page about the Open Source Viewer. http://wiki.secondlife.com/wiki/Open_Source_Viewer -- Power to Change the Void From secret.argent at gmail.com Mon Jul 16 08:49:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 16 08:49:05 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> References: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> Message-ID: <5B92B97A-4232-4F7C-B6C6-566CAD2639C4@gmail.com> Jason Giglio asks: > 1. Auto unmute on pay or contact > 2. Error messages when they try to pay or contact you. I agree with your comments later in the message and vote for #1. From secret.argent at gmail.com Mon Jul 16 08:51:19 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 16 08:50:58 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> References: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> Message-ID: <2E3DB0E9-72CE-4671-98F7-91E2DE265D52@gmail.com> Tateru Nino writes: > Now if we can disable busy mode when someone pays an object.... :) I'd vote for this one as well. And any other time you do something in busy mode that invites a response. From tateru.nino at gmail.com Mon Jul 16 08:52:47 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jul 16 08:52:57 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: <2E3DB0E9-72CE-4671-98F7-91E2DE265D52@gmail.com> References: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> <2E3DB0E9-72CE-4671-98F7-91E2DE265D52@gmail.com> Message-ID: <469B944F.5070401@gmail.com> Argent Stonecutter wrote: > Tateru Nino writes: >> Now if we can disable busy mode when someone pays an object.... :) > > I'd vote for this one as well. And any other time you do something in > busy mode that invites a response. Want to JIRA that up? -- Tateru Nino http://dwellonit.blogspot.com/ From kelly at lindenlab.com Mon Jul 16 09:14:50 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Mon Jul 16 09:14:53 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469B1BE2.9000309@zurich.ibm.com> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> <4697B1D7.4090208@lindenlab.com> <469B1BE2.9000309@zurich.ibm.com> Message-ID: <469B997A.8090703@lindenlab.com> dirk husemann wrote: > i'm not sure whether that's related but sometimes when we retrieve group > listings (for our automated group management tool), the grid will give > us incomplete lists --- incomplete in that the list will not contain all > members of the group (we end up sending out an invite to those members > who then are rather surprised because they've been and are members of > that group for ages); for example, the grid will tell us that there are > 2778 members in the group, we do get 2778 entries, but in reality there > are more than that. > > cheers, > dirk > > dirk, This is a separate issue, as you guessed. If you could jira it, if it isn't already, with any details you have that would help. From bos at lindenlab.com Mon Jul 16 10:57:51 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jul 16 10:57:56 2007 Subject: [sldev] Re: shared objects output during standalone build (Was: releasefordownload - linux) In-Reply-To: <20070714180001.GA20761@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> Message-ID: <469BB19F.1000509@lindenlab.com> Paul TBBle Hampson wrote: > I see Sardonyx Linden has marked this as fixed internally. What was the > fix? We switched to compiling the files that need to go into libllimage.so with -fpic, but generating "ar" archives with them (as we had been doing before) instead of shared objects. > I'm hoping it wasn't unsharing the shared objects, because I'm pretty > sure building those as shared objects cut my build time by about an hour > (from three to two), unless someone else can suggest a different 1.17 to > 1.18 change that would cause that? I can't suggest what might have changed this, but I'm skeptical that it could have had anything to do with a change of library type. > which I'm guessing is the result of inlining, so unless there's some kind > of performance penalty for using shared libraries, I'm all for this > state of affairs continuing and even encompassing more. I believe there > was a Jira issue around for .soing more of the client... I'm afraid that doesn't make any sense. Using shared objects increases viewer startup time and makes packaging more of a pain. References: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> <2E3DB0E9-72CE-4671-98F7-91E2DE265D52@gmail.com> <469B944F.5070401@gmail.com> Message-ID: Vote it up! https://jira.secondlife.com/browse/VWR-1735 On 7/16/07, Tateru Nino wrote: > Argent Stonecutter wrote: > > Tateru Nino writes: > >> Now if we can disable busy mode when someone pays an object.... :) > > > > I'd vote for this one as well. And any other time you do something in > > busy mode that invites a response. > Want to JIRA that up? > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sl-dev at theblob.org Mon Jul 16 11:03:13 2007 From: sl-dev at theblob.org (Kiwi Alfa) Date: Mon Jul 16 11:03:16 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469B8C53.9040605@dzonux.net> References: <469B8C53.9040605@dzonux.net> Message-ID: Hi, I'm a long-time lurker on this list, and I think this may be my first post, but I just wanted to mention that this could cause confusion since the viewer is already open source - the name makes it sound as if Linden Labs' own viewer *isn't* open source, which isn't true. Just my two cents. :) (I'll probably introduce myself properly at some stage.) - Kiwi. On 7/16/07, Dzonatas wrote: > I wrote up a wiki page about the Open Source Viewer. > > http://wiki.secondlife.com/wiki/Open_Source_Viewer > > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From bos at lindenlab.com Mon Jul 16 11:06:44 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jul 16 11:06:46 2007 Subject: [sldev] Local variable names in llwindowmacosx.cpp In-Reply-To: <8Qdsbds8G07ds4ds4dwQLzmc.alissa_sabre@yahoo.co.jp> References: <8Qdsbds8G07ds4ds4dwQLzmc.alissa_sabre@yahoo.co.jp> Message-ID: <469BB3B4.9000202@lindenlab.com> Alissa Sabre asked about coding style. > (1) report it as an issue on JIRA (with a patch) Code cleanups for their own sake generally make us a bit nervous. We're quite bandwidth limited, and cleanups take as much effort to review, apply, and test as actual bug fixes. > (2) just leave it? That would generally be the preferred approach. > Assuming the answer to the above question is (2), what naming > convention should variables in my new code added to the file look > like? A camel case or a all lowercase with underlines? It's often best to fit in with the prevailing style in a given source file or context, even if that's at odds with LL's general standards. This doesn't extend to unsafe coding practices, though. If nearby code is using sprintf or such, don't use it yourself :-) References: <469B8C53.9040605@dzonux.net> Message-ID: <469BB422.6070101@gwala.net> 'Community Viewer' might be a better (and more accurate) name. Adam Kiwi Alfa wrote: > Hi, > > I'm a long-time lurker on this list, and I think this may be my first > post, but I just wanted to mention that this could cause confusion > since the viewer is already open source - the name makes it sound as > if Linden Labs' own viewer *isn't* open source, which isn't true. > > Just my two cents. :) (I'll probably introduce myself properly at some > stage.) > > - Kiwi. > > On 7/16/07, Dzonatas wrote: > >> I wrote up a wiki page about the Open Source Viewer. >> >> http://wiki.secondlife.com/wiki/Open_Source_Viewer >> >> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Mon Jul 16 11:12:07 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 16 11:12:08 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: References: <469B8C53.9040605@dzonux.net> Message-ID: <469BB4F7.3020705@dzonux.net> Interesting view. I put it on the Agenda: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Kiwi Alfa wrote: > Hi, > > I'm a long-time lurker on this list, and I think this may be my first > post, but I just wanted to mention that this could cause confusion > since the viewer is already open source - the name makes it sound as > if Linden Labs' own viewer *isn't* open source, which isn't true. > > Just my two cents. :) (I'll probably introduce myself properly at some > stage.) > > - Kiwi. > > On 7/16/07, Dzonatas wrote: >> I wrote up a wiki page about the Open Source Viewer. >> >> http://wiki.secondlife.com/wiki/Open_Source_Viewer >> >> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > -- Power to Change the Void From jhurliman at wsu.edu Mon Jul 16 11:50:48 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jul 16 11:52:15 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BB4F7.3020705@dzonux.net> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> Message-ID: <469BBE08.4030809@wsu.edu> In hindsight OpenSL was a bad enough name for a fork of the viewer, but "Open Source Viewer" is just ridiculous. That's like calling Ubuntu "Open Source Linux". Not only does the name mis-convey what the project does (without context it sounds like a free image viewing app), but as previously mentioned every SL viewer is open source. At worst this could be conveyed as an attempt to discredit existing SL viewers. Dzonatas wrote: > Interesting view. > > I put it on the Agenda: > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > > Kiwi Alfa wrote: >> Hi, >> >> I'm a long-time lurker on this list, and I think this may be my first >> post, but I just wanted to mention that this could cause confusion >> since the viewer is already open source - the name makes it sound as >> if Linden Labs' own viewer *isn't* open source, which isn't true. >> >> Just my two cents. :) (I'll probably introduce myself properly at >> some stage.) >> >> - Kiwi. >> >> On 7/16/07, Dzonatas wrote: >>> I wrote up a wiki page about the Open Source Viewer. >>> >>> http://wiki.secondlife.com/wiki/Open_Source_Viewer >>> >>> >>> -- >>> Power to Change the Void >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> >> > From dzonatas at dzonux.net Mon Jul 16 12:13:29 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 16 12:13:30 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BBE08.4030809@wsu.edu> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BBE08.4030809@wsu.edu> Message-ID: <469BC359.80501@dzonux.net> It was never meant to be so aggressively profound like that. I had other ideas for a name, but I settled on something just bland and more so generic. See my sentiments here: https://lists.secondlife.com/pipermail/sldev/2007-July/003329.html Obviously, I'm open for a new name for it. John Hurliman wrote: > In hindsight OpenSL was a bad enough name for a fork of the viewer, > but "Open Source Viewer" is just ridiculous. That's like calling > Ubuntu "Open Source Linux". Not only does the name mis-convey what the > project does (without context it sounds like a free image viewing > app), but as previously mentioned every SL viewer is open source. At > worst this could be conveyed as an attempt to discredit existing SL > viewers. > > > Dzonatas wrote: >> Interesting view. >> >> I put it on the Agenda: >> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >> >> >> Kiwi Alfa wrote: >>> Hi, >>> >>> I'm a long-time lurker on this list, and I think this may be my first >>> post, but I just wanted to mention that this could cause confusion >>> since the viewer is already open source - the name makes it sound as >>> if Linden Labs' own viewer *isn't* open source, which isn't true. >>> >>> Just my two cents. :) (I'll probably introduce myself properly at >>> some stage.) >>> >>> - Kiwi. >>> >>> On 7/16/07, Dzonatas wrote: >>>> I wrote up a wiki page about the Open Source Viewer. >>>> >>>> http://wiki.secondlife.com/wiki/Open_Source_Viewer >>>> >>>> >>>> -- >>>> Power to Change the Void >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> >>> >>> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From matthew.dowd at hotmail.co.uk Mon Jul 16 13:15:53 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jul 16 13:15:55 2007 Subject: [sldev] About the Open Source Viewer Message-ID: Well, I'd propose to call it what it is so possibilities are Open Source Test Viewer Open Source Development Viewer Open Source Sandbox Viewer Open Source Contributions Sandbox Viewer Matthew ---------------------------------------- > Date: Mon, 16 Jul 2007 12:13:29 -0700 > From: dzonatas@dzonux.net > To: jhurliman@wsu.edu > Subject: Re: [sldev] About the Open Source Viewer > CC: sldev@lists.secondlife.com > > It was never meant to be so aggressively profound like that. > > I had other ideas for a name, but I settled on something just bland and > more so generic. > > See my sentiments here: > https://lists.secondlife.com/pipermail/sldev/2007-July/003329.html > > Obviously, I'm open for a new name for it. > > John Hurliman wrote: > > In hindsight OpenSL was a bad enough name for a fork of the viewer, > > but "Open Source Viewer" is just ridiculous. That's like calling > > Ubuntu "Open Source Linux". Not only does the name mis-convey what the > > project does (without context it sounds like a free image viewing > > app), but as previously mentioned every SL viewer is open source. At > > worst this could be conveyed as an attempt to discredit existing SL > > viewers. > > > > > > Dzonatas wrote: > >> Interesting view. > >> > >> I put it on the Agenda: > >> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > >> > >> > >> Kiwi Alfa wrote: > >>> Hi, > >>> > >>> I'm a long-time lurker on this list, and I think this may be my first > >>> post, but I just wanted to mention that this could cause confusion > >>> since the viewer is already open source - the name makes it sound as > >>> if Linden Labs' own viewer *isn't* open source, which isn't true. > >>> > >>> Just my two cents. :) (I'll probably introduce myself properly at > >>> some stage.) > >>> > >>> - Kiwi. > >>> > >>> On 7/16/07, Dzonatas wrote: > >>>> I wrote up a wiki page about the Open Source Viewer. > >>>> > >>>> http://wiki.secondlife.com/wiki/Open_Source_Viewer > >>>> > >>>> > >>>> -- > >>>> Power to Change the Void > >>>> _______________________________________________ > >>>> Click here to unsubscribe or manage your list subscription: > >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >>>> > >>>> > >>> > >>> > >> > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From nicholaz at blueflash.cc Mon Jul 16 13:26:46 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 16 13:27:04 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: References: Message-ID: <469BD486.7030003@blueflash.cc> Dzonatas Edition JIRA-Patch Testbed JIRA-Patch Viewer Patch-Test Edition Patch Frontrunner Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matthew Dowd wrote: > Well, I'd propose to call it what it is so possibilities are > > Open Source Test Viewer > Open Source Development Viewer > Open Source Sandbox Viewer > Open Source Contributions Sandbox Viewer > > Matthew > > > > > > > ---------------------------------------- >> Date: Mon, 16 Jul 2007 12:13:29 -0700 >> From: dzonatas@dzonux.net >> To: jhurliman@wsu.edu >> Subject: Re: [sldev] About the Open Source Viewer >> CC: sldev@lists.secondlife.com >> >> It was never meant to be so aggressively profound like that. >> >> I had other ideas for a name, but I settled on something just bland and >> more so generic. >> >> See my sentiments here: >> https://lists.secondlife.com/pipermail/sldev/2007-July/003329.html >> >> Obviously, I'm open for a new name for it. >> >> John Hurliman wrote: >>> In hindsight OpenSL was a bad enough name for a fork of the viewer, >>> but "Open Source Viewer" is just ridiculous. That's like calling >>> Ubuntu "Open Source Linux". Not only does the name mis-convey what the >>> project does (without context it sounds like a free image viewing >>> app), but as previously mentioned every SL viewer is open source. At >>> worst this could be conveyed as an attempt to discredit existing SL >>> viewers. >>> >>> >>> Dzonatas wrote: >>>> Interesting view. >>>> >>>> I put it on the Agenda: >>>> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >>>> >>>> >>>> Kiwi Alfa wrote: >>>>> Hi, >>>>> >>>>> I'm a long-time lurker on this list, and I think this may be my first >>>>> post, but I just wanted to mention that this could cause confusion >>>>> since the viewer is already open source - the name makes it sound as >>>>> if Linden Labs' own viewer *isn't* open source, which isn't true. >>>>> >>>>> Just my two cents. :) (I'll probably introduce myself properly at >>>>> some stage.) >>>>> >>>>> - Kiwi. >>>>> >>>>> On 7/16/07, Dzonatas wrote: >>>>>> I wrote up a wiki page about the Open Source Viewer. >>>>>> >>>>>> http://wiki.secondlife.com/wiki/Open_Source_Viewer >>>>>> >>>>>> >>>>>> -- >>>>>> Power to Change the Void >>>>>> _______________________________________________ >>>>>> Click here to unsubscribe or manage your list subscription: >>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>>>> >>>>>> >>>>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Celeb spotting ? Play CelebMashup and win cool prizes > https://www.celebmashup.com/index2.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Mon Jul 16 13:31:57 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 16 13:31:59 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BD486.7030003@blueflash.cc> References: <469BD486.7030003@blueflash.cc> Message-ID: <7b3a84fb0707161331u113db401ma0a3d333761aa7d@mail.gmail.com> I like "Sandbox Edition". It's short, simple, jargon-free, and tidily describes what it's meant to do: serve as a sandbox for patches before they are integrated into the official viewer. On 7/16/07, Nicholaz Beresford wrote: > > > Dzonatas Edition > JIRA-Patch Testbed > JIRA-Patch Viewer > Patch-Test Edition > Patch Frontrunner > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Matthew Dowd wrote: > > Well, I'd propose to call it what it is so possibilities are > > > > Open Source Test Viewer > > Open Source Development Viewer > > Open Source Sandbox Viewer > > Open Source Contributions Sandbox Viewer > > > > Matthew > > > > > > > > > > > > > > ---------------------------------------- > >> Date: Mon, 16 Jul 2007 12:13:29 -0700 > >> From: dzonatas@dzonux.net > >> To: jhurliman@wsu.edu > >> Subject: Re: [sldev] About the Open Source Viewer > >> CC: sldev@lists.secondlife.com > >> > >> It was never meant to be so aggressively profound like that. > >> > >> I had other ideas for a name, but I settled on something just bland and > >> more so generic. > >> > >> See my sentiments here: > >> https://lists.secondlife.com/pipermail/sldev/2007-July/003329.html > >> > >> Obviously, I'm open for a new name for it. > >> > >> John Hurliman wrote: > >>> In hindsight OpenSL was a bad enough name for a fork of the viewer, > >>> but "Open Source Viewer" is just ridiculous. That's like calling > >>> Ubuntu "Open Source Linux". Not only does the name mis-convey what the > >>> project does (without context it sounds like a free image viewing > >>> app), but as previously mentioned every SL viewer is open source. At > >>> worst this could be conveyed as an attempt to discredit existing SL > >>> viewers. > >>> > >>> > >>> Dzonatas wrote: > >>>> Interesting view. > >>>> > >>>> I put it on the Agenda: > >>>> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > >>>> > >>>> > >>>> Kiwi Alfa wrote: > >>>>> Hi, > >>>>> > >>>>> I'm a long-time lurker on this list, and I think this may be my > first > >>>>> post, but I just wanted to mention that this could cause confusion > >>>>> since the viewer is already open source - the name makes it sound as > >>>>> if Linden Labs' own viewer *isn't* open source, which isn't true. > >>>>> > >>>>> Just my two cents. :) (I'll probably introduce myself properly at > >>>>> some stage.) > >>>>> > >>>>> - Kiwi. > >>>>> > >>>>> On 7/16/07, Dzonatas wrote: > >>>>>> I wrote up a wiki page about the Open Source Viewer. > >>>>>> > >>>>>> http://wiki.secondlife.com/wiki/Open_Source_Viewer > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Power to Change the Void > >>>>>> _______________________________________________ > >>>>>> Click here to unsubscribe or manage your list subscription: > >>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >>>>>> > >>>>>> > >>>>> > >>> _______________________________________________ > >>> Click here to unsubscribe or manage your list subscription: > >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >>> > >>> > >> -- > >> Power to Change the Void > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _________________________________________________________________ > > Celeb spotting ? Play CelebMashup and win cool prizes > > > https://www.celebmashup.com/index2.html_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > 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/20070716/9095f798/attachment.htm From nicholaz at blueflash.cc Mon Jul 16 13:39:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 16 13:39:39 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <7b3a84fb0707161331u113db401ma0a3d333761aa7d@mail.gmail.com> References: <469BD486.7030003@blueflash.cc> <7b3a84fb0707161331u113db401ma0a3d333761aa7d@mail.gmail.com> Message-ID: <469BD77C.2020505@blueflash.cc> Able Whitman wrote: > I like "Sandbox Edition". It's short, simple, jargon-free, and tidily > describes what it's meant to do: serve as a sandbox for patches before > they are integrated into the official viewer. I really like that one ... sounds friendly somehow :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From seg at haxxed.com Mon Jul 16 14:06:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jul 16 14:09:00 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection Message-ID: <1184620013.26499.21.camel@localhost.localdomain> As you may know I have been involved in optimizing OpenJPEG, and I have run in to what is becoming a common problem. Detecting and using extensions such as SSE. This is very messy to do in a cross-platform manner, and really should be in a universally usable library, where it can be done right once, and be used everywhere. Well, I've found a promising candidate, liboil: http://liboil.freedesktop.org/wiki/ It is the "library of optimized inner loops", its goal is to implement common operations optimally, in a runtime switchable manner. It is BSD licensed so commercial use in slviewer is not a problem, and it is already included in most Linux distributions, some gstreamer codecs seem to use it. I am considering using it for OpenJPEG, for runtime CPU detection, and it also has functions for converting an array between ints and float which would be useful. One issue is that it is currently gcc-centric, this would mean for best results on Windows, it would have to be compiled to a DLL using MinGW rather than MSVC. Is there any chance of getting some buy-in from Linden Lab? Switch the viewer to using liboil for CPU detection, improving it where necessary? What would be really nice is to generalize all the viewer's vector math functionality, and upstream it into liboil. There's also a bunch of image scaling and compositing functionality that the viewer could possibly use. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070716/2883d099/attachment-0001.pgp From bos at lindenlab.com Mon Jul 16 14:15:33 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jul 16 14:15:35 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <1184620013.26499.21.camel@localhost.localdomain> References: <1184620013.26499.21.camel@localhost.localdomain> Message-ID: <469BDFF5.4070400@lindenlab.com> Callum Lerwick wrote: > I am considering using it for OpenJPEG, for runtime CPU detection, and > it also has functions for converting an array between ints and float > which would be useful. Looks potentially useful. > One issue is that it is currently gcc-centric, this would mean for best > results on Windows, it would have to be compiled to a DLL using MinGW > rather than MSVC. So long as MSVC doesn't choke on header files, this shouldn't be a problem. > Is there any chance of getting some buy-in from Linden Lab? Switch the > viewer to using liboil for CPU detection, improving it where necessary? I'll have an ask around. References: <1184620013.26499.21.camel@localhost.localdomain> <469BDFF5.4070400@lindenlab.com> Message-ID: <469BE24F.4040906@dzonux.net> Bryan O'Sullivan wrote: >> results on Windows, it would have to be compiled to a DLL using MinGW >> rather than MSVC. > One issue is that it is currently gcc-centric, this would mean for best > > So long as MSVC doesn't choke on header files, this shouldn't be a > problem. Unless there has been a change in the last month, MingGW doesn't yet officially support anything other than MSVCRT6.0, which the build excludes. It is possible to use newer MSVCRT libraries with MingGW. See Also: https://jira.secondlife.com/browse/VWR-1748 -- Power to Change the Void From gigstaggart at gmail.com Mon Jul 16 14:51:26 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 16 14:51:32 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BB4F7.3020705@dzonux.net> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> Message-ID: <469BE85E.8010705@gmail.com> I'm assuming the idea of this is to get some extra QA on code that is going to wind up in the main viewer. I think the only way this can be useful is if it *only* includes Jira patches. If the code isn't ready for Jira it probably isn't ready for this stage either. If you have to modify a patch to get it to apply clean, that modified patch should be posted back to Jira. If non-Jira or code submitted by people who haven't signed the contributor agreement is included, the value is greatly reduced because any bugs or instability might be written off as a problem with the "unofficial" code patches that were applied. If I've completely misunderstood the point of this, I apologize. -Jason From gigstaggart at gmail.com Mon Jul 16 14:57:52 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 16 14:57:53 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <1184620013.26499.21.camel@localhost.localdomain> References: <1184620013.26499.21.camel@localhost.localdomain> Message-ID: <469BE9E0.9040303@gmail.com> Callum Lerwick wrote: > One issue is that it is currently gcc-centric, this would mean for best > results on Windows, it would have to be compiled to a DLL using MinGW > rather than MSVC. I believe liboil is worth making some concessions for. I came to the same conclusions when I was looking at OpenJPEG, that liboil might be very useful to have. It may even be worth doing upstream patches to liboil to make it more MS friendly, if they would be willing to accept them. -Jason From dzonatas at dzonux.net Mon Jul 16 15:03:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 16 15:03:50 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BE85E.8010705@gmail.com> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> Message-ID: <469BEB47.9080303@dzonux.net> You are correct. The QA bit is the higher priority of the effort. I'm still wonder what to do with those that have signed agreements that want to submit source for review or for a test before a jira issue seems practical. In the end, yes, the jira serialization is very helpful and does help make efforts become more official. Jason Giglio wrote: > I'm assuming the idea of this is to get some extra QA on code that is > going to wind up in the main viewer. > > I think the only way this can be useful is if it *only* includes Jira > patches. If the code isn't ready for Jira it probably isn't ready for > this stage either. > > If you have to modify a patch to get it to apply clean, that modified > patch should be posted back to Jira. > > If non-Jira or code submitted by people who haven't signed the > contributor agreement is included, the value is greatly reduced > because any bugs or instability might be written off as a problem with > the "unofficial" code patches that were applied. > > If I've completely misunderstood the point of this, I apologize. > > -Jason > > -- Power to Change the Void From kamilion at gmail.com Mon Jul 16 16:25:30 2007 From: kamilion at gmail.com (Kamilion) Date: Mon Jul 16 16:25:32 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BEB47.9080303@dzonux.net> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> <469BEB47.9080303@dzonux.net> Message-ID: On 7/16/07, Dzonatas wrote: > You are correct. The QA bit is the higher priority of the effort. > > I'm still wonder what to do with those that have signed agreements that > want to submit source for review or for a test before a jira issue seems > practical. Perhaps we should separate builds into 'stable' and 'testing/unstable', it seems to work for many other projects. JIRA patches would end up in 'stable', and non-jira'd review/test patches can make it into testing/unstable. When the patch ends up on JIRA, it could be moved over to stable. Testing would likely be a subset of stable, making it a good place to test patches on top of the latest community patchset. > In the end, yes, the jira serialization is very helpful and does help > make efforts become more official. From blakar at gmail.com Mon Jul 16 16:37:54 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jul 16 16:37:58 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469BD486.7030003@blueflash.cc> References: <469BD486.7030003@blueflash.cc> Message-ID: <7992d0d60707161637i4243856m782133e1cdfacfdd@mail.gmail.com> What about "SL Bleeding Edge Viewer"? It implies that you're running a viewer that has code which is advanced compared to the official version. It should also make users aware that it'll not always be bug free. I mostly like it because most of the other names sound "boring" ;) Dirk aka Blakar Ogre On 7/16/07, Nicholaz Beresford wrote: > > Dzonatas Edition > JIRA-Patch Testbed > JIRA-Patch Viewer > Patch-Test Edition > Patch Frontrunner > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Matthew Dowd wrote: > > Well, I'd propose to call it what it is so possibilities are > > > > Open Source Test Viewer > > Open Source Development Viewer > > Open Source Sandbox Viewer > > Open Source Contributions Sandbox Viewer > > > > Matthew > > > > > > > > > > > > > > ---------------------------------------- > >> Date: Mon, 16 Jul 2007 12:13:29 -0700 > >> From: dzonatas@dzonux.net > >> To: jhurliman@wsu.edu > >> Subject: Re: [sldev] About the Open Source Viewer > >> CC: sldev@lists.secondlife.com > >> > >> It was never meant to be so aggressively profound like that. > >> > >> I had other ideas for a name, but I settled on something just bland and > >> more so generic. > >> > >> See my sentiments here: > >> https://lists.secondlife.com/pipermail/sldev/2007-July/003329.html > >> > >> Obviously, I'm open for a new name for it. > >> > >> John Hurliman wrote: > >>> In hindsight OpenSL was a bad enough name for a fork of the viewer, > >>> but "Open Source Viewer" is just ridiculous. That's like calling > >>> Ubuntu "Open Source Linux". Not only does the name mis-convey what the > >>> project does (without context it sounds like a free image viewing > >>> app), but as previously mentioned every SL viewer is open source. At > >>> worst this could be conveyed as an attempt to discredit existing SL > >>> viewers. > >>> > >>> > >>> Dzonatas wrote: > >>>> Interesting view. > >>>> > >>>> I put it on the Agenda: > >>>> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > >>>> > >>>> > >>>> Kiwi Alfa wrote: > >>>>> Hi, > >>>>> > >>>>> I'm a long-time lurker on this list, and I think this may be my first > >>>>> post, but I just wanted to mention that this could cause confusion > >>>>> since the viewer is already open source - the name makes it sound as > >>>>> if Linden Labs' own viewer *isn't* open source, which isn't true. > >>>>> > >>>>> Just my two cents. :) (I'll probably introduce myself properly at > >>>>> some stage.) > >>>>> > >>>>> - Kiwi. > >>>>> > >>>>> On 7/16/07, Dzonatas wrote: > >>>>>> I wrote up a wiki page about the Open Source Viewer. > >>>>>> > >>>>>> http://wiki.secondlife.com/wiki/Open_Source_Viewer > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Power to Change the Void > >>>>>> _______________________________________________ > >>>>>> Click here to unsubscribe or manage your list subscription: > >>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >>>>>> > >>>>>> > >>>>> > >>> _______________________________________________ > >>> Click here to unsubscribe or manage your list subscription: > >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >>> > >>> > >> -- > >> Power to Change the Void > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _________________________________________________________________ > > Celeb spotting ? Play CelebMashup and win cool prizes > > https://www.celebmashup.com/index2.html_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Mon Jul 16 16:38:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 16 16:39:13 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> <469BEB47.9080303@dzonux.net> Message-ID: <469C018D.10000@blueflash.cc> My suggestion would be to make the JIRA the hub for patches. They could be posted with comments to not immediately import them. Or if the Lindens are not sure about them they could say that they'd like to see some pre-testing. In any case, a patch running in a homebrew for some time could be some sort of seal of approval for less than trivial patches. Maybe a JIRA state for issues like "in beta testing", could offer more clarity to the process. Just an idea though. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Kamilion wrote: > On 7/16/07, Dzonatas wrote: >> You are correct. The QA bit is the higher priority of the effort. >> >> I'm still wonder what to do with those that have signed agreements that >> want to submit source for review or for a test before a jira issue seems >> practical. > > Perhaps we should separate builds into 'stable' and > 'testing/unstable', it seems to work for many other projects. > > JIRA patches would end up in 'stable', and non-jira'd review/test > patches can make it into testing/unstable. > > When the patch ends up on JIRA, it could be moved over to stable. > > Testing would likely be a subset of stable, making it a good place to > test patches on top of the latest community patchset. > >> In the end, yes, the jira serialization is very helpful and does help >> make efforts become more official. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Mon Jul 16 16:39:57 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 16 16:40:26 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <7992d0d60707161637i4243856m782133e1cdfacfdd@mail.gmail.com> References: <469BD486.7030003@blueflash.cc> <7992d0d60707161637i4243856m782133e1cdfacfdd@mail.gmail.com> Message-ID: <469C01CD.3020908@blueflash.cc> I like both ... the Sandbox Edition and Bleeding Edge. Bleeding Edge is more catchy though ... it has something cool! Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dirk Moerenhout wrote: > What about "SL Bleeding Edge Viewer"? > > It implies that you're running a viewer that has code which is > advanced compared to the official version. It should also make users > aware that it'll not always be bug free. > > I mostly like it because most of the other names sound "boring" ;) > > Dirk aka Blakar Ogre > > > On 7/16/07, Nicholaz Beresford wrote: >> >> Dzonatas Edition >> JIRA-Patch Testbed >> JIRA-Patch Viewer >> Patch-Test Edition >> Patch Frontrunner >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Matthew Dowd wrote: >> > Well, I'd propose to call it what it is so possibilities are >> > >> > Open Source Test Viewer >> > Open Source Development Viewer >> > Open Source Sandbox Viewer >> > Open Source Contributions Sandbox Viewer >> > >> > Matthew >> > >> > >> > >> > >> > >> > >> > ---------------------------------------- >> >> Date: Mon, 16 Jul 2007 12:13:29 -0700 >> >> From: dzonatas@dzonux.net >> >> To: jhurliman@wsu.edu >> >> Subject: Re: [sldev] About the Open Source Viewer >> >> CC: sldev@lists.secondlife.com >> >> >> >> It was never meant to be so aggressively profound like that. >> >> >> >> I had other ideas for a name, but I settled on something just bland >> and >> >> more so generic. >> >> >> >> See my sentiments here: >> >> https://lists.secondlife.com/pipermail/sldev/2007-July/003329.html >> >> >> >> Obviously, I'm open for a new name for it. >> >> >> >> John Hurliman wrote: >> >>> In hindsight OpenSL was a bad enough name for a fork of the viewer, >> >>> but "Open Source Viewer" is just ridiculous. That's like calling >> >>> Ubuntu "Open Source Linux". Not only does the name mis-convey what >> the >> >>> project does (without context it sounds like a free image viewing >> >>> app), but as previously mentioned every SL viewer is open source. At >> >>> worst this could be conveyed as an attempt to discredit existing SL >> >>> viewers. >> >>> >> >>> >> >>> Dzonatas wrote: >> >>>> Interesting view. >> >>>> >> >>>> I put it on the Agenda: >> >>>> https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >> >>>> >> >>>> >> >>>> Kiwi Alfa wrote: >> >>>>> Hi, >> >>>>> >> >>>>> I'm a long-time lurker on this list, and I think this may be my >> first >> >>>>> post, but I just wanted to mention that this could cause confusion >> >>>>> since the viewer is already open source - the name makes it >> sound as >> >>>>> if Linden Labs' own viewer *isn't* open source, which isn't true. >> >>>>> >> >>>>> Just my two cents. :) (I'll probably introduce myself properly at >> >>>>> some stage.) >> >>>>> >> >>>>> - Kiwi. >> >>>>> >> >>>>> On 7/16/07, Dzonatas wrote: >> >>>>>> I wrote up a wiki page about the Open Source Viewer. >> >>>>>> >> >>>>>> http://wiki.secondlife.com/wiki/Open_Source_Viewer >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Power to Change the Void >> >>>>>> _______________________________________________ >> >>>>>> Click here to unsubscribe or manage your list subscription: >> >>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >>>>>> >> >>>>>> >> >>>>> >> >>> _______________________________________________ >> >>> Click here to unsubscribe or manage your list subscription: >> >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >>> >> >>> >> >> -- >> >> Power to Change the Void >> >> _______________________________________________ >> >> Click here to unsubscribe or manage your list subscription: >> >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > >> > _________________________________________________________________ >> > Celeb spotting ? Play CelebMashup and win cool prizes >> > >> https://www.celebmashup.com/index2.html_______________________________________________ >> >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> From kamilion at gmail.com Mon Jul 16 16:44:45 2007 From: kamilion at gmail.com (Kamilion) Date: Mon Jul 16 16:44:47 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469C018D.10000@blueflash.cc> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> <469BEB47.9080303@dzonux.net> <469C018D.10000@blueflash.cc> Message-ID: Well, a good example for the Testing/Unstable branch would be Able's object muting patches. As far as I can tell, there's no patchset on JIRA for it, as Able's still in active development. Probably wouldn't be terribly hard to toss his patchset in Testing on top of Stable's patchsets and make sure they operate well with the JIRA set (which will likely be applied by LL 'soon'). And FWIW, I like "Sandbox Edition" as well -- most residents know what a sandbox is in SL terms ;) From dzonatas at dzonux.net Mon Jul 16 16:47:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 16 16:47:38 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> <469BEB47.9080303@dzonux.net> <469C018D.10000@blueflash.cc> Message-ID: <469C0399.7000507@dzonux.net> Kamilion wrote: > And FWIW, I like "Sandbox Edition" as well -- most residents know what > a sandbox is in SL terms ;) > Where you get shot at and caged often by random griefers? -- Power to Change the Void From Paul.Hampson at Pobox.com Mon Jul 16 17:47:04 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Mon Jul 16 17:47:13 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <469BB19F.1000509@lindenlab.com> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> Message-ID: <20070717004704.GA20171@keitarou> On Mon, Jul 16, 2007 at 10:57:51AM -0700, Bryan O'Sullivan wrote: > Paul TBBle Hampson wrote: > >I'm hoping it wasn't unsharing the shared objects, because I'm pretty > >sure building those as shared objects cut my build time by about an hour > >(from three to two), unless someone else can suggest a different 1.17 to > >1.18 change that would cause that? > I can't suggest what might have changed this, but I'm skeptical that > it could have had anything to do with a change of library type. Well, I'll keep an eye on it. It's possible I forgot to time the gcc-4 build of 1.17, in which case switching to gcc-4 is the only other likely culprit. I _believe_ that I did check the gcc-4 build time for 1.17 and it was still three hours. Anyway, the first-to-mind reason the shared-library build would reduce build time is because it no longer has to try and hold so much in RAM at once when linking things. My 512MB laptop goes to swap fairly early on in the build process (which I blame for most of the three-hour build-time, a doubly-fast machine with much more RAM does it in like 20 minutes) > >which I'm guessing is the result of inlining, so unless there's some kind > >of performance penalty for using shared libraries, I'm all for this > >state of affairs continuing and even encompassing more. I believe there > >was a Jira issue around for .soing more of the client... > I'm afraid that doesn't make any sense. Using shared objects > increases viewer startup time and makes packaging more of a pain. I'm aware (theoretically aware, I've never noticed it myself) it increases viewer startup time, but I'm not sure why people keep saying this makes packaging the viewer more of a pain... Still, making shared libraries load faster is in my experience the job of prelink, rather than compiling applications statically. Of course, in this case we don't really get any benefits of building shared libraries at runtime, since they're not being shared with anything. In my case, I'm already loading all those system libraries as shared libraries, rather than using the linden-provided .a files, so I don't think the performance penalty of loading ll*.so will turn out to be significant. I might have a play with compiling more of the objects shared, to see if that reduces my build turnaround time any further. Faster build => sooner package releases. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070717/f34845d8/attachment.pgp From iridium at lindenlab.com Mon Jul 16 18:44:24 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Mon Jul 16 18:44:38 2007 Subject: [sldev] UI Triage Agenda up for review Message-ID: <469C1EF8.4020608@lindenlab.com> Dear SL Devs, I would just like to give you a heads up that the UI Triage Agenda for tomorrow (July 17, 2007) is up on the wiki (http://wiki.secondlife.com/wiki/Bug_triage/UI_Agenda#Other_Bug_Reports). Benjamin, Torley, and I will conduct the triage at 10am SLTime tomorrow. The slurl to Benjamin's office is listed on the wiki. Feel free to edit the Agenda as you see fit. For this particular triage, I organized by number of votes. You may certainly add issues that you think are important, issues I have failed to address this week. It is our hope that you will seize control of the UI Triage Agenda in the spirit of Resident empowerment. That way, you dictate what goes on the agenda, not Linden Lab. For instructions on setting the agenda, please see http://wiki.secondlife.com/wiki/Bug_triage. Still have questions? Ping me. Best, Iridium Linden From jhurliman at wsu.edu Mon Jul 16 19:00:05 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jul 16 19:01:29 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <20070717004704.GA20171@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> Message-ID: <469C22A5.3090707@wsu.edu> Paul TBBle Hampson wrote: > I might have a play with compiling more of the objects shared, to see > if that reduces my build turnaround time any further. > > Faster build => sooner package releases. ^_^ > > How difficult is it to switch between shared and static libraries for the client? If a patch could be made to modularize more things in to shared libraries for a debug build, it could be applied to a third party repository like OSLCC (or has a name been decided for the viewer yet?). Anything to make relinking times faster for client devs or people just working on patches. John Hurliman From seg at haxxed.com Mon Jul 16 19:33:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jul 16 19:35:24 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <20070717004704.GA20171@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> Message-ID: <1184639588.31185.5.camel@localhost.localdomain> On Tue, 2007-07-17 at 10:47 +1000, Paul TBBle Hampson wrote: > > I'm afraid that doesn't make any sense. Using shared objects > > increases viewer startup time and makes packaging more of a pain. > > I'm aware (theoretically aware, I've never noticed it myself) it > increases viewer startup time, but I'm not sure why people keep saying > this makes packaging the viewer more of a pain... Because it requires you to start up the client with a wrapper script, something I'd like to avoid. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070716/a9c21417/attachment.pgp From chance at kalacia.com Mon Jul 16 20:24:03 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jul 16 20:24:05 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469C0399.7000507@dzonux.net> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> <469BEB47.9080303@dzonux.net> <469C018D.10000@blueflash.cc> <469C0399.7000507@dzonux.net> Message-ID: <2925011a0707162024h3bad8d82ldcd1164e9eae77f5@mail.gmail.com> right: he registered the project at sourceforge, and maintains the checkins there so if you know what your downloading, call it whatever he wants to... On 7/16/07, Dzonatas wrote: > Kamilion wrote: > > And FWIW, I like "Sandbox Edition" as well -- most residents know what > > a sandbox is in SL terms ;) > > > > Where you get shot at and caged often by random griefers? > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Mon Jul 16 20:34:25 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 16 20:34:25 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <2925011a0707162024h3bad8d82ldcd1164e9eae77f5@mail.gmail.com> References: <469B8C53.9040605@dzonux.net> <469BB4F7.3020705@dzonux.net> <469BE85E.8010705@gmail.com> <469BEB47.9080303@dzonux.net> <469C018D.10000@blueflash.cc> <469C0399.7000507@dzonux.net> <2925011a0707162024h3bad8d82ldcd1164e9eae77f5@mail.gmail.com> Message-ID: <469C38C1.9030508@dzonux.net> Uh... I did advertise a request for those who want accounts on OSLCC. Anyways.... In code sense... "Sandbox" would be positive. That we know. In Second Life, it may be looked upon differently. If you spent time in the sandbox sim, you know this. Chance Unknown wrote: > right: he registered the project at sourceforge, and maintains the > checkins there so if you know what your downloading, call it whatever > he wants to... > > On 7/16/07, Dzonatas wrote: >> Kamilion wrote: >> > And FWIW, I like "Sandbox Edition" as well -- most residents know what >> > a sandbox is in SL terms ;) >> > >> >> Where you get shot at and caged often by random griefers? >> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > -- Power to Change the Void From gwardell at gwsystems.co.il Mon Jul 16 21:03:12 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Mon Jul 16 21:03:22 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <469C38C1.9030508@dzonux.net> Message-ID: <01a401c7c827$65504e70$a4689943@gwsystems2.com> Never been to the sandbox sim so I don't know that one. But there are sandboxes elsewhere that aren't bad, so I like that name as well. > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Dzonatas > Sent: Mon, July 16, 2007 11:34 PM > To: Chance Unknown; Kamilion > Cc: sldev@lists.secondlife.com > Subject: Re: [sldev] About the Open Source Viewer > > > Uh... I did advertise a request for those who want accounts on OSLCC. > > Anyways.... > > In code sense... "Sandbox" would be positive. That we know. > > In Second Life, it may be looked upon differently. If you > spent time in > the sandbox sim, you know this. > > Chance Unknown wrote: > > right: he registered the project at sourceforge, and maintains the > > checkins there so if you know what your downloading, call > it whatever > > he wants to... > > > > On 7/16/07, Dzonatas wrote: > >> Kamilion wrote: > >> > And FWIW, I like "Sandbox Edition" as well -- most > residents know what > >> > a sandbox is in SL terms ;) > >> > > >> > >> Where you get shot at and caged often by random griefers? > >> > >> -- > >> Power to Change the Void > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > > > > > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From webmaster at ligosworld.com Tue Jul 17 03:16:33 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Tue Jul 17 03:17:05 2007 Subject: [sldev] Viewer Problems Message-ID: <469C9701.7040404@ligosworld.com> I have a big problem compiling the current version of the viewer: c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all the argument types c:\sldev\linden\indra\newview\llsrv.h(45): could be 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' Can anybody send help please??? Andi From Paul.Hampson at Pobox.com Tue Jul 17 03:22:54 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Tue Jul 17 03:23:08 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <469C22A5.3090707@wsu.edu> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <469C22A5.3090707@wsu.edu> Message-ID: <20070717102254.GA23391@keitarou> On Mon, Jul 16, 2007 at 07:00:05PM -0700, John Hurliman wrote: > Paul TBBle Hampson wrote: > >I might have a play with compiling more of the objects shared, to see > >if that reduces my build turnaround time any further. > >Faster build => sooner package releases. ^_^ > How difficult is it to switch between shared and static libraries for the client? If a patch could be made to modularize more things in to shared libraries for a debug build, it could be applied to a third > party repository like OSLCC (or has a name been decided for the viewer yet?). Anything to make relinking times faster for client devs or people just working on patches. Easy change in SConstruct. See the lines create_cond_module('llcommon') create_cond_module('llmath') create_cond_module('llvfs') create_cond_module('llimagej2coj', module_libs=['openjpeg']) create_cond_module('llimage', module_libs=['llimagej2coj', 'jpeg', 'png12']) create_static_module('llmessage') create_static_module('llinventory') create_static_module('llcharacter') create_static_module('llprimitive') create_static_module('llrender') create_static_module('llwindow') create_static_module('llxml') changing one from create_static_module to create_cond_module should do it. (There's some other create_static_module calls around too) I haven't tried this yet, mind you. create_cond_module doesn't (yet) support the extra_depends parameter used by the lscript module. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070717/ec1a1f67/attachment.pgp From Paul.Hampson at Pobox.com Tue Jul 17 03:27:05 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Tue Jul 17 03:27:07 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <1184639588.31185.5.camel@localhost.localdomain> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <1184639588.31185.5.camel@localhost.localdomain> Message-ID: <20070717102705.GB23391@keitarou> On Mon, Jul 16, 2007 at 09:33:08PM -0500, Callum Lerwick wrote: > On Tue, 2007-07-17 at 10:47 +1000, Paul TBBle Hampson wrote: > >> I'm afraid that doesn't make any sense. Using shared objects > >> increases viewer startup time and makes packaging more of a pain. >> I'm aware (theoretically aware, I've never noticed it myself) it >> increases viewer startup time, but I'm not sure why people keep saying >> this makes packaging the viewer more of a pain... > Because it requires you to start up the client with a wrapper script, > something I'd like to avoid. I don't see that it does. We had this conversation already, in fact. Even Fedora provides a non-wrapper-script solution. True, it needs a wrapper script to run it directly out of the build-path without an installer around it, but I don't see that as a particularly interesting use-case myself. Maybe the opensource check in create_cond_module should be a standalone check? That way compile-run cyclers who don't want to set LD_LIBRARY_PATH can build statically to squeeze every last cycle out of the CPU, since that implies to me using the non-standalone version of the other libraries too... Either way, I've not seen anything here that convinces me that private shared libraries aren't a good idea for my Debian package builds, so I'll still go ahead and futz with that when I have a little more time. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070717/68fa8118/attachment.pgp From matthew.dowd at hotmail.co.uk Tue Jul 17 05:23:26 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jul 17 05:23:28 2007 Subject: [sldev] Viewer Problems Message-ID: Could you clarify which compiler/platform you are using? thanks Matthew ---------------------------------------- > Date: Tue, 17 Jul 2007 12:16:33 +0200 > From: webmaster@ligosworld.com > To: sldev@lists.secondlife.com > Subject: [sldev] Viewer Problems > > I have a big problem compiling the current version of the viewer: > > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all > the argument types > c:\sldev\linden\indra\newview\llsrv.h(45): could be > 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > > Can anybody send help please??? > > Andi > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From webmaster at ligosworld.com Tue Jul 17 05:28:11 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Tue Jul 17 05:28:21 2007 Subject: [sldev] Viewer Problems In-Reply-To: References: Message-ID: <469CB5DB.6000408@ligosworld.com> Compiling with MSVC2005 on a WinXP pro SP2, need more information? thanks for help, Andi Matthew Dowd schrieb: > Could you clarify which compiler/platform you are using? > > thanks > > Matthew > > > > > ---------------------------------------- > >> Date: Tue, 17 Jul 2007 12:16:33 +0200 >> From: webmaster@ligosworld.com >> To: sldev@lists.secondlife.com >> Subject: [sldev] Viewer Problems >> >> I have a big problem compiling the current version of the viewer: >> >> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all >> the argument types >> c:\sldev\linden\indra\newview\llsrv.h(45): could be >> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >> while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' >> >> Can anybody send help please??? >> >> Andi >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _________________________________________________________________ > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > http://www.live.com/?mkt=en-gb > > From Dana.Fagerstrom at Sun.COM Tue Jul 17 06:20:44 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Tue Jul 17 06:19:25 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <20070717004704.GA20171@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> Message-ID: <469CC22C.3090007@sun.com> Paul, One thing many people don't realize is that scons supports the -j option just like make/dmake. That option instructs scons to perform multiple compiles. On a "fast" system a "-j 2" or even "-j 4" will greatly decrease build time. On my Ultra 40 (2 AMD dual core CPUs) I run with "-j 8" and a complete build plus packaging is completed in less than an hour. HTH, D (aka Whoops Babii) http://blogs.sun.com/daner/ Paul TBBle Hampson wrote: > On Mon, Jul 16, 2007 at 10:57:51AM -0700, Bryan O'Sullivan wrote: >> Paul TBBle Hampson wrote: > >>> I'm hoping it wasn't unsharing the shared objects, because I'm pretty >>> sure building those as shared objects cut my build time by about an hour >>> (from three to two), unless someone else can suggest a different 1.17 to >>> 1.18 change that would cause that? > >> I can't suggest what might have changed this, but I'm skeptical that >> it could have had anything to do with a change of library type. > > Well, I'll keep an eye on it. It's possible I forgot to time the gcc-4 > build of 1.17, in which case switching to gcc-4 is the only other likely > culprit. I _believe_ that I did check the gcc-4 build time for 1.17 and > it was still three hours. > > Anyway, the first-to-mind reason the shared-library build would reduce > build time is because it no longer has to try and hold so much in RAM at > once when linking things. My 512MB laptop goes to swap fairly early on > in the build process (which I blame for most of the three-hour > build-time, a doubly-fast machine with much more RAM does it in like 20 > minutes) > >>> which I'm guessing is the result of inlining, so unless there's some kind >>> of performance penalty for using shared libraries, I'm all for this >>> state of affairs continuing and even encompassing more. I believe there >>> was a Jira issue around for .soing more of the client... > >> I'm afraid that doesn't make any sense. Using shared objects >> increases viewer startup time and makes packaging more of a pain. > > I'm aware (theoretically aware, I've never noticed it myself) it > increases viewer startup time, but I'm not sure why people keep saying > this makes packaging the viewer more of a pain... > > Still, making shared libraries load faster is in my experience the job > of prelink, rather than compiling applications statically. Of course, > in this case we don't really get any benefits of building shared > libraries at runtime, since they're not being shared with anything. > > In my case, I'm already loading all those system libraries as shared > libraries, rather than using the linden-provided .a files, so I don't > think the performance penalty of loading ll*.so will turn out to be > significant. > > I might have a play with compiling more of the objects shared, to see > if that reduces my build turnaround time any further. > > Faster build => sooner package releases. ^_^ > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gigstaggart at gmail.com Tue Jul 17 06:47:42 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 17 06:47:47 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <469CC22C.3090007@sun.com> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <469CC22C.3090007@sun.com> Message-ID: <469CC87E.10609@gmail.com> Dana Fagerstrom wrote: > Paul, > > One thing many people don't realize is that scons supports the -j option > just like make/dmake. That option instructs scons to perform multiple > compiles. On a "fast" system a "-j 2" or even "-j 4" will greatly > decrease build time. > > On my Ultra 40 (2 AMD dual core CPUs) I run with "-j 8" and a complete > build plus packaging is completed in less than an hour. I've found that on my Quad Core single chip, it's best to just stay with the actual number of cores you have, i.e. -j 4 is fastest. This could be because of disk bottlenecks. In any case with -j 4 on Scons I can build the client from scratch in 11 minutes, with -j 5 it takes more like 20 minutes. So if you have more than one core, don't forget to try the actual number of cores you have at least once, it might be faster. -Jason From matthew.dowd at hotmail.co.uk Tue Jul 17 08:58:00 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jul 17 08:58:02 2007 Subject: [sldev] Viewer Problems Message-ID: Sorry, to have to keep asking questions. Could you confirm you followed the steps on this page: http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) As the project files in the LL download do not work out of the box with MSVC2005. Matthew ---------------------------------------- > Date: Tue, 17 Jul 2007 14:28:11 +0200 > From: webmaster@ligosworld.com > To: matthew.dowd@hotmail.co.uk; sldev@lists.secondlife.com > Subject: Re: [sldev] Viewer Problems > > Compiling with MSVC2005 on a WinXP pro SP2, > need more information? > > thanks for help, > Andi > > Matthew Dowd schrieb: > > Could you clarify which compiler/platform you are using? > > > > thanks > > > > Matthew > > > > > > > > > > ---------------------------------------- > > > >> Date: Tue, 17 Jul 2007 12:16:33 +0200 > >> From: webmaster@ligosworld.com > >> To: sldev@lists.secondlife.com > >> Subject: [sldev] Viewer Problems > >> > >> I have a big problem compiling the current version of the viewer: > >> > >> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > >> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all > >> the argument types > >> c:\sldev\linden\indra\newview\llsrv.h(45): could be > >> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > >> while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > >> > >> Can anybody send help please??? > >> > >> Andi > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > > > > _________________________________________________________________ > > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > > http://www.live.com/?mkt=en-gb > > > > > _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From dale at daleglass.net Tue Jul 17 10:22:16 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 17 10:22:34 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <469CC87E.10609@gmail.com> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <469CC22C.3090007@sun.com> <469CC87E.10609@gmail.com> Message-ID: <20070717172216.GA26195@bruno.sbruno> On Tue, Jul 17, 2007 at 09:47:42AM -0400, Jason Giglio wrote: > I've found that on my Quad Core single chip, it's best to just stay with > the actual number of cores you have, i.e. -j 4 is fastest. > > This could be because of disk bottlenecks. My own experiments indicate that build speed depends very heavily on the amount of RAM available. Enough RAM will make disk speed completely irrelevant. If you have too little though, the build process will result in evicting useful data from the cache, and making the disk a lot more relevant. I've seen g++ use somewhere about 300-500MB per process while building. I'd estimate the amount of RAM needed to compile SL optimally to be somewhere about: (400MB * num_processes) + 400MB + amount_used_by_applications The +400MB is the approximate amount of intermediate results the build generates. In the ideal case, all that remains cached in RAM by the time the build is done. So a 8 process build would require a 64 bit box (32 bit has a practical RAM limit of around 3GB) with somewhere about 5GB, assuming 1GB for the IDE and such. Add another GB or so if you're going to run SL at the same time (although that'll take one core of course) Here I do a full build of SL in approximately 15 minutes, on an Athlon 64 X2 5200+ with 4GB RAM, running in 64 bit mode, using -j2. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070717/904c4f79/attachment-0001.pgp From tofu.linden at lindenlab.com Tue Jul 17 11:25:07 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Jul 17 11:25:12 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <1184620013.26499.21.camel@localhost.localdomain> References: <1184620013.26499.21.camel@localhost.localdomain> Message-ID: <469D0983.8040901@lindenlab.com> I've used liboil in the past - it's pretty cool. I seem to recall that it was fairly painful to package, though, if not anticipating relying upon a system-installed one. It's also quite large (another packaging concern). The license would seem to allow one to re-use some isolated routines if we don't want to absorb the whole library - again I've done this in the past for personal projects and it wasn't technically difficult. Perhaps the CPU detection could be isolated into its own library (heck, perhaps the liboil authors would be happy to see this isolation as a contrib). -Tofu From webmaster at ligosworld.com Tue Jul 17 12:59:24 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Tue Jul 17 12:59:28 2007 Subject: [sldev] Viewer Problems In-Reply-To: References: Message-ID: <469D1F9C.6020503@ligosworld.com> I?m happy for hearing questions becouse i have no own idea left. But I followed those steps already. I compiled the version 1.17.0.12 the same way. Problems now with the newest version. The file, the error comes from is a new file ( llsrv.cpp and the header llsrv.h ), which was not part of the project in the 1.17... versions. Andreas Matthew Dowd schrieb: > Sorry, to have to keep asking questions. > > Could you confirm you followed the steps on this page: > > http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) > > As the project files in the LL download do not work out of the box with MSVC2005. > > Matthew > > > > > ---------------------------------------- > >> Date: Tue, 17 Jul 2007 14:28:11 +0200 >> From: webmaster@ligosworld.com >> To: matthew.dowd@hotmail.co.uk; sldev@lists.secondlife.com >> Subject: Re: [sldev] Viewer Problems >> >> Compiling with MSVC2005 on a WinXP pro SP2, >> need more information? >> >> thanks for help, >> Andi >> >> Matthew Dowd schrieb: >> >>> Could you clarify which compiler/platform you are using? >>> >>> thanks >>> >>> Matthew >>> >>> >>> >>> >>> ---------------------------------------- >>> >>> >>>> Date: Tue, 17 Jul 2007 12:16:33 +0200 >>>> From: webmaster@ligosworld.com >>>> To: sldev@lists.secondlife.com >>>> Subject: [sldev] Viewer Problems >>>> >>>> I have a big problem compiling the current version of the viewer: >>>> >>>> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >>>> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all >>>> the argument types >>>> c:\sldev\linden\indra\newview\llsrv.h(45): could be >>>> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >>>> while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' >>>> >>>> Can anybody send help please??? >>>> >>>> Andi >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> >>> _________________________________________________________________ >>> Try Live.com - your fast, personalised homepage with all the things you care about in one place. >>> http://www.live.com/?mkt=en-gb >>> >>> >>> > > _________________________________________________________________ > 100?s of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html > > From dzonatas at dzonux.net Tue Jul 17 13:40:04 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 17 13:40:03 2007 Subject: [sldev] 1.18.0.6.OS.3 released: includes SSE2 support and DSO run-time linking Message-ID: <469D2924.2080001@dzonux.net> Here is where to get it: http://sourceforge.net/project/showfiles.php?group_id=191214 This one is to mainly re-work SSE/vector optimization features and show that it can be done. Very simple, the newer CPU detection code figures if it can support SSE2. It tries to find the llviewersse2.dll (or likewise for local platform) if it support SSE2. It loads the SSE2 library and switches function pointers. This avoids the Visual Studio bug with globals and SSE2 compile options when the viewer is packaged as one complete exe file. The SSE2 code is only found in the llviewersse2.dll. This allows the extra benefit that further SSE2 optimizations can be made on classes defined in llviewersse2.dll as reflected in the normal viewer. This is a intermediate build to show proof-of-concept, so I didn't fully document and upload sources to jira at this time. New patches can be found in the "applied" folder of the zip file. Enjoy! -- Power to Change the Void From soft at lindenlab.com Tue Jul 17 15:00:33 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 17 15:00:36 2007 Subject: [sldev] Collection of JIRAs suitable for open source In-Reply-To: <46926526.60103@lindenlab.com> References: <468E67C7.4040008@blueflash.cc> <46926526.60103@lindenlab.com> Message-ID: <9e6e5c9e0707171500v1f46f1a1udb376d65fed84b45@mail.gmail.com> On 7/9/07, Bryan O'Sullivan wrote: > Nicholaz Beresford wrote: > > > > I just created a JIRA to serve as a link list to issues that > > lend themselves to be solved by open sourcers. > > Great idea, thanks! What Bos said. :) Keeping this alive. From able.whitman at gmail.com Tue Jul 17 15:07:35 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 17 15:07:37 2007 Subject: [sldev] Etiquette for posting patches-in-progress? Message-ID: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> If I've got a patch for a JIRA issue that's not quite finished, but in a state that can be tested, would it be good practive for me to attach the patch to the JIRA issue, with a note that it's not the final version? I'm trying to find the most convenient way to share in-progress patches, and the nice thing about putting them in JIRA is that it's a central place for all the resources related to a particular bug. So for things like the Sandbox (i.e., the Yet-To-Be-Named) edition, all the current patches could be found in JIRA without having to have some submitted via email, some downloaded from other sites, etc. The downside is that currently there's no common way to flag a patch as "attached, but not ready for import". Maybe a "ready for import" flag could be added? Or maybe the right solution is to post the patch elsewhere (like on my own site, like I do currently), and only attach patches to JIRA when they're done. I'd like to do whatever is simplest and least confusing, but I'm not sure that one solution meets both criteria. :) --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070717/b4c76e5a/attachment.htm From dzonatas at dzonux.net Tue Jul 17 15:24:13 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 17 15:24:11 2007 Subject: [sldev] Collection of JIRAs suitable for open source In-Reply-To: <9e6e5c9e0707171500v1f46f1a1udb376d65fed84b45@mail.gmail.com> References: <468E67C7.4040008@blueflash.cc> <46926526.60103@lindenlab.com> <9e6e5c9e0707171500v1f46f1a1udb376d65fed84b45@mail.gmail.com> Message-ID: <469D418D.7050502@dzonux.net> Soft Linden wrote: > On 7/9/07, Bryan O'Sullivan wrote: >> Nicholaz Beresford wrote: >> > >> > I just created a JIRA to serve as a link list to issues that >> > lend themselves to be solved by open sourcers. >> >> Great idea, thanks! > > What Bos said. :) ... We just might need this jira feature: http://www.atlassian.com/software/jira/features/track.jsp -- Power to Change the Void From dzonatas at dzonux.net Tue Jul 17 15:33:10 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jul 17 15:33:19 2007 Subject: [sldev] Etiquette for posting patches-in-progress? In-Reply-To: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> References: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> Message-ID: <469D43A6.9080002@dzonux.net> What I did was to create a sub-task of in-progress work or work-to-be-done. When the patch is ready to that sub-task, create another sub-task to QA it to a build. Repeat if needed. Sorting patches is a real pain in the arse. I'll upload the current Sandbox-Something release to the OSLCC SVN and create a branch for your work. That'll quicken the merges easier and allow everybody to build the same way. =) I suggest to Use TortiseSVN/Merge. It's best feature is the UI, but its folder hooks are a pain. Eclipse also has very similar features to TortiseSVN/Merge. In Eclipse, I especially like the merge/diff and edit all -in-one view. My recommendation, Tortise for the major SVN jobs - Eclipse for everything else. Able Whitman wrote: > If I've got a patch for a JIRA issue that's not quite finished, but in > a state that can be tested, would it be good practive for me to attach > the patch to the JIRA issue, with a note that it's not the final version? > > I'm trying to find the most convenient way to share in-progress > patches, and the nice thing about putting them in JIRA is that it's a > central place for all the resources related to a particular bug. So > for things like the Sandbox ( i.e., the Yet-To-Be-Named) edition, all > the current patches could be found in JIRA without having to have some > submitted via email, some downloaded from other sites, etc. The > downside is that currently there's no common way to flag a patch as > "attached, but not ready for import". > > Maybe a "ready for import" flag could be added? Or maybe the right > solution is to post the patch elsewhere (like on my own site, like I > do currently), and only attach patches to JIRA when they're done. I'd > like to do whatever is simplest and least confusing, but I'm not sure > that one solution meets both criteria. :) > > --Able > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070717/62b71471/attachment.htm From gigstaggart at gmail.com Tue Jul 17 15:33:37 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 17 15:33:38 2007 Subject: [sldev] Etiquette for posting patches-in-progress? In-Reply-To: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> References: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> Message-ID: <469D43C1.7090909@gmail.com> Able Whitman wrote: > Maybe a "ready for import" flag could be added? Or maybe the right > solution is to post the patch elsewhere (like on my own site, like I do > currently), and only attach patches to JIRA when they're done. I'd like > to do whatever is simplest and least confusing, but I'm not sure that > one solution meets both criteria. :) That is a sticky one, because unimported patches will come up every week in triage. One barrier in the past has been that no one at Linden Lab can figure out how to make Jira permissions fine grained such that signed contributors could have access to special flags. This came up when it was suggested that regular users be prohibited from editing the Internal Jira number field. A ready for import field could be abused if people realize that that gets it on triage faster. -Jason From nicholaz at blueflash.cc Tue Jul 17 15:35:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 17 15:35:40 2007 Subject: [sldev] Etiquette for posting patches-in-progress? In-Reply-To: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> References: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> Message-ID: <469D442C.10501@blueflash.cc> Hmmm, maybe post it with something in the title ("sandbox patch"?) that makes clear that it's not yet ready. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Able Whitman wrote: > If I've got a patch for a JIRA issue that's not quite finished, but in a > state that can be tested, would it be good practive for me to attach the > patch to the JIRA issue, with a note that it's not the final version? > > I'm trying to find the most convenient way to share in-progress patches, > and the nice thing about putting them in JIRA is that it's a central > place for all the resources related to a particular bug. So for things > like the Sandbox ( i.e., the Yet-To-Be-Named) edition, all the current > patches could be found in JIRA without having to have some submitted via > email, some downloaded from other sites, etc. The downside is that > currently there's no common way to flag a patch as "attached, but not > ready for import". > > Maybe a "ready for import" flag could be added? Or maybe the right > solution is to post the patch elsewhere (like on my own site, like I do > currently), and only attach patches to JIRA when they're done. I'd like > to do whatever is simplest and least confusing, but I'm not sure that > one solution meets both criteria. :) > > --Able > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From alissa_sabre at yahoo.co.jp Tue Jul 17 15:41:54 2007 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Tue Jul 17 15:42:21 2007 Subject: [sldev] Input Method patch (Re: VWR-250) Message-ID: <1s87dsas0kdx46xYdokGG5rc.alissa_sabre@yahoo.co.jp> For those who *might* be interested, I uploaded a snapshot of my work on Input Method improvement as an attachment to JIRA issue VWR-250 (IME-20070716.patch). I also put links to several files: Windows binary, Mac binary, and screen shot. Please be reminded that, as noted on the comment to VWR-250, it is not ready for merge into viewer source tree. I want to hear from those people who are interested in improving Japanese/Chinese/Korean hanling about my patch. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From able.whitman at gmail.com Tue Jul 17 16:02:18 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 17 16:02:21 2007 Subject: [sldev] Etiquette for posting patches-in-progress? In-Reply-To: <469D442C.10501@blueflash.cc> References: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> <469D442C.10501@blueflash.cc> Message-ID: <7b3a84fb0707171602w3b3da858l358d4bda44376196@mail.gmail.com> If possible, I'd prefer not to create a bunch of placeholder JIRA entries just for the purpose of tracking the status of patches. There's enough duplication noise in JIRA already--and I have great admiration for those people who devote considerable time to helping clean it up! On 7/17/07, Nicholaz Beresford wrote: > > > Hmmm, maybe post it with something in the title > ("sandbox patch"?) that makes clear that it's not > yet ready. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Able Whitman wrote: > > If I've got a patch for a JIRA issue that's not quite finished, but in a > > state that can be tested, would it be good practive for me to attach the > > patch to the JIRA issue, with a note that it's not the final version? > > > > I'm trying to find the most convenient way to share in-progress patches, > > and the nice thing about putting them in JIRA is that it's a central > > place for all the resources related to a particular bug. So for things > > like the Sandbox ( i.e., the Yet-To-Be-Named) edition, all the current > > patches could be found in JIRA without having to have some submitted via > > email, some downloaded from other sites, etc. The downside is that > > currently there's no common way to flag a patch as "attached, but not > > ready for import". > > > > Maybe a "ready for import" flag could be added? Or maybe the right > > solution is to post the patch elsewhere (like on my own site, like I do > > currently), and only attach patches to JIRA when they're done. I'd like > > to do whatever is simplest and least confusing, but I'm not sure that > > one solution meets both criteria. :) > > > > --Able > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20070717/df1481ce/attachment.htm From able.whitman at gmail.com Tue Jul 17 16:06:59 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jul 17 16:07:01 2007 Subject: [sldev] Etiquette for posting patches-in-progress? In-Reply-To: <469D43A6.9080002@dzonux.net> References: <7b3a84fb0707171507x1ce544b0tb7e753adaaee0cd8@mail.gmail.com> <469D43A6.9080002@dzonux.net> Message-ID: <7b3a84fb0707171606t7d281d6gfa843b41c935b9b8@mail.gmail.com> On 7/17/07, Dzonatas wrote: > > What I did was to create a sub-task of in-progress work or > work-to-be-done. > When the patch is ready to that sub-task, create another sub-task to QA it > to a build. > Repeat if needed. > It's not a perfect solution, but sub-tasks make a lot of sense, I think. That's certainly a workable approach I will take. Sorting patches is a real pain in the arse. > > I'll upload the current Sandbox-Something release to the OSLCC SVN and > create a branch for your work. That'll quicken the merges easier and allow > everybody to build the same way. =) > I can certainly merge my own changes into that new branch, but I will probably only do so when I've got a new "stabilized" set of changes to integrate... Believe me, right now you don't want to see my daily builds of mute visibility. (Or more accurately, I don't want you to see them :)) I suggest to Use TortiseSVN/Merge. It's best feature is the UI, but its > folder hooks are a pain. Eclipse also has very similar features to > TortiseSVN/Merge. In Eclipse, I especially like the merge/diff and edit all > -in-one view. My recommendation, Tortise for the major SVN jobs - Eclipse > for everything else. > TortoiseSVN has worked well for me in the past, no worries there. Able Whitman wrote: > > If I've got a patch for a JIRA issue that's not quite finished, but in a > state that can be tested, would it be good practive for me to attach the > patch to the JIRA issue, with a note that it's not the final version? > > I'm trying to find the most convenient way to share in-progress patches, > and the nice thing about putting them in JIRA is that it's a central place > for all the resources related to a particular bug. So for things like the > Sandbox ( i.e., the Yet-To-Be-Named) edition, all the current patches > could be found in JIRA without having to have some submitted via email, some > downloaded from other sites, etc. The downside is that currently there's no > common way to flag a patch as "attached, but not ready for import". > > Maybe a "ready for import" flag could be added? Or maybe the right > solution is to post the patch elsewhere (like on my own site, like I do > currently), and only attach patches to JIRA when they're done. I'd like to > do whatever is simplest and least confusing, but I'm not sure that one > solution meets both criteria. :) > > --Able > > ------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- > Power to Change the Void > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070717/d0b295e4/attachment.htm From soft at lindenlab.com Tue Jul 17 17:15:40 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jul 17 17:15:43 2007 Subject: [sldev] SLDev-Traffic #20 Message-ID: <9e6e5c9e0707171715n2892bc0frf1f00ee0f3f18fa7@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_20 SLDev-Traffic number 20 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From jianr3n at gmail.com Tue Jul 17 21:18:57 2007 From: jianr3n at gmail.com (jianren chua) Date: Tue Jul 17 21:19:01 2007 Subject: [sldev] Browser Message-ID: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> Hi, i know that the the LSL provides the lloadUrl function to load a url on an external browser, but is it possible to load the URL content without opening a browser? -- Jr Time aNd t|de waIt f0r No mAn, St0p t|me! ~Life is for now, work is for later~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/432bbcb5/attachment.htm From hud at zurich.ibm.com Wed Jul 18 03:19:54 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Wed Jul 18 03:20:24 2007 Subject: [sldev] Re:SVC-85 - friends lists not working In-Reply-To: <469B997A.8090703@lindenlab.com> References: <469691A1.4090104@lindenlab.com> <4074C793DF5C4B1093F716C3705348E5@SanMiguel> <4697B1D7.4090208@lindenlab.com> <469B1BE2.9000309@zurich.ibm.com> <469B997A.8090703@lindenlab.com> Message-ID: <469DE94A.4010806@zurich.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kelly Linden wrote: > dirk husemann wrote: >> i'm not sure whether that's related but sometimes when we retrieve group >> listings (for our automated group management tool), the grid will give >> us incomplete lists --- incomplete in that the list will not contain all >> members of the group (we end up sending out an invite to those members >> who then are rather surprised because they've been and are members of >> that group for ages); for example, the grid will tell us that there are >> 2778 members in the group, we do get 2778 entries, but in reality there >> are more than that. >> >> cheers, >> dirk >> >> > dirk, > This is a separate issue, as you guessed. If you could jira it, if it > isn't already, with any details you have that would help. ok. cheers, dirk - -- dr dirk husemann, pervasive computing, ibm zurich research lab - --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnelJPAonjmQxoUkRAuNXAJ0Sam5XDMbtzb+ut/Ujq/CKuiTyTACdGSZ+ p736mkoXeysaHIyHNVuKadY= =wwl/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/25a721e1/attachment.htm From webmaster at ligosworld.com Wed Jul 18 03:21:49 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Wed Jul 18 03:21:58 2007 Subject: [sldev] Viewer Problems Message-ID: <469DE9BD.3030801@ligosworld.com> Today I was setting up the whole project completely new, Again I did every step from: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 still having the same error. Please help, I urgendly need a workaround. Greets Andi From nicholaz at blueflash.cc Wed Jul 18 03:38:52 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 18 03:38:58 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469DE9BD.3030801@ligosworld.com> References: <469DE9BD.3030801@ligosworld.com> Message-ID: <469DEDBC.5010800@blueflash.cc> Can you repost your error again please? Nick Andreas Lichtenberger wrote: > Today I was setting up the whole project completely new, > Again I did every step from: > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 > > still having the same error. > Please help, I urgendly need a workaround. > > Greets Andi > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From webmaster at ligosworld.com Wed Jul 18 03:52:03 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Wed Jul 18 03:52:06 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469DEDBC.5010800@blueflash.cc> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> Message-ID: <469DF0D3.4010909@ligosworld.com> Of course I can: llsrv.cpp c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all the argument types c:\sldev\linden\indra\newview\llsrv.h(45): could be 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' Build log was saved at "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" newview - 1 error(s), 0 warning(s) These files are new in the 1.18.... releases. Thanks Andi Nicholaz Beresford schrieb: > > Can you repost your error again please? > > > Nick > > > > Andreas Lichtenberger wrote: >> Today I was setting up the whole project completely new, >> Again I did every step from: >> >> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >> >> still having the same error. >> Please help, I urgendly need a workaround. >> >> Greets Andi >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From jhurliman at wsu.edu Wed Jul 18 03:54:42 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Jul 18 03:54:59 2007 Subject: [sldev] Why does the simulator do object culling for clients? Message-ID: <469DF172.8020008@wsu.edu> As you move around in a simulator, the sim is constantly sending ObjectUpdate* packets for objects that become within range or have moved, and it sends ObjectKill packets for things that go outside of your vision. Then when you move back to that area it sends the ObjectUpdate* packets for those objects again. Is there a reason this culling is done across the network by sending ObjectKill packets for things that are not actually leaving the simulator? Video example: http://www.youtube.com/watch?v=TT7Mcp4Wd6M John Hurliman From dale at daleglass.net Wed Jul 18 04:37:20 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 18 04:37:26 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469DF172.8020008@wsu.edu> References: <469DF172.8020008@wsu.edu> Message-ID: <20070718113720.GA5864@bruno.sbruno> On Wed, Jul 18, 2007 at 03:54:42AM -0700, John Hurliman wrote: > As you move around in a simulator, the sim is constantly sending > ObjectUpdate* packets for objects that become within range or have > moved, and it sends ObjectKill packets for things that go outside of > your vision. Then when you move back to that area it sends the > ObjectUpdate* packets for those objects again. Is there a reason this > culling is done across the network by sending ObjectKill packets for > things that are not actually leaving the simulator? My guess: Suppose the sim didn't do that. In that case, the viewer would never know when the sim decided the object is too far away. So you'd need to have the viewer perform its own culling, or you'd have extra objects hanging around. If the culling on the viewer and sim didn't match, you'd end up with updates being sent for objects the viewer won't show, or the viewer showing objects for which the sim isn't sending updates. And since the sim determines which objects are near enough to notify you about their existence, it's only logical that it'd do the kill notification as well. Less error prone, and avoids duplicating code. Sim needs to know which objects are far enough anyway, as it has to decide when to stop sending updates. Note: This is only a rather uninformed guess, as I can't look at the source ATM. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/1b0c57cc/attachment.pgp From gigstaggart at gmail.com Wed Jul 18 04:50:13 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 18 04:50:17 2007 Subject: [sldev] Browser In-Reply-To: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> Message-ID: <469DFE75.2020901@gmail.com> jianren chua wrote: > Hi, > i know that the the LSL provides the lloadUrl function to load a url on > an external browser, but is it possible to load the URL content without > opening a browser? > No, not really. There are some hacks with quicktime, but they are cumbersome. -Jason From Paul.Hampson at Pobox.com Wed Jul 18 05:07:56 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Wed Jul 18 05:08:07 2007 Subject: [sldev] Re: shared objects output during standalone build In-Reply-To: <469CC22C.3090007@sun.com> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <469CC22C.3090007@sun.com> Message-ID: <20070718120756.GA8432@keitarou> On Tue, Jul 17, 2007 at 09:20:44AM -0400, Dana Fagerstrom wrote: > One thing many people don't realize is that scons supports the -j > option just like make/dmake. That option instructs scons to perform > multiple compiles. On a "fast" system a "-j 2" or even "-j 4" will > greatly decrease build time. > On my Ultra 40 (2 AMD dual core CPUs) I run with "-j 8" and a complete > build plus packaging is completed in less than an hour. Indeed, the usual recommendation is -j 2xCPUs (I guess CPU cores, these days) I believe on the assumption that the build will be IO-bound, hence allowing one process to run the compiler while the other is waiting on the disk. If your build is RAM-bound, then -j is disasterous, as when the scheduler decides to switch builds (ie due to disk IO waiting) you then have the disk get hammered with swapping, also preventing any useful work getting done in that spare CPU time, so making it worse. If you're RAM-bound, the usual way to improve things is to split your build up into smaller libraries, or move stuff off into shared objects where the linker doesn't need the whole object in RAM to get to and use the symbol table. Another option is to refactor your headers so that most of the compilations #include less stuff. I doubt that precompiled headers will actually help with RAM usage during the compilation itself, (since once they're compiled, they're compiled anyway) but if your preprocessor is getting RAM-bound, pre-compiled headers will at least reduce the occurance of that step. I note that ccache is setup in SConstruct, but I presume that's only for repeat-builds and server builds, since I don't see where the slviewer build process would recompile the same object... Anyone care to enlighten me? If I was going to go to the effort, I've got an old G3 box here I could run up with distcc, but I've not any other use for it now, so I don't yet feel any kind of need to do so. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/61b83d32/attachment.pgp From Paul.Hampson at Pobox.com Wed Jul 18 05:17:45 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Wed Jul 18 05:17:48 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469C9701.7040404@ligosworld.com> References: <469C9701.7040404@ligosworld.com> Message-ID: <20070718121745.GB8432@keitarou> On Tue, Jul 17, 2007 at 12:16:33PM +0200, Andreas Lichtenberger wrote: > I have a big problem compiling the current version of the viewer: > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all the argument types > c:\sldev\linden\indra\newview\llsrv.h(45): could be 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > Can anybody send help please??? I'm gonna hazard a guess, that "cur->Data.Srv.pNameTarget" on line 58 needs to be "*(cur->Data.Srv.pNameTarget)", since the constructor expects a const std::string reference, and the name of that (and the error) suggests it's a std::string pointer. Not having a c:\ on my machine, I've not tested this though. If it breaks, you can keep both pieces. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/ea701b4f/attachment.pgp From nicholaz at blueflash.cc Wed Jul 18 05:18:49 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 18 05:18:54 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469DF0D3.4010909@ligosworld.com> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> <469DF0D3.4010909@ligosworld.com> Message-ID: <469E0529.2040305@blueflash.cc> Andreas, I'll try a VS2005 compile this afternoon (I'm in Europe) and will let you know how it goes. Nick Andreas Lichtenberger wrote: > Of course I can: > > llsrv.cpp > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all > the argument types > c:\sldev\linden\indra\newview\llsrv.h(45): could be > 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > Build log was saved at > "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > newview - 1 error(s), 0 warning(s) > > These files are new in the 1.18.... releases. > > Thanks > Andi > > Nicholaz Beresford schrieb: >> >> Can you repost your error again please? >> >> >> Nick >> >> >> >> Andreas Lichtenberger wrote: >>> Today I was setting up the whole project completely new, >>> Again I did every step from: >>> >>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >>> >>> still having the same error. >>> Please help, I urgendly need a workaround. >>> >>> Greets Andi >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > From Paul.Hampson at Pobox.com Wed Jul 18 05:20:05 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Wed Jul 18 05:20:08 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <469D0983.8040901@lindenlab.com> References: <1184620013.26499.21.camel@localhost.localdomain> <469D0983.8040901@lindenlab.com> Message-ID: <20070718122005.GC8432@keitarou> On Tue, Jul 17, 2007 at 07:25:07PM +0100, Tofu Linden wrote: > I've used liboil in the past - it's pretty cool. I seem to > recall that it was fairly painful to package, though, if not > anticipating relying upon a system-installed one. It's also > quite large (another packaging concern). > The license would seem to allow one to re-use some isolated > routines if we don't want to absorb the whole library - again > I've done this in the past for personal projects and it wasn't > technically difficult. Perhaps the CPU detection could be > isolated into its own library (heck, perhaps the liboil authors > would be happy to see this isolation as a contrib). I'd very much like to see liboil used, and at least kept able to use an already-packaged version, rather than rolling more code into the slviewer core. I'm particularly keen on getting the advances of Callum and Dzonatas on vectorising with SSE2 magically translate to an Altivec implementation. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/25f7466a/attachment.pgp From blakar at gmail.com Wed Jul 18 05:21:11 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jul 18 05:21:15 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469E0529.2040305@blueflash.cc> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> <469DF0D3.4010909@ligosworld.com> <469E0529.2040305@blueflash.cc> Message-ID: <7992d0d60707180521o102d2436mfe58724faf169a6e@mail.gmail.com> I can zip and send my project files if somebody needs them. I can compile fine on VS 2005 (Express). Dirk aka Blakar Ogre On 7/18/07, Nicholaz Beresford wrote: > > Andreas, > > I'll try a VS2005 compile this afternoon (I'm in Europe) > and will let you know how it goes. > > Nick > > > Andreas Lichtenberger wrote: > > Of course I can: > > > > llsrv.cpp > > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > > 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all > > the argument types > > c:\sldev\linden\indra\newview\llsrv.h(45): could be > > 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > > Build log was saved at > > "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > newview - 1 error(s), 0 warning(s) > > > > These files are new in the 1.18.... releases. > > > > Thanks > > Andi > > > > Nicholaz Beresford schrieb: > >> > >> Can you repost your error again please? > >> > >> > >> Nick > >> > >> > >> > >> Andreas Lichtenberger wrote: > >>> Today I was setting up the whole project completely new, > >>> Again I did every step from: > >>> > >>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 > >>> > >>> still having the same error. > >>> Please help, I urgendly need a workaround. > >>> > >>> Greets Andi > >>> _______________________________________________ > >>> Click here to unsubscribe or manage your list subscription: > >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > >> > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From matthew.dowd at hotmail.co.uk Wed Jul 18 05:30:48 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 18 05:30:49 2007 Subject: [sldev] Viewer Problems Message-ID: What configuration are you trying to build. ReleaseNoOpt worked fine for me building under MSVC2005 (Express). I downloaded the VC8 project files from Jira. I did have to source a few libpng header files from the net though (although the error I got without those were entirely different). Matthew ---------------------------------------- > Date: Wed, 18 Jul 2007 12:52:03 +0200 > From: webmaster@ligosworld.com > To: nicholaz@blueflash.cc > Subject: Re: [sldev] Viewer Problems > CC: sldev@lists.secondlife.com > > Of course I can: > > llsrv.cpp > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all > the argument types > c:\sldev\linden\indra\newview\llsrv.h(45): could be > 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > Build log was saved at > "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > newview - 1 error(s), 0 warning(s) > > These files are new in the 1.18.... releases. > > Thanks > Andi > > Nicholaz Beresford schrieb: > > > > Can you repost your error again please? > > > > > > Nick > > > > > > > > Andreas Lichtenberger wrote: > >> Today I was setting up the whole project completely new, > >> Again I did every step from: > >> > >> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 > >> > >> still having the same error. > >> Please help, I urgendly need a workaround. > >> > >> Greets Andi > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From webmaster at ligosworld.com Wed Jul 18 05:31:20 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Wed Jul 18 05:31:31 2007 Subject: [sldev] Viewer Problems In-Reply-To: <7992d0d60707180521o102d2436mfe58724faf169a6e@mail.gmail.com> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> <469DF0D3.4010909@ligosworld.com> <469E0529.2040305@blueflash.cc> <7992d0d60707180521o102d2436mfe58724faf169a6e@mail.gmail.com> Message-ID: <469E0818.2030106@ligosworld.com> I?m not using the Express Version, but let?s have a try. Andi Dirk Moerenhout schrieb: > I can zip and send my project files if somebody needs them. I can > compile fine on VS 2005 (Express). > > Dirk aka Blakar Ogre > > On 7/18/07, Nicholaz Beresford wrote: >> >> Andreas, >> >> I'll try a VS2005 compile this afternoon (I'm in Europe) >> and will let you know how it goes. >> >> Nick >> >> >> Andreas Lichtenberger wrote: >> > Of course I can: >> > >> > llsrv.cpp >> > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >> > 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all >> > the argument types >> > c:\sldev\linden\indra\newview\llsrv.h(45): could be >> > 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >> > while trying to match the argument list '(WORD, WORD, >> LPTSTR, WORD)' >> > Build log was saved at >> > "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" >> > newview - 1 error(s), 0 warning(s) >> > >> > These files are new in the 1.18.... releases. >> > >> > Thanks >> > Andi >> > >> > Nicholaz Beresford schrieb: >> >> >> >> Can you repost your error again please? >> >> >> >> >> >> Nick >> >> >> >> >> >> >> >> Andreas Lichtenberger wrote: >> >>> Today I was setting up the whole project completely new, >> >>> Again I did every step from: >> >>> >> >>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >> >>> >> >>> still having the same error. >> >>> Please help, I urgendly need a workaround. >> >>> >> >>> Greets Andi >> >>> _______________________________________________ >> >>> Click here to unsubscribe or manage your list subscription: >> >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> >> >> > >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > From webmaster at ligosworld.com Wed Jul 18 05:43:22 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Wed Jul 18 05:43:27 2007 Subject: [sldev] Viewer Problems In-Reply-To: References: Message-ID: <469E0AEA.8000608@ligosworld.com> Did the same: VC8 project files from Jira, libpng header. The error appears in both configurations: ReleaseNoOpt AND ReleaseForDownload. The only difference is, that I?m using MSVC2005 Professional. Matthew Dowd schrieb: > What configuration are you trying to build. > > ReleaseNoOpt worked fine for me building under MSVC2005 (Express). I downloaded the VC8 project files from Jira. I did have to source a few libpng header files from the net though (although the error I got without those were entirely different). > > Matthew > > > > > ---------------------------------------- > >> Date: Wed, 18 Jul 2007 12:52:03 +0200 >> From: webmaster@ligosworld.com >> To: nicholaz@blueflash.cc >> Subject: Re: [sldev] Viewer Problems >> CC: sldev@lists.secondlife.com >> >> Of course I can: >> >> llsrv.cpp >> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all >> the argument types >> c:\sldev\linden\indra\newview\llsrv.h(45): could be >> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >> while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' >> Build log was saved at >> "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" >> newview - 1 error(s), 0 warning(s) >> >> These files are new in the 1.18.... releases. >> >> Thanks >> Andi >> >> Nicholaz Beresford schrieb: >> >>> Can you repost your error again please? >>> >>> >>> Nick >>> >>> >>> >>> Andreas Lichtenberger wrote: >>> >>>> Today I was setting up the whole project completely new, >>>> Again I did every step from: >>>> >>>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >>>> >>>> still having the same error. >>>> Please help, I urgendly need a workaround. >>>> >>>> Greets Andi >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _________________________________________________________________ > 100?s of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html > > From nicholaz at blueflash.cc Wed Jul 18 05:46:45 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 18 05:46:51 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469DF0D3.4010909@ligosworld.com> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> <469DF0D3.4010909@ligosworld.com> Message-ID: <469E0BB5.60805@blueflash.cc> I still have not compiled, but could it be something (especially since you say you don't have Express, so assuming you do other work with VS2005 also) in the order of the include files in Visual Studio? Nick Andreas Lichtenberger wrote: > Of course I can: > > llsrv.cpp > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all > the argument types > c:\sldev\linden\indra\newview\llsrv.h(45): could be > 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > Build log was saved at > "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > newview - 1 error(s), 0 warning(s) > > These files are new in the 1.18.... releases. > > Thanks > Andi > > Nicholaz Beresford schrieb: >> >> Can you repost your error again please? >> >> >> Nick >> >> >> >> Andreas Lichtenberger wrote: >>> Today I was setting up the whole project completely new, >>> Again I did every step from: >>> >>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >>> >>> still having the same error. >>> Please help, I urgendly need a workaround. >>> >>> Greets Andi >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > From webmaster at ligosworld.com Wed Jul 18 05:52:06 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Wed Jul 18 05:52:11 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469E0BB5.60805@blueflash.cc> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> <469DF0D3.4010909@ligosworld.com> <469E0BB5.60805@blueflash.cc> Message-ID: <469E0CF6.7060603@ligosworld.com> Sorry, I just have the global includes left, which I need for SL. I deleted all others from the global settings. Andi Nicholaz Beresford schrieb: > > I still have not compiled, but could it be something > (especially since you say you don't have Express, so > assuming you do other work with VS2005 also) in the > order of the include files in Visual Studio? > > > Nick > > > Andreas Lichtenberger wrote: >> Of course I can: >> >> llsrv.cpp >> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert >> all the argument types >> c:\sldev\linden\indra\newview\llsrv.h(45): could be >> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >> while trying to match the argument list '(WORD, WORD, LPTSTR, >> WORD)' >> Build log was saved at >> "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" >> newview - 1 error(s), 0 warning(s) >> >> These files are new in the 1.18.... releases. >> >> Thanks >> Andi >> >> Nicholaz Beresford schrieb: >>> >>> Can you repost your error again please? >>> >>> >>> Nick >>> >>> >>> >>> Andreas Lichtenberger wrote: >>>> Today I was setting up the whole project completely new, >>>> Again I did every step from: >>>> >>>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >>>> >>>> still having the same error. >>>> Please help, I urgendly need a workaround. >>>> >>>> Greets Andi >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> > > From nicholaz at blueflash.cc Wed Jul 18 06:36:29 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 18 06:36:36 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469E0CF6.7060603@ligosworld.com> References: <469DE9BD.3030801@ligosworld.com> <469DEDBC.5010800@blueflash.cc> <469DF0D3.4010909@ligosworld.com> <469E0BB5.60805@blueflash.cc> <469E0CF6.7060603@ligosworld.com> Message-ID: <469E175D.5050808@blueflash.cc> It does compile okay here but I'm seeing includes for winsock and windns there. Maybe you have different versions of that. One thing to try would be to move the include for llsrv.h down to a place below those two. Maybe there's also some strict type checking option enabled somewhere. If nothing else helps, try casting the parameters @59 to WORD recs.push_back(LLSRVRecord((WORD)cur->Data.Srv.wPriority, (WORD)cur->Data.Srv.wWeight, cur->Data.Srv.pNameTarget, (WORD)cur->Data.Srv.wPort)); Nick Andreas Lichtenberger wrote: > Sorry, I just have the global includes left, which I need for SL. > I deleted all others from the global settings. > > Andi > > Nicholaz Beresford schrieb: >> >> I still have not compiled, but could it be something >> (especially since you say you don't have Express, so >> assuming you do other work with VS2005 also) in the >> order of the include files in Visual Studio? >> >> >> Nick >> >> >> Andreas Lichtenberger wrote: >>> Of course I can: >>> >>> llsrv.cpp >>> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >>> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert >>> all the argument types >>> c:\sldev\linden\indra\newview\llsrv.h(45): could be >>> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >>> while trying to match the argument list '(WORD, WORD, LPTSTR, >>> WORD)' >>> Build log was saved at >>> "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" >>> newview - 1 error(s), 0 warning(s) >>> >>> These files are new in the 1.18.... releases. >>> >>> Thanks >>> Andi >>> >>> Nicholaz Beresford schrieb: >>>> >>>> Can you repost your error again please? >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> Andreas Lichtenberger wrote: >>>>> Today I was setting up the whole project completely new, >>>>> Again I did every step from: >>>>> >>>>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >>>>> >>>>> still having the same error. >>>>> Please help, I urgendly need a workaround. >>>>> >>>>> Greets Andi >>>>> _______________________________________________ >>>>> Click here to unsubscribe or manage your list subscription: >>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> >>> >> >> > From dzonatas at dzonux.net Wed Jul 18 07:09:56 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 07:09:50 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <20070718122005.GC8432@keitarou> References: <1184620013.26499.21.camel@localhost.localdomain> <469D0983.8040901@lindenlab.com> <20070718122005.GC8432@keitarou> Message-ID: <469E1F34.3090903@dzonux.net> Prepackaged and optimized routines are good if have nothing else handy. They provide better than moderate speed improvements. The problem with such routines is that their robustness and call structure tend to take a performance hit. If one wants the fastest code, then prepackaged routines aren't the best solution. The QuickTime library is already cross-platform and has many different optimized vector routines. If you downloaded QT to build the source, you have these routines on your disk. See these: vBLAS.h vBasicOps.h vBigNum.h vDSP.h vecLib.h vectorOps.h vfp.h =) Paul TBBle Hampson wrote: > On Tue, Jul 17, 2007 at 07:25:07PM +0100, Tofu Linden wrote: > >> I've used liboil in the past - it's pretty cool. I seem to >> recall that it was fairly painful to package, though, if not >> anticipating relying upon a system-installed one. It's also >> quite large (another packaging concern). >> > > >> The license would seem to allow one to re-use some isolated >> routines if we don't want to absorb the whole library - again >> I've done this in the past for personal projects and it wasn't >> technically difficult. Perhaps the CPU detection could be >> isolated into its own library (heck, perhaps the liboil authors >> would be happy to see this isolation as a contrib). >> > > I'd very much like to see liboil used, and at least kept able to use an > already-packaged version, rather than rolling more code into the > slviewer core. > > I'm particularly keen on getting the advances of Callum and Dzonatas on > vectorising with SSE2 magically translate to an Altivec implementation. > > ^_^ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/76729787/attachment.htm From matthew.dowd at hotmail.co.uk Wed Jul 18 07:10:01 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jul 18 07:10:03 2007 Subject: [sldev] Viewer Problems Message-ID: Actually I'd suggest force casting them to U16 which is what the constructor is expecting. If that doesn't work you could try also casting the pNameTarget too: recs.push_back(LLSRVRecord((U16)cur->Data.Srv.wPriority, (U16)cur->Data.Srv.wWeight, (const std::string&)cur->Data.Srv.pNameTarget, (U16)cur->Data.Srv.wPort)); Matthew ---------------------------------------- > Date: Wed, 18 Jul 2007 15:36:29 +0200 > From: nicholaz@blueflash.cc > To: webmaster@ligosworld.com > Subject: Re: [sldev] Viewer Problems > CC: sldev@lists.secondlife.com > > > It does compile okay here but I'm seeing includes for > winsock and windns there. Maybe you have different versions of > that. > > One thing to try would be to move the include for llsrv.h down > to a place below those two. > > Maybe there's also some strict type checking option enabled > somewhere. > > If nothing else helps, try casting the parameters @59 > to WORD > > recs.push_back(LLSRVRecord((WORD)cur->Data.Srv.wPriority, > (WORD)cur->Data.Srv.wWeight, > cur->Data.Srv.pNameTarget, > (WORD)cur->Data.Srv.wPort)); > > > > Nick > > > Andreas Lichtenberger wrote: > > Sorry, I just have the global includes left, which I need for SL. > > I deleted all others from the global settings. > > > > Andi > > > > Nicholaz Beresford schrieb: > >> > >> I still have not compiled, but could it be something > >> (especially since you say you don't have Express, so > >> assuming you do other work with VS2005 also) in the > >> order of the include files in Visual Studio? > >> > >> > >> Nick > >> > >> > >> Andreas Lichtenberger wrote: > >>> Of course I can: > >>> > >>> llsrv.cpp > >>> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: > >>> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert > >>> all the argument types > >>> c:\sldev\linden\indra\newview\llsrv.h(45): could be > >>> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > >>> while trying to match the argument list '(WORD, WORD, LPTSTR, > >>> WORD)' > >>> Build log was saved at > >>> "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > >>> newview - 1 error(s), 0 warning(s) > >>> > >>> These files are new in the 1.18.... releases. > >>> > >>> Thanks > >>> Andi > >>> > >>> Nicholaz Beresford schrieb: > >>>> > >>>> Can you repost your error again please? > >>>> > >>>> > >>>> Nick > >>>> > >>>> > >>>> > >>>> Andreas Lichtenberger wrote: > >>>>> Today I was setting up the whole project completely new, > >>>>> Again I did every step from: > >>>>> > >>>>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 > >>>>> > >>>>> still having the same error. > >>>>> Please help, I urgendly need a workaround. > >>>>> > >>>>> Greets Andi > >>>>> _______________________________________________ > >>>>> Click here to unsubscribe or manage your list subscription: > >>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >>>> > >>>> > >>> > >> > >> > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From nicholaz at blueflash.cc Wed Jul 18 07:24:45 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 18 07:24:55 2007 Subject: [sldev] Viewer Problems In-Reply-To: References: Message-ID: <469E22AD.5010901@blueflash.cc> Matt, of course you're right, cast to U16, not WORD Andi, For debugging this, it may be helpful to just add a std::string dummy = cur->Data.Srv.pNameTarget; std::string &dummy_ref = cur->Data.Srv.pNameTarget; to see if these give an error message about not being able to convert. Nick Matthew Dowd wrote: > Actually I'd suggest force casting them to U16 which is what the constructor is expecting. If that doesn't work you could try also casting the pNameTarget too: > > recs.push_back(LLSRVRecord((U16)cur->Data.Srv.wPriority, > (U16)cur->Data.Srv.wWeight, > (const std::string&)cur->Data.Srv.pNameTarget, > (U16)cur->Data.Srv.wPort)); > > Matthew > > > > > ---------------------------------------- >> Date: Wed, 18 Jul 2007 15:36:29 +0200 >> From: nicholaz@blueflash.cc >> To: webmaster@ligosworld.com >> Subject: Re: [sldev] Viewer Problems >> CC: sldev@lists.secondlife.com >> >> >> It does compile okay here but I'm seeing includes for >> winsock and windns there. Maybe you have different versions of >> that. >> >> One thing to try would be to move the include for llsrv.h down >> to a place below those two. >> >> Maybe there's also some strict type checking option enabled >> somewhere. >> >> If nothing else helps, try casting the parameters @59 >> to WORD >> >> recs.push_back(LLSRVRecord((WORD)cur->Data.Srv.wPriority, >> (WORD)cur->Data.Srv.wWeight, >> cur->Data.Srv.pNameTarget, >> (WORD)cur->Data.Srv.wPort)); >> >> >> >> Nick >> >> >> Andreas Lichtenberger wrote: >>> Sorry, I just have the global includes left, which I need for SL. >>> I deleted all others from the global settings. >>> >>> Andi >>> >>> Nicholaz Beresford schrieb: >>>> I still have not compiled, but could it be something >>>> (especially since you say you don't have Express, so >>>> assuming you do other work with VS2005 also) in the >>>> order of the include files in Visual Studio? >>>> >>>> >>>> Nick >>>> >>>> >>>> Andreas Lichtenberger wrote: >>>>> Of course I can: >>>>> >>>>> llsrv.cpp >>>>> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: >>>>> 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert >>>>> all the argument types >>>>> c:\sldev\linden\indra\newview\llsrv.h(45): could be >>>>> 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >>>>> while trying to match the argument list '(WORD, WORD, LPTSTR, >>>>> WORD)' >>>>> Build log was saved at >>>>> "file://c:\SLDEV\linden\indra\newview\ReleaseForDownload\BuildLog.htm" >>>>> newview - 1 error(s), 0 warning(s) >>>>> >>>>> These files are new in the 1.18.... releases. >>>>> >>>>> Thanks >>>>> Andi >>>>> >>>>> Nicholaz Beresford schrieb: >>>>>> Can you repost your error again please? >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> Andreas Lichtenberger wrote: >>>>>>> Today I was setting up the whole project completely new, >>>>>>> Again I did every step from: >>>>>>> >>>>>>> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 >>>>>>> >>>>>>> still having the same error. >>>>>>> Please help, I urgendly need a workaround. >>>>>>> >>>>>>> Greets Andi >>>>>>> _______________________________________________ >>>>>>> Click here to unsubscribe or manage your list subscription: >>>>>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>>>> >>>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > The next generation of MSN Hotmail has arrived - Windows Live Hotmail > http://www.newhotmail.co.uk From soft at lindenlab.com Wed Jul 18 07:25:03 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jul 18 07:25:06 2007 Subject: [sldev] Open Source Meeting Agenda - Thursday 2pm Message-ID: <9e6e5c9e0707180725r44117fccr3b1da0fcdac4958f@mail.gmail.com> The weekly Open Source office hours are Thursday, at 2pm. If there's something you'd like to spend time on before going to general conversation, please add it to the agenda: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Thanks! From gigstaggart at gmail.com Wed Jul 18 07:40:25 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 18 07:40:25 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <469E1F34.3090903@dzonux.net> References: <1184620013.26499.21.camel@localhost.localdomain> <469D0983.8040901@lindenlab.com> <20070718122005.GC8432@keitarou> <469E1F34.3090903@dzonux.net> Message-ID: <469E2659.5050902@gmail.com> Dzonatas wrote: > The QuickTime library is already cross-platform and has many different > optimized vector routines. If you downloaded QT to build the source, you > have these routines on your disk. Since when is QuickTime open source? -Jason From eponymousdylan at googlemail.com Wed Jul 18 08:31:59 2007 From: eponymousdylan at googlemail.com (EponymousDylan Ra) Date: Wed Jul 18 08:32:02 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469E22AD.5010901@blueflash.cc> References: <469E22AD.5010901@blueflash.cc> Message-ID: I might be way off, but it seems most likely that for some reason windns.his not recognising the #undef UNICODE (ugh, btw), meaning that the string in DNS_RECORD is 16-bit rather than 8-bit, and hence can't be converted to a std::string. A quick test of this theory would be to replace DNS_RECORD with DNS_RECORDA, and DnsQuery with DnsQuery_A, and see if that fixes the problem. E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/92c63958/attachment.htm From tateru.nino at gmail.com Wed Jul 18 08:38:02 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 18 08:38:08 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <20070718113720.GA5864@bruno.sbruno> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> Message-ID: <469E33DA.2070005@gmail.com> Considering the amount of ghosting we generally see (due to lost ObjectKill packets), I'm wondering if it isn't a good idea for the viewer to be able to periodically poll 'stale' objects (ones that have had no Update for a while) just to verify that they're still present. Having avatars and objects that have long since gone hang around in your viewer for an hour or two - that can be a little odd, or even unsettling at times. Dale Glass wrote: > On Wed, Jul 18, 2007 at 03:54:42AM -0700, John Hurliman wrote: > >> As you move around in a simulator, the sim is constantly sending >> ObjectUpdate* packets for objects that become within range or have >> moved, and it sends ObjectKill packets for things that go outside of >> your vision. Then when you move back to that area it sends the >> ObjectUpdate* packets for those objects again. Is there a reason this >> culling is done across the network by sending ObjectKill packets for >> things that are not actually leaving the simulator? >> > > My guess: > > Suppose the sim didn't do that. In that case, the viewer would never > know when the sim decided the object is too far away. So you'd need to > have the viewer perform its own culling, or you'd have extra objects > hanging around. > > If the culling on the viewer and sim didn't match, you'd end up with > updates being sent for objects the viewer won't show, or the viewer > showing objects for which the sim isn't sending updates. > > And since the sim determines which objects are near enough to notify you > about their existence, it's only logical that it'd do the kill > notification as well. Less error prone, and avoids duplicating code. > Sim needs to know which objects are far enough anyway, as it has to > decide when to stop sending updates. > > Note: This is only a rather uninformed guess, as I can't look at the > source ATM. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From secret.argent at gmail.com Wed Jul 18 09:11:39 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 18 09:11:43 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? In-Reply-To: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> References: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> Message-ID: Dale Glass: > On Wed, Jul 18, 2007 at 03:54:42AM -0700, John Hurliman wrote: >> As you move around in a simulator, the sim is constantly sending >> ObjectUpdate* packets for objects that become within range or have >> moved, and it sends ObjectKill packets for things that go outside of >> your vision. Then when you move back to that area it sends the >> ObjectUpdate* packets for those objects again. Is there a reason this >> culling is done across the network by sending ObjectKill packets for >> things that are not actually leaving the simulator? > Suppose the sim didn't do that. In that case, the viewer would never > know when the sim decided the object is too far away. So you'd need to > have the viewer perform its own culling, or you'd have extra objects > hanging around. Why does the sim need to decide which objects are near enough to notify you about their existence? The range is determined by the viewer and changed by the viewer, and the viewer is performing its own culling anyway as it runs level-of-detail calculations. From nicholaz at blueflash.cc Wed Jul 18 09:16:55 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jul 18 09:17:14 2007 Subject: [sldev] Viewer Problems In-Reply-To: References: <469E22AD.5010901@blueflash.cc> Message-ID: <469E3CF7.4080203@blueflash.cc> Now, thinking about it being highly unlikely that the compiler can't convert between U16 and WORD, I guess instead of being way off, you might have hit the nail on the head. In any case, changing the calls/structures to those with a specific narrow/wide character type will be a good idea nonetheless. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ EponymousDylan Ra wrote: > I might be way off, but it seems most likely that for some reason > windns.h is not recognising the #undef UNICODE (ugh, btw), meaning that > the string in DNS_RECORD is 16-bit rather than 8-bit, and hence can't > be converted to a std::string. > > A quick test of this theory would be to replace DNS_RECORD with > DNS_RECORDA, and DnsQuery with DnsQuery_A, and see if that fixes the > problem. > > E > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From doug at lindenlab.com Wed Jul 18 10:10:48 2007 From: doug at lindenlab.com (Douglas Soo) Date: Wed Jul 18 10:12:25 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? In-Reply-To: References: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> Message-ID: <92CBF7CED4DAF2921CC1E91A@[10.1.8.55]> The ObjectKill message is a message that is sent when your agent on the simulator has decided to unsubscribe to an object on the simulator. The primary reason why it needs to be send is that once your agent on the simulator isn't paying attention to objects, it won't send further updates to the viewer, which will cause lots of interesting artifacts in the case of objects that change when you aren't subscribed. In particular, moving objects can cause quite a headache (ghosting, etc.) - so the correct behavior is to cull the object from the viewer completely. The logic that decides to subscribe and unsubscribe to objects is done based on groupings of objects based on type, size, and location in the region. Right now subscription and unsubscription is done based on a circular keyhole layout, with a bit of hysteresis to reduce subscription thrashing. If you turn down your bandwidth and teleport to a new region (or clear your caches), you should see this effect pretty well. - Doug --On Wednesday, July 18, 2007 11:11 AM -0500 Argent Stonecutter wrote: > Dale Glass: >> On Wed, Jul 18, 2007 at 03:54:42AM -0700, John Hurliman wrote: >>> As you move around in a simulator, the sim is constantly sending >>> ObjectUpdate* packets for objects that become within range or have >>> moved, and it sends ObjectKill packets for things that go outside of >>> your vision. Then when you move back to that area it sends the >>> ObjectUpdate* packets for those objects again. Is there a reason this >>> culling is done across the network by sending ObjectKill packets for >>> things that are not actually leaving the simulator? > >> Suppose the sim didn't do that. In that case, the viewer would never >> know when the sim decided the object is too far away. So you'd need to >> have the viewer perform its own culling, or you'd have extra objects >> hanging around. > > Why does the sim need to decide which objects are near enough to notify > you about their existence? The range is determined by the viewer and > changed by the viewer, and the viewer is performing its own culling > anyway as it runs level-of-detail calculations. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Douglas Soo Studio Director Linden Lab San Francisco doug@lindenlab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/f2f65ebe/attachment-0001.pgp From dale at daleglass.net Wed Jul 18 10:24:40 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 18 10:24:46 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469E33DA.2070005@gmail.com> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> Message-ID: <20070718172440.GB5864@bruno.sbruno> On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote: > Considering the amount of ghosting we generally see (due to lost > ObjectKill packets), I'm wondering if it isn't a good idea for the > viewer to be able to periodically poll 'stale' objects (ones that have > had no Update for a while) just to verify that they're still present. > Having avatars and objects that have long since gone hang around in your > viewer for an hour or two - that can be a little odd, or even unsettling > at times. That sounds like a hack. ObjectKill is sent over UDP, I suppose? I haven't looked at networking code much yet. But if so, polling isn't the right way to do it, the problem is that the message should be reliable and isn't. So move it to TCP, ensuring it's always delivered. Then so long the sim and viewer aren't buggy that should be all that's needed. Imagine the amount of extra bandwidth needed for periodically checking all the objects you can see if you set draw distance to 512M. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/a08b75db/attachment.pgp From dzonatas at dzonux.net Wed Jul 18 10:28:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 10:28:56 2007 Subject: [sldev] Viewer Problems In-Reply-To: <20070718121745.GB8432@keitarou> References: <469C9701.7040404@ligosworld.com> <20070718121745.GB8432@keitarou> Message-ID: <469E4DD5.9020206@dzonux.net> I've run into this situation with MinGW. It is do to distinct types. MSVC has been a little less strict about distinct types. See: https://jira.secondlife.com/browse/VWR-186 You can put a band-aid cast op in the line for now. Paul TBBle Hampson wrote: > On Tue, Jul 17, 2007 at 12:16:33PM +0200, Andreas Lichtenberger wrote: > >> I have a big problem compiling the current version of the viewer: >> > > >> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all the argument types >> c:\sldev\linden\indra\newview\llsrv.h(45): could be 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >> while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' >> > > >> Can anybody send help please??? >> > > I'm gonna hazard a guess, that "cur->Data.Srv.pNameTarget" on line 58 > needs to be "*(cur->Data.Srv.pNameTarget)", since the constructor > expects a const std::string reference, and the name of that (and the > error) suggests it's a std::string pointer. > > Not having a c:\ on my machine, I've not tested this though. If it > breaks, you can keep both pieces. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/d8530fb6/attachment.htm From secret.argent at gmail.com Wed Jul 18 10:37:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 18 10:37:24 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? In-Reply-To: <92CBF7CED4DAF2921CC1E91A@[10.1.8.55]> References: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> <92CBF7CED4DAF2921CC1E91A@[10.1.8.55]> Message-ID: <8B1BB870-2F92-4226-8A42-5104060F12C8@gmail.com> On 18-Jul-2007, at 12:10, Douglas Soo wrote: > The ObjectKill message is a message that is sent when your agent on > the simulator has decided to unsubscribe to an object on the > simulator. The primary reason why it needs to be send is that once > your agent on the simulator isn't paying attention to objects, it > won't send further updates to the viewer, which will cause lots of > interesting artifacts in the case of objects that change when you > aren't subscribed. In particular, moving objects can cause quite a > headache (ghosting, etc.) - so the correct behavior is to cull the > object from the viewer completely. Interesting. This explains the problem where objects vanish while you're cammed in near them, because the subscription list is based on your physical position rather than your camera position. I was thinking that letting the client handle the *un*subscription would alleviate this problem, but obviously it's more complex than that. From able.whitman at gmail.com Wed Jul 18 10:43:09 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 18 10:43:11 2007 Subject: [sldev] Viewer Problems In-Reply-To: <469E4DD5.9020206@dzonux.net> References: <469C9701.7040404@ligosworld.com> <20070718121745.GB8432@keitarou> <469E4DD5.9020206@dzonux.net> Message-ID: <7b3a84fb0707181043m6c1deec2jb0c29c53eacfdff1@mail.gmail.com> What's puzzling to me is that this error is occurring in the first place. I'm using the Standard Edition of VS 2005 (not Express). I've built the viewer using both the wiki instructions and using the project files posted on JIRA (http://jira.secondlife.com/browse/VWR-1151), and I haven't run into this issue. The only thing I can think of is that since DNS_RECORD gets pulled in from windns.h, perhaps the problem is caused by using an older version of the Windows Platform SDK. The latest is the Windows Server 2003 R2 Platform SDK, March 2006 edition: http://www.microsoft.com/downloads/details.aspx?FamilyId=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en On 7/18/07, Dzonatas wrote: > > > I've run into this situation with MinGW. It is do to distinct types. MSVC > has been a little less strict about distinct types. > > See: https://jira.secondlife.com/browse/VWR-186 > > You can put a band-aid cast op in the line for now. > > Paul TBBle Hampson wrote: > > On Tue, Jul 17, 2007 at 12:16:33PM +0200, Andreas Lichtenberger wrote: > > I have a big problem compiling the current version of the viewer: > > c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all the argument types > c:\sldev\linden\indra\newview\llsrv.h(45): could be 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' > while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' > > Can anybody send help please??? > > I'm gonna hazard a guess, that "cur->Data.Srv.pNameTarget" on line 58 > needs to be "*(cur->Data.Srv.pNameTarget)", since the constructor > expects a const std::string reference, and the name of that (and the > error) suggests it's a std::string pointer. > > Not having a c:\ on my machine, I've not tested this though. If it > breaks, you can keep both pieces. > > ------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- > Power to Change the Void > > _______________________________________________ > 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/20070718/0b5504bd/attachment.htm From doug at lindenlab.com Wed Jul 18 10:48:06 2007 From: doug at lindenlab.com (Douglas Soo) Date: Wed Jul 18 10:48:17 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? In-Reply-To: <8B1BB870-2F92-4226-8A42-5104060F12C8@gmail.com> References: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> <92CBF7CED4DAF2921CC1E91A@[10.1.8.55]> <8B1BB870-2F92-4226-8A42-5104060F12C8@gmail.com> Message-ID: <32A309A2FBC9E38308A4FC9A@[10.1.8.55]> Actually, objects diappearing when you're near them may be due to a client side culling issue. Moving the camera shouldn't generally cause objects to be unsubscribed - camera position and direction is used for determining which objects to subscribe to first, but for the purposes of unsubscription, I believe that only your avatar position is used. The subscription and unsubscription logic needs a lot of work, and will likely eventually be moved to be viewer-side. I leave it as an exercise for the reader to figure out what the optimal strategies for this are. :) - Doug --On Wednesday, July 18, 2007 12:37 PM -0500 Argent Stonecutter wrote: > On 18-Jul-2007, at 12:10, Douglas Soo wrote: >> The ObjectKill message is a message that is sent when your agent on >> the simulator has decided to unsubscribe to an object on the >> simulator. The primary reason why it needs to be send is that once >> your agent on the simulator isn't paying attention to objects, it >> won't send further updates to the viewer, which will cause lots of >> interesting artifacts in the case of objects that change when you >> aren't subscribed. In particular, moving objects can cause quite a >> headache (ghosting, etc.) - so the correct behavior is to cull the >> object from the viewer completely. > > Interesting. This explains the problem where objects vanish while you're > cammed in near them, because the subscription list is based on your > physical position rather than your camera position. I was thinking that > letting the client handle the *un*subscription would alleviate this > problem, but obviously it's more complex than that. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- Douglas Soo Studio Director Linden Lab San Francisco doug@lindenlab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/a767e8a7/attachment.pgp From dzonatas at dzonux.net Wed Jul 18 10:49:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 10:49:09 2007 Subject: [sldev] Viewer Problems In-Reply-To: <7b3a84fb0707181043m6c1deec2jb0c29c53eacfdff1@mail.gmail.com> References: <469C9701.7040404@ligosworld.com> <20070718121745.GB8432@keitarou> <469E4DD5.9020206@dzonux.net> <7b3a84fb0707181043m6c1deec2jb0c29c53eacfdff1@mail.gmail.com> Message-ID: <469E5298.5020007@dzonux.net> I'm not using those project files, but I do use Express. I think you are right. Either there or from the cygwin/mingw includes that get installed with cygwin. Able Whitman wrote: > What's puzzling to me is that this error is occurring in the first > place. I'm using the Standard Edition of VS 2005 (not Express). I've > built the viewer using both the wiki instructions and using the > project files posted on JIRA ( > http://jira.secondlife.com/browse/VWR-1151), and I haven't run into > this issue. > > The only thing I can think of is that since DNS_RECORD gets pulled in > from windns.h, perhaps the problem is caused by using an older version > of the Windows Platform SDK. The latest is the Windows Server 2003 R2 > Platform SDK, March 2006 edition: > http://www.microsoft.com/downloads/details.aspx?FamilyId=0BAF2B35-C656-4969-ACE8-E4C0C0716ADB&displaylang=en > > > > On 7/18/07, *Dzonatas* < dzonatas@dzonux.net > > wrote: > > > I've run into this situation with MinGW. It is do to distinct > types. MSVC has been a little less strict about distinct types. > > See: https://jira.secondlife.com/browse/VWR-186 > > You can put a band-aid cast op in the line for now. > > Paul TBBle Hampson wrote: >> On Tue, Jul 17, 2007 at 12:16:33PM +0200, Andreas Lichtenberger wrote: >> >>> I have a big problem compiling the current version of the viewer: >>> >> >>> c:\sldev\linden\indra\newview\llsrv.cpp(59) : error C2665: 'LLSRVRecord::LLSRVRecord' : none of the 2 overloads could convert all the argument types >>> c:\sldev\linden\indra\newview\llsrv.h(45): could be 'LLSRVRecord::LLSRVRecord(U16,U16,const std::string &,U16)' >>> >>> while trying to match the argument list '(WORD, WORD, LPTSTR, WORD)' >>> >> >>> Can anybody send help please??? >>> >> I'm gonna hazard a guess, that "cur->Data.Srv.pNameTarget" on line 58 >> needs to be "*(cur->Data.Srv.pNameTarget)", since the constructor >> expects a const std::string reference, and the name of that (and the >> >> error) suggests it's a std::string pointer. >> >> Not having a c:\ on my machine, I've not tested this though. If it >> breaks, you can keep both pieces. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > -- > Power to Change the Void > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/db3cf6a3/attachment-0001.htm From dzonatas at dzonux.net Wed Jul 18 10:57:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 10:57:07 2007 Subject: [sldev] Installer for 1.18.0.6.OS.3 Message-ID: <469E5478.8070003@dzonux.net> I decided to go with InstallJammer. It is nice. http://sourceforge.net/project/showfiles.php?group_id=191214 The setup exe is up. It creates its own directory, settings file and defaults to the aditi grid, but Agni can still be selected. Cheers! =) -- Power to Change the Void From secret.argent at gmail.com Wed Jul 18 11:09:29 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 18 11:09:34 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? In-Reply-To: <32A309A2FBC9E38308A4FC9A@[10.1.8.55]> References: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> <92CBF7CED4DAF2921CC1E91A@[10.1.8.55]> <8B1BB870-2F92-4226-8A42-5104060F12C8@gmail.com> <32A309A2FBC9E38308A4FC9A@[10.1.8.55]> Message-ID: <41C79377-F0B5-4AC3-B4CC-49D6A96FD565@gmail.com> On 18-Jul-2007, at 12:48, Douglas Soo wrote: > Actually, objects diappearing when you're near them may be due to a > client side culling issue. I'm talking about objects disappearing when my camera is near them but I'm not. > Moving the camera shouldn't generally cause objects to be > unsubscribed - camera position and direction is used for > determining which objects to subscribe to first, but for the > purposes of unsubscription, I believe that only your avatar > position is used. That would be the problem in question. :) From hawk.carter at unix-dev.de Wed Jul 18 11:12:49 2007 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Wed Jul 18 11:13:18 2007 Subject: [sldev] About the Open Source Viewer References: <01a401c7c827$65504e70$a4689943@gwsystems2.com> Message-ID: <00a001c7c967$4ac49480$8901a8c0@main1> Hows about the Name..easy and fast : Secondlife - BEE Secondlife - SBE maybe cuz we have now many homebrews, name/surname shorts ? Secondlife - BEE-HC Secondlife - SBE-DG etc ?? Just an "stupid" idea ;) ----- Original Message ----- From: "Gary Wardell" To: "'Dzonatas'" Cc: Sent: Tuesday, July 17, 2007 6:03 AM Subject: RE: [sldev] About the Open Source Viewer > Never been to the sandbox sim so I don't know that one. > > But there are sandboxes elsewhere that aren't bad, so I like that name as > well. > >> -----Original Message----- >> From: sldev-bounces@lists.secondlife.com >> [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Dzonatas >> Sent: Mon, July 16, 2007 11:34 PM >> To: Chance Unknown; Kamilion >> Cc: sldev@lists.secondlife.com >> Subject: Re: [sldev] About the Open Source Viewer >> >> >> Uh... I did advertise a request for those who want accounts on OSLCC. >> >> Anyways.... >> >> In code sense... "Sandbox" would be positive. That we know. >> >> In Second Life, it may be looked upon differently. If you >> spent time in >> the sandbox sim, you know this. >> >> Chance Unknown wrote: >> > right: he registered the project at sourceforge, and maintains the >> > checkins there so if you know what your downloading, call >> it whatever >> > he wants to... >> > >> > On 7/16/07, Dzonatas wrote: >> >> Kamilion wrote: >> >> > And FWIW, I like "Sandbox Edition" as well -- most >> residents know what >> >> > a sandbox is in SL terms ;) >> >> > >> >> >> >> Where you get shot at and caged often by random griefers? >> >> >> >> -- >> >> Power to Change the Void >> >> _______________________________________________ >> >> Click here to unsubscribe or manage your list subscription: >> >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > >> > >> >> -- >> Power to Change the Void >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Wed Jul 18 11:13:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jul 18 11:13:22 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? (Dale Glass) In-Reply-To: <20070718174909.E168941AF94@stupor.lindenlab.com> References: <20070718174909.E168941AF94@stupor.lindenlab.com> Message-ID: <83EE87DE-78DA-4543-AC08-7E7F63D7BC29@gmail.com> On 18-Jul-2007, at 12:49, sldev-request@lists.secondlife.com wrote: > ObjectKill is sent over UDP, I suppose? I haven't looked at networking > code much yet. But if so, polling isn't the right way to do it, the > problem is that the message should be reliable and isn't. So move > it to > TCP, ensuring it's always delivered. Then so long the sim and viewer > aren't buggy that should be all that's needed. So long as ObjectUpdate stays UDP. > Imagine the amount of extra bandwidth needed for periodically checking > all the objects you can see if you set draw distance to 512M. It probably needs to at least do a check when you focus on an object. That way you could kill a ghost by right clicking it. From adam at gwala.net Wed Jul 18 12:11:31 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Jul 18 12:12:04 2007 Subject: [sldev] Re: Why does the simulator do object culling for clients? In-Reply-To: <32A309A2FBC9E38308A4FC9A@[10.1.8.55]> References: <20070718122119.A4B2441AFBA@stupor.lindenlab.com> <92CBF7CED4DAF2921CC1E91A@[10.1.8.55]> <8B1BB870-2F92-4226-8A42-5104060F12C8@gmail.com> <32A309A2FBC9E38308A4FC9A@[10.1.8.55]> Message-ID: <469E65E3.4040705@gwala.net> Incidentally, removing this logic from the simulator results in a pretty heavy cutback on CPU requirements for the server in my own experience, since you can pretty much ditch the whole 'interest list' thing, without really affecting the client too much (although your bandwidth bills will go up). Adam Douglas Soo wrote: > Actually, objects diappearing when you're near them may be due to a > client side culling issue. Moving the camera shouldn't generally cause > objects to be unsubscribed - camera position and direction is used for > determining which objects to subscribe to first, but for the purposes of > unsubscription, I believe that only your avatar position is used. > > The subscription and unsubscription logic needs a lot of work, and will > likely eventually be moved to be viewer-side. I leave it as an exercise > for the reader to figure out what the optimal strategies for this are. :) > > - Doug > > --On Wednesday, July 18, 2007 12:37 PM -0500 Argent Stonecutter > wrote: > >> On 18-Jul-2007, at 12:10, Douglas Soo wrote: >> >>> The ObjectKill message is a message that is sent when your agent on >>> the simulator has decided to unsubscribe to an object on the >>> simulator. The primary reason why it needs to be send is that once >>> your agent on the simulator isn't paying attention to objects, it >>> won't send further updates to the viewer, which will cause lots of >>> interesting artifacts in the case of objects that change when you >>> aren't subscribed. In particular, moving objects can cause quite a >>> headache (ghosting, etc.) - so the correct behavior is to cull the >>> object from the viewer completely. >> >> >> Interesting. This explains the problem where objects vanish while you're >> cammed in near them, because the subscription list is based on your >> physical position rather than your camera position. I was thinking that >> letting the client handle the *un*subscription would alleviate this >> problem, but obviously it's more complex than that. >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Wed Jul 18 13:02:14 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 18 13:02:17 2007 Subject: [sldev] Re: Mute Visibility Preview (Re: More on Mute Visibility) In-Reply-To: <7b3a84fb0707061244p5b8ecfaahcd8aabadd9f7ed0d@mail.gmail.com> References: <7b3a84fb0707061244p5b8ecfaahcd8aabadd9f7ed0d@mail.gmail.com> Message-ID: <7b3a84fb0707181302kfdfe28ey5e718d7d6bfabc66@mail.gmail.com> I've released an updated preview of the Mute Visibility ( http://jira.secondlife.com/browse/VWR-1017) patch. The latest patch also includes an implementation of auto-unmuting ( http://jira.secondlife.com/browse/VWR-1735) , as discussed on this list. Installer and release notes are here: http://ablewhitman.org/viewer/ The complete patch is here: http://ablewhitman.org/viewer/aw-41572.patch.zip Barring any new bugs, this patch is pretty close to the one I will be submitting to JIRA. I'm going to let my extremely helpful testers bang away at it for a few days first, and I still need to clean up both the feature spec and the test plan I've created for the mute visibility features. Hopefully I will be ready to submit the patch in about a week. Cheers! --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/99773388/attachment.htm From robla at lindenlab.com Wed Jul 18 14:12:33 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jul 18 14:12:41 2007 Subject: [sldev] Thoughts on test plans? Message-ID: <469E8241.4030502@lindenlab.com> Hi folks, You may have noticed a few months ago that a new QA Portal sprang up on wiki.secondlife.com https://wiki.secondlife.com/wiki/QA_Portal One of the key features there is a set of testplans, linked to from the right. These are test plans that are run by our QA team with major releases There doesn't seem to have been much activity on these from Residents besides the occasional typo fix. My hope would be that there would at least be some discussion on the talk pages for these test plans, asking about the things that aren't covered. If there's something that seems to break often, but doesn't seem to be in the test plan, make a note of it on the talk page. I'm guessing that most people didn't know these were there. Take a look, and let us know what you think. I've added it to the agenda for the meeting tomorrow: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/3195d4fa/signature.pgp From chance at kalacia.com Wed Jul 18 14:29:42 2007 From: chance at kalacia.com (Chance Unknown) Date: Wed Jul 18 14:29:45 2007 Subject: [sldev] Thoughts on test plans? In-Reply-To: <469E8241.4030502@lindenlab.com> References: <469E8241.4030502@lindenlab.com> Message-ID: <2925011a0707181429o2f9ec433gaab298f8dc61e9fc@mail.gmail.com> Have any attempts been made to get the goreans on board with testing? They would be heavy consumers of simultaneous uses of the animations, streaming media, and erm the voice client. I am sure a couple of slave kennels would have some routine roleplay that someone might like to document as a quality assurance test case. On 7/18/07, Rob Lanphier wrote: > > Hi folks, > > You may have noticed a few months ago that a new QA Portal sprang up on > wiki.secondlife.com > https://wiki.secondlife.com/wiki/QA_Portal > > One of the key features there is a set of testplans, linked to from the > right. These are test plans that are run by our QA team with major > releases > > There doesn't seem to have been much activity on these from Residents > besides the occasional typo fix. My hope would be that there would at > least be some discussion on the talk pages for these test plans, asking > about the things that aren't covered. If there's something that seems > to break often, but doesn't seem to be in the test plan, make a note of > it on the talk page. > > I'm guessing that most people didn't know these were there. Take a > look, and let us know what you think. I've added it to the agenda for > the meeting tomorrow: > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > Rob > > > > _______________________________________________ > 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/20070718/3698d153/attachment.htm From dzonatas at dzonux.net Wed Jul 18 14:48:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 14:48:53 2007 Subject: [sldev] Funny about Mute Visibility Message-ID: <469E8ACB.4060905@dzonux.net> In a comment on the Forums: Somebody has just replied to a thread you have subscribed to entitled - Second Life 1.18.0.6.OS.3 -- Sandbox Edition - in the Resident-Run Websites forum of SL Forums. This thread is located at: http://forums.secondlife.com/showthread.php?t=198436&goto=newpost Here is the message that has just been posted: *************** The "Mute Visibility" option is interesting. Do you still bounce off a wall you don't see? Does that nude avatar go bye-bye too? What if he decides to hump your leg? Will everyone else see it but you lol :) *************** -- Power to Change the Void From tateru.nino at gmail.com Wed Jul 18 15:39:47 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 18 15:39:53 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <20070718172440.GB5864@bruno.sbruno> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> <20070718172440.GB5864@bruno.sbruno> Message-ID: <469E96B3.4060602@gmail.com> Dale Glass wrote: > On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote: > >> Considering the amount of ghosting we generally see (due to lost >> ObjectKill packets), I'm wondering if it isn't a good idea for the >> viewer to be able to periodically poll 'stale' objects (ones that have >> had no Update for a while) just to verify that they're still present. >> Having avatars and objects that have long since gone hang around in your >> viewer for an hour or two - that can be a little odd, or even unsettling >> at times. >> > > That sounds like a hack. > > ObjectKill is sent over UDP, I suppose? I haven't looked at networking > code much yet. But if so, polling isn't the right way to do it, the > problem is that the message should be reliable and isn't. So move it to > TCP, ensuring it's always delivered. Then so long the sim and viewer > aren't buggy that should be all that's needed. > > Imagine the amount of extra bandwidth needed for periodically checking > all the objects you can see if you set draw distance to 512M. > > Many of our most common complaints are caused by dropped messages that should be reliable, but aren't. :) -- Tateru Nino http://dwellonit.blogspot.com/ From jhurliman at wsu.edu Wed Jul 18 15:54:17 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Jul 18 15:54:23 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469E96B3.4060602@gmail.com> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> <20070718172440.GB5864@bruno.sbruno> <469E96B3.4060602@gmail.com> Message-ID: <469E9A19.4020201@wsu.edu> Tateru Nino wrote: > Dale Glass wrote: > >> On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote: >> >> >>> Considering the amount of ghosting we generally see (due to lost >>> ObjectKill packets), I'm wondering if it isn't a good idea for the >>> viewer to be able to periodically poll 'stale' objects (ones that have >>> had no Update for a while) just to verify that they're still present. >>> Having avatars and objects that have long since gone hang around in your >>> viewer for an hour or two - that can be a little odd, or even unsettling >>> at times. >>> >>> >> That sounds like a hack. >> >> ObjectKill is sent over UDP, I suppose? I haven't looked at networking >> code much yet. But if so, polling isn't the right way to do it, the >> problem is that the message should be reliable and isn't. So move it to >> TCP, ensuring it's always delivered. Then so long the sim and viewer >> aren't buggy that should be all that's needed. >> >> Imagine the amount of extra bandwidth needed for periodically checking >> all the objects you can see if you set draw distance to 512M. >> >> >> > Many of our most common complaints are caused by dropped messages that > should be reliable, but aren't. :) > Isn't ObjectKill sent as "Reliable"? If there is a problem with the ACKing code that's a whole different story, and if the connection quality is poor enough that packets are being given up on after the minimum five resends or whatever it is then switching to TCP probably won't fix the connection. From tateru.nino at gmail.com Wed Jul 18 16:27:03 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jul 18 16:27:10 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469E9A19.4020201@wsu.edu> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> <20070718172440.GB5864@bruno.sbruno> <469E96B3.4060602@gmail.com> <469E9A19.4020201@wsu.edu> Message-ID: <469EA1C7.6070704@gmail.com> John Hurliman wrote: > Tateru Nino wrote: >> Dale Glass wrote: >> >>> On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote: >>> >>>> Considering the amount of ghosting we generally see (due to lost >>>> ObjectKill packets), I'm wondering if it isn't a good idea for the >>>> viewer to be able to periodically poll 'stale' objects (ones that have >>>> had no Update for a while) just to verify that they're still present. >>>> Having avatars and objects that have long since gone hang around in >>>> your >>>> viewer for an hour or two - that can be a little odd, or even >>>> unsettling >>>> at times. >>>> >>> That sounds like a hack. >>> >>> ObjectKill is sent over UDP, I suppose? I haven't looked at networking >>> code much yet. But if so, polling isn't the right way to do it, the >>> problem is that the message should be reliable and isn't. So move it to >>> TCP, ensuring it's always delivered. Then so long the sim and viewer >>> aren't buggy that should be all that's needed. >>> >>> Imagine the amount of extra bandwidth needed for periodically checking >>> all the objects you can see if you set draw distance to 512M. >>> >>> >> Many of our most common complaints are caused by dropped messages that >> should be reliable, but aren't. :) >> > > Isn't ObjectKill sent as "Reliable"? If there is a problem with the > ACKing code that's a whole different story, and if the connection > quality is poor enough that packets are being given up on after the > minimum five resends or whatever it is then switching to TCP probably > won't fix the connection. There seem to be some things going missing, and I've started to look a little more closely at the messaging code to try to figure out why. Symptoms suggest that messages are not turning up at all (avatar standing up, avatar departing, object removed from simulation, etc) or are having their parameters zeroed out or mangled somehow (avatar position, appearance, attachment position). In recent days I've been starting to wonder if it is possible for the parameters for one message to be incorrectly interpreted as being part of an earlier message whose parameters may have been dropped in transit somewhere, or if there is a data-path with degenerate encoding/decoding behaviour. Time to UTSL, and see what can be seen. -- Tateru Nino http://dwellonit.blogspot.com/ From dale at daleglass.net Wed Jul 18 17:26:14 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Jul 18 17:26:20 2007 Subject: [sldev] New version with working update checks released, URL changed Message-ID: <20070719002613.GA32645@bruno.sbruno> Hi! Finished fixing the autoupdate system, so now that it actually works. Other developers are of course welcome to reuse the code for their own purposes. The previous version almost worked, but updater.exe would fail with an error after downloading my installer. Turns out there's a sanity check in it checking the installer is >= 1MB, and my installer is just 350K :-) This version will check for updates just like the official viewer, only it checks against my server instead of LL's, and installs updates faster as the download is much smaller. I'm also changing the URL where all this is found, the new one is: http://sl.daleglass.net/ For now that's not very good looking, but it works. The page is a script, so it'll update automatically when I upload new versions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/3b544606/attachment.pgp From dzonatas at dzonux.net Wed Jul 18 18:42:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 18:42:31 2007 Subject: [sldev] Thoughts on test plans? In-Reply-To: <469E8241.4030502@lindenlab.com> References: <469E8241.4030502@lindenlab.com> Message-ID: <469EC18D.5060402@dzonux.net> My thought is simply: what constitutes the "audience" for these pages? How do non-sldev people know about them? Rob Lanphier wrote: > Hi folks, > > You may have noticed a few months ago that a new QA Portal sprang up on > wiki.secondlife.com > https://wiki.secondlife.com/wiki/QA_Portal > > One of the key features there is a set of testplans, linked to from the > right. These are test plans that are run by our QA team with major releases > > There doesn't seem to have been much activity on these from Residents > besides the occasional typo fix. My hope would be that there would at > least be some discussion on the talk pages for these test plans, asking > about the things that aren't covered. If there's something that seems > to break often, but doesn't seem to be in the test plan, make a note of > it on the talk page. > > I'm guessing that most people didn't know these were there. Take a > look, and let us know what you think. I've added it to the agenda for > the meeting tomorrow: > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > Rob > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070718/5e99f00a/attachment.htm From seg at haxxed.com Wed Jul 18 18:44:34 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jul 18 18:47:35 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469EA1C7.6070704@gmail.com> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> <20070718172440.GB5864@bruno.sbruno> <469E96B3.4060602@gmail.com> <469E9A19.4020201@wsu.edu> <469EA1C7.6070704@gmail.com> Message-ID: <1184809474.31185.132.camel@localhost.localdomain> On Thu, 2007-07-19 at 09:27 +1000, Tateru Nino wrote: > There seem to be some things going missing, and I've started to look a > little more closely at the messaging code to try to figure out why. > Symptoms suggest that messages are not turning up at all (avatar > standing up, avatar departing, object removed from simulation, etc) or > are having their parameters zeroed out or mangled somehow (avatar > position, appearance, attachment position). > > In recent days I've been starting to wonder if it is possible for the > parameters for one message to be incorrectly interpreted as being part > of an earlier message whose parameters may have been dropped in transit > somewhere, or if there is a data-path with degenerate encoding/decoding > behaviour. I often get "corrupted double-linked list" crashes from glibc, which seem to happen on sim border crosses, so there is a buffer overrun lurking somewhere. I have yet to manage to reproduce it under valgrind so I have no idea where it is happening yet, and haven't figured out any other way to nail it down. ElectricFence just causes the client to run out of RAM and die before it even finishes starting up. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070718/1a8ea76f/attachment.pgp From jhurliman at wsu.edu Wed Jul 18 18:56:31 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Jul 18 18:56:38 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469EA1C7.6070704@gmail.com> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> <20070718172440.GB5864@bruno.sbruno> <469E96B3.4060602@gmail.com> <469E9A19.4020201@wsu.edu> <469EA1C7.6070704@gmail.com> Message-ID: <469EC4CF.4070305@wsu.edu> Tateru Nino wrote: > John Hurliman wrote: > >> Tateru Nino wrote: >> >>> Dale Glass wrote: >>> >>> >>>> On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote: >>>> >>>> >>>>> Considering the amount of ghosting we generally see (due to lost >>>>> ObjectKill packets), I'm wondering if it isn't a good idea for the >>>>> viewer to be able to periodically poll 'stale' objects (ones that have >>>>> had no Update for a while) just to verify that they're still present. >>>>> Having avatars and objects that have long since gone hang around in >>>>> your >>>>> viewer for an hour or two - that can be a little odd, or even >>>>> unsettling >>>>> at times. >>>>> >>>>> >>>> That sounds like a hack. >>>> >>>> ObjectKill is sent over UDP, I suppose? I haven't looked at networking >>>> code much yet. But if so, polling isn't the right way to do it, the >>>> problem is that the message should be reliable and isn't. So move it to >>>> TCP, ensuring it's always delivered. Then so long the sim and viewer >>>> aren't buggy that should be all that's needed. >>>> >>>> Imagine the amount of extra bandwidth needed for periodically checking >>>> all the objects you can see if you set draw distance to 512M. >>>> >>>> >>>> >>> Many of our most common complaints are caused by dropped messages that >>> should be reliable, but aren't. :) >>> >>> >> Isn't ObjectKill sent as "Reliable"? If there is a problem with the >> ACKing code that's a whole different story, and if the connection >> quality is poor enough that packets are being given up on after the >> minimum five resends or whatever it is then switching to TCP probably >> won't fix the connection. >> > There seem to be some things going missing, and I've started to look a > little more closely at the messaging code to try to figure out why. > Symptoms suggest that messages are not turning up at all (avatar > standing up, avatar departing, object removed from simulation, etc) or > are having their parameters zeroed out or mangled somehow (avatar > position, appearance, attachment position). > > In recent days I've been starting to wonder if it is possible for the > parameters for one message to be incorrectly interpreted as being part > of an earlier message whose parameters may have been dropped in transit > somewhere, or if there is a data-path with degenerate encoding/decoding > behaviour. > > Time to UTSL, and see what can be seen. > One thing we found while developing libsecondlife is that out of order packets can sometimes produce the same behavior as a dropped packet. For example, if someone stands up then sits down again quickly and then sit down packet is handled before the stand up packet, the avatar will appear to be standing over the new target. The only solution we could think up was holding out of order packets in a processing queue and replaying them, which didn't seem like an acceptable solution as it would effectively lock up the network stream every time things were handled out of order. Not saying that is what is going on there but it's another angle to consider. From able.whitman at gmail.com Wed Jul 18 20:12:18 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 18 20:12:20 2007 Subject: [sldev] llGiveInventory comedy In-Reply-To: References: <20070715162834.B7E2041AFFD@stupor.lindenlab.com> <2E3DB0E9-72CE-4671-98F7-91E2DE265D52@gmail.com> <469B944F.5070401@gmail.com> Message-ID: <7b3a84fb0707182012n430e486dn5bfcc49cd5b94b5@mail.gmail.com> I actually implemented the suggestions in VWR-1735 in my latest version of the mute visibility patch, but the functionality for this bug is completely independent of the other changes I made. Since the mute visibility patch is big and complex, I created a fresh branch of 1.18.0.6 with only the auto-unmute code applied, and I've attached a smaller, simpler patch to the JIRA issue. The implementation is fairly straightforward. The only complications that arose were due to the fact that the viewer is not guaranteed to know the owner of an object when it is paid, or the name corresponding to an agent's ID, so there are some callback shenanigans which occur. Please feel free to look over the patch and post any feedback to the list, or to me directly. Cheers, --Able On 7/16/07, Brandon Husbands wrote: > > Vote it up! > https://jira.secondlife.com/browse/VWR-1735 > > > On 7/16/07, Tateru Nino wrote: > > Argent Stonecutter wrote: > > > Tateru Nino writes: > > >> Now if we can disable busy mode when someone pays an object.... :) > > > > > > I'd vote for this one as well. And any other time you do something in > > > busy mode that invites a response. > > Want to JIRA that up? > > > > -- > > Tateru Nino > > http://dwellonit.blogspot.com/ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > 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/20070718/53399158/attachment.htm From dzonatas at dzonux.net Wed Jul 18 22:21:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jul 18 22:21:31 2007 Subject: [sldev] Documented LLDynamicSharedObject & Vectorization patches Message-ID: <469EF4E1.8010409@dzonux.net> I put the updated documentation into a jira issue: https://jira.secondlife.com/browse/VWR-1812 That is a solution sub-task to the SSE2 crashes found 1.17.3.0 build: https://jira.secondlife.com/browse/VWR-1610 VWR-1812 is dependant upon the cpu detection: https://jira.secondlife.com/browse/VWR-1748 (and others as noted in that issue) Look in VWR-1812 for the details. Enjoy -- Power to Change the Void From able.whitman at gmail.com Wed Jul 18 23:30:58 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jul 18 23:31:00 2007 Subject: [sldev] Showing L$ per sqm info in Buy Land and About Land Floaters Message-ID: <7b3a84fb0707182330gd3492b0w15f0294e1ce906c3@mail.gmail.com> This is just a little thing that's annoyed me for a while, and when a friend reminded me of it tonight I decided to fix it. Here's the patch: https://jira.secondlife.com/browse/VWR-1813 Cheers, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/fa4482fd/attachment.htm From jake at lindenlab.com Wed Jul 18 23:52:27 2007 From: jake at lindenlab.com (Jake Simpson) Date: Wed Jul 18 23:52:43 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469EC4CF.4070305@wsu.edu> References: <469DF172.8020008@wsu.edu> <20070718113720.GA5864@bruno.sbruno> <469E33DA.2070005@gmail.com> <20070718172440.GB5864@bruno.sbruno> <469E96B3.4060602@gmail.com> <469E9A19.4020201@wsu.edu> <469EA1C7.6070704@gmail.com> <469EC4CF.4070305@wsu.edu> Message-ID: <469F0A2B.6060901@lindenlab.com> As Douglas has indicated, the subscribe / unsubscribe code in SL needs attention. Whats there works, but not in the most optimal fashion. Right now, as has been mentioned, unsubscribe / subscribe is UDP and will probably need to remain that way since UDP as asynchronous and TCP is not - if object updates are coming via UDP (and they need to, trust me on this. Go dig out the TCP version of Doom and seeing what the does :) ) then the "Client, you need to know about this object" needs to be UDP to be sure it gets there first - at least attempting to, since UDP isn't guaranteed delivery. Generally there are approaches that will work for this kind of thing - if the client receives an update for an object it doesn't know about yet, it can just ignore that update, unless it's enough to actually construct a complete object on the client side in which case it should do that. Generally though you don't get enough in an update packet since it's mostly deltas from an known state, not a complete state for an object, so construction is less likely an option. There are mechanisms we can put into place whereby the sim sends a 'subscribe' notice to the client, indicating a new object of interest has entered the list of objects for this particular client, and can do that via UDP. And it will continue to do that, sending down a complete state until such time as the client acks this and says "Yes, I know there's a new object here, thanks" which it can do simply by acking the packet it received with that new objects information with in it. Then the sim 'knows' the client has that object and it can start sending just updates instead. You do the same thing for unsubscribing - the sim continues to send updates for a given object, as well as a "you are done with this object" message, until the client acknowledges it got it, in which case the object is just removed on the sim side and not considered again until it comes back into view. There are some other things we can do as well in terms of the object update packets - Object Update packets should be mostly just deltas from a known state that the sim and client agree on - e.g. the initial state that the sim sent down to the client, which the client acked. The sim now knows what the client has and will only send down information that has deviated from that state. If, every now and then, when you get a smaller packet constructed for sending down, you can insert a new 'complete state' for an object to pad it out, which once acked brings the client and sim states up to one that hopefully should have less deviation between them because it's 'newer'. Further to this there are other things to be tried, like not sending positional updates at all, but only sending velocity changes. If you send down a known state the client and sim have agreed on, then you don't need to send positional updates any more because the client and sim _should_ be in sync - all you need to do is send down velocity changes and the client and sim should remain in sync. Of course if packets are dropped, even though the velocity change is still being sent (and will be until the client acks it and the server says "Right, we are in sync right now") then this breaks some stuff since the client got the velocity change later than the sim started it, which means the dead reckoning position of the object is now wrong, but that's alleviated by the peridoric complete states being sent down. You can also send times on these packets and have the client re-interpret what the position should be given that the velocity change occured at time X (although this starts to involve some somewhat hairy code on the client side to make things match up). Simpler indeed, to just including a position when sending down a velocity change. You'd be surprised how effective that actually is - if you get to the point where so many packets are dropped that this become very apparent, then you are pretty much teetering on getting dumped anyway. Most of the time good enough is surprisingly low in terms of real time correction and so on, because nothing particularly heavy is done client side that relies on this - it's all just visualization, rather than collision requirements and so on. The moment you start doing physics on a client, all this suddenly becomes far more important. But for now, it's less so. Most of this is a known and solved problem; it's just time and resources that prevent us from looking at this immediately - that and the fact that while we see some artifacting now and again, it's not really something that destroys residents experience. Note - this isn't necessarily how SL works right now, just an ideal of what it might be nice to get to. In terms of why objects are subscribed and unsubscribed in the first place, there's also the factor of network bandwidth to consider alongside the issue of CPU usage on the Sim. If you don't remove those objects from the stream that are not considered within the clients perview (and not just frustrum perview as most FPS games have it - you need to be able to consider objects behind you to ensure you get sounds, particles that overlap your view and so on) then it doesn't take long before your stream is *full* of objects you can't see, don't care about and yet are getting updates for you don't need. Moving some of this to the client is a definite possibility - however there are implications to that. It enables people to ask the sim for information about objects they can't see in an attempt to cheat at games, and generally see stuff they don't have the permissions to see, plus timing suddenly becomes that much more important. Realistically the Sim has to be the final arbiter of what it sends for several reasons - network bandwidth (you may have extra bandwidth to receive more data, but the sim doesn't necessarily have the bandwidth to be sending it out, given it's sending out these streams of updates to gobs of clients, not just yours), clients seeing what they need to see and no more, and the sim owning what you can see. Jake John Hurliman wrote: > Tateru Nino wrote: >> John Hurliman wrote: >> >>> Tateru Nino wrote: >>> >>>> Dale Glass wrote: >>>> >>>> >>>>> On Thu, Jul 19, 2007 at 01:38:02AM +1000, Tateru Nino wrote: >>>>> >>>>>> Considering the amount of ghosting we generally see (due to lost >>>>>> ObjectKill packets), I'm wondering if it isn't a good idea for the >>>>>> viewer to be able to periodically poll 'stale' objects (ones that >>>>>> have >>>>>> had no Update for a while) just to verify that they're still >>>>>> present. >>>>>> Having avatars and objects that have long since gone hang around in >>>>>> your >>>>>> viewer for an hour or two - that can be a little odd, or even >>>>>> unsettling >>>>>> at times. >>>>>> >>>>> That sounds like a hack. >>>>> >>>>> ObjectKill is sent over UDP, I suppose? I haven't looked at >>>>> networking >>>>> code much yet. But if so, polling isn't the right way to do it, the >>>>> problem is that the message should be reliable and isn't. So move >>>>> it to >>>>> TCP, ensuring it's always delivered. Then so long the sim and viewer >>>>> aren't buggy that should be all that's needed. >>>>> >>>>> Imagine the amount of extra bandwidth needed for periodically >>>>> checking >>>>> all the objects you can see if you set draw distance to 512M. >>>>> >>>>> >>>> Many of our most common complaints are caused by dropped messages that >>>> should be reliable, but aren't. :) >>>> >>> Isn't ObjectKill sent as "Reliable"? If there is a problem with the >>> ACKing code that's a whole different story, and if the connection >>> quality is poor enough that packets are being given up on after the >>> minimum five resends or whatever it is then switching to TCP probably >>> won't fix the connection. >> There seem to be some things going missing, and I've started to look a >> little more closely at the messaging code to try to figure out why. >> Symptoms suggest that messages are not turning up at all (avatar >> standing up, avatar departing, object removed from simulation, etc) or >> are having their parameters zeroed out or mangled somehow (avatar >> position, appearance, attachment position). >> >> In recent days I've been starting to wonder if it is possible for the >> parameters for one message to be incorrectly interpreted as being part >> of an earlier message whose parameters may have been dropped in transit >> somewhere, or if there is a data-path with degenerate encoding/decoding >> behaviour. >> >> Time to UTSL, and see what can be seen. >> > > One thing we found while developing libsecondlife is that out of order > packets can sometimes produce the same behavior as a dropped packet. > For example, if someone stands up then sits down again quickly and > then sit down packet is handled before the stand up packet, the avatar > will appear to be standing over the new target. The only solution we > could think up was holding out of order packets in a processing queue > and replaying them, which didn't seem like an acceptable solution as > it would effectively lock up the network stream every time things were > handled out of order. Not saying that is what is going on there but > it's another angle to consider. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From seg at haxxed.com Thu Jul 19 02:09:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 02:12:17 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <469D0983.8040901@lindenlab.com> References: <1184620013.26499.21.camel@localhost.localdomain> <469D0983.8040901@lindenlab.com> Message-ID: <1184836148.31185.141.camel@localhost.localdomain> On Tue, 2007-07-17 at 19:25 +0100, Tofu Linden wrote: > I've used liboil in the past - it's pretty cool. I seem to > recall that it was fairly painful to package, though, if not > anticipating relying upon a system-installed one. It's also > quite large (another packaging concern). Large? Its 516kb on x86_64, which is a bit larger than I'd expect from looking at the source. Not particularly large compared to the secondlife binary itself, 24mb(!). But larger than OpenJPEG (119kb), and Debris (177k). http://www.pouet.net/prod.php?which=30244 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/f615229b/attachment.pgp From Dana.Fagerstrom at Sun.COM Thu Jul 19 07:25:06 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Jul 19 07:23:42 2007 Subject: [sldev] compressed maps? Message-ID: <469F7442.60903@sun.com> Before I go opening any new Jira "tickets" I'd like to know if anyone else is finding maps compressed to the top left quadrant of each sim rectangle on the in-world Map. I'm seeing this behavior with version 1.18.0.4. I reviewed the open jira tickets and didn't see it mentioned. But before I open a ticket I'd like to know if anyone else is seeing this. I just want to make sure it's not just my build. Thanks, D From dale at daleglass.net Thu Jul 19 07:33:40 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 19 07:33:45 2007 Subject: [sldev] compressed maps? In-Reply-To: <469F7442.60903@sun.com> References: <469F7442.60903@sun.com> Message-ID: <20070719143340.GA21466@bruno.sbruno> On Thu, Jul 19, 2007 at 10:25:06AM -0400, Dana Fagerstrom wrote: > Before I go opening any new Jira "tickets" I'd like to know if anyone > else is finding maps compressed to the top left quadrant of each sim > rectangle on the in-world Map. I'm seeing this behavior with version > 1.18.0.4. Yep, I've noticed this recently in my build as well, but didn't report it because I wanted to try to investigate it a bit first. Unfortunately didn't have time. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/d0a2f18e/attachment.pgp From sllists at boroon.dasgupta.ch Thu Jul 19 07:40:02 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu Jul 19 07:40:15 2007 Subject: [sldev] compressed maps? In-Reply-To: <469F7442.60903@sun.com> References: <469F7442.60903@sun.com> Message-ID: <20070719164002.dv12jii5wckkos0o@datendelphin.net> Zitat von Dana Fagerstrom : > Before I go opening any new Jira "tickets" I'd like to know if anyone > else is finding maps compressed to the top left quadrant of each sim > rectangle on the in-world Map.? I'm seeing this behavior with version > 1.18.0.4. I don't see this in my current build (from 1.18.0.6 sources). Is it sprecific to 1.18.0.4? Or might it be dependant to what jpeg2k library is used? Boroondas ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/80ee3d6f/attachment.htm From Dana.Fagerstrom at Sun.COM Thu Jul 19 07:42:06 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Jul 19 07:40:41 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719143340.GA21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719143340.GA21466@bruno.sbruno> Message-ID: <469F783E.2070807@sun.com> Phew! I was thinking it was something in my Solaris port :) I'll open a ticket so we don't loose it. Thanks, D > On Thu, Jul 19, 2007 at 10:25:06AM -0400, Dana Fagerstrom wrote: >> Before I go opening any new Jira "tickets" I'd like to know if anyone >> else is finding maps compressed to the top left quadrant of each sim >> rectangle on the in-world Map. I'm seeing this behavior with version >> 1.18.0.4. > > Yep, I've noticed this recently in my build as well, but didn't report > it because I wanted to try to investigate it a bit first. Unfortunately > didn't have time. From Dana.Fagerstrom at Sun.COM Thu Jul 19 07:49:39 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Jul 19 07:48:19 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719143340.GA21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719143340.GA21466@bruno.sbruno> Message-ID: <469F7A03.6080801@sun.com> http://jira.secondlife.com/browse/VWR-1815 Dale Glass wrote: > On Thu, Jul 19, 2007 at 10:25:06AM -0400, Dana Fagerstrom wrote: >> Before I go opening any new Jira "tickets" I'd like to know if anyone >> else is finding maps compressed to the top left quadrant of each sim >> rectangle on the in-world Map. I'm seeing this behavior with version >> 1.18.0.4. > > Yep, I've noticed this recently in my build as well, but didn't report > it because I wanted to try to investigate it a bit first. Unfortunately > didn't have time. From dale at daleglass.net Thu Jul 19 08:05:14 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 19 08:05:21 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719164002.dv12jii5wckkos0o@datendelphin.net> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> Message-ID: <20070719150514.GB21466@bruno.sbruno> On Thu, Jul 19, 2007 at 04:40:02PM +0200, Boroondas Gupte wrote: > I don't see this in my current build (from 1.18.0.6 sources). Is it > sprecific to 1.18.0.4? Or might it be dependant to what jpeg2k library > is used? 1.18.0.6. Using OpenJPEG, which could be the issue. OpenJPEG still seems to have remaining bugs. I only see it when the map is zoomed in nearly all the way. If you zoom out it looks fine. It looks like the higher res image is getting loaded, but drawn at 50% of the correct width and height. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/30f34250/attachment.pgp From dale at daleglass.net Thu Jul 19 08:06:42 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 19 08:06:48 2007 Subject: [sldev] compressed maps? In-Reply-To: <469F783E.2070807@sun.com> References: <469F7442.60903@sun.com> <20070719143340.GA21466@bruno.sbruno> <469F783E.2070807@sun.com> Message-ID: <20070719150642.GC21466@bruno.sbruno> On Thu, Jul 19, 2007 at 10:42:06AM -0400, Dana Fagerstrom wrote: > Phew! I was thinking it was something in my Solaris port :) > > I'll open a ticket so we don't loose it. Attached a screenshot to your ticket -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/c7fd9c81/attachment.pgp From dzonatas at dzonux.net Thu Jul 19 08:07:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 08:07:44 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719150514.GB21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> Message-ID: <469F7E49.1090602@dzonux.net> I'm using OpenJPEG with the 1.18.0.6 (kdu removed), and the map works fine -- actually better. Dale Glass wrote: > On Thu, Jul 19, 2007 at 04:40:02PM +0200, Boroondas Gupte wrote: > >> I don't see this in my current build (from 1.18.0.6 sources). Is it >> sprecific to 1.18.0.4? Or might it be dependant to what jpeg2k library >> is used? >> > 1.18.0.6. Using OpenJPEG, which could be the issue. OpenJPEG still seems > to have remaining bugs. > > I only see it when the map is zoomed in nearly all the way. If you zoom > out it looks fine. It looks like the higher res image is getting loaded, > but drawn at 50% of the correct width and height. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/8d9797e5/attachment.htm From dale at daleglass.net Thu Jul 19 08:10:19 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 19 08:10:24 2007 Subject: [sldev] compressed maps? In-Reply-To: <469F7E49.1090602@dzonux.net> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> Message-ID: <20070719151018.GD21466@bruno.sbruno> On Thu, Jul 19, 2007 at 08:07:53AM -0700, Dzonatas wrote: > I'm using OpenJPEG with the 1.18.0.6 (kdu removed), and the map works > fine -- actually better. Strange. I've seen some artifacts with OpenJPEG when uploading files (I think those have been on Jira for quite some time), but for the most part it works fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/f8f5811c/attachment.pgp From dzonatas at dzonux.net Thu Jul 19 08:15:13 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 08:15:06 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719151018.GD21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> Message-ID: <469F8001.3070005@dzonux.net> Let me know which ones, so that I can run ImageMagick's compare on them. Dale Glass wrote: > On Thu, Jul 19, 2007 at 08:07:53AM -0700, Dzonatas wrote: > >> I'm using OpenJPEG with the 1.18.0.6 (kdu removed), and the map works >> fine -- actually better. >> > > Strange. I've seen some artifacts with OpenJPEG when uploading files (I > think those have been on Jira for quite some time), but for the most > part it works fine. > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/de8677c0/attachment-0001.htm From dale at daleglass.net Thu Jul 19 08:35:21 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 19 08:35:26 2007 Subject: [sldev] compressed maps? In-Reply-To: <469F8001.3070005@dzonux.net> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> Message-ID: <20070719153521.GE21466@bruno.sbruno> On Thu, Jul 19, 2007 at 08:15:13AM -0700, Dzonatas wrote: > Let me know which ones, so that I can run ImageMagick's compare on them. > I have for example texture 5b9e9c17-f346-871e-8617-773335f5f3e2 To me it looks like this: http://daleglass.net/scanner_bad.tga This is very old, so I'm not sure if I remember the details right, but IIRC: Upload with openjpeg: Looks bad if seen with openjpeg, good with KDU upload with kdu: looks good with both -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/a6e0bb62/attachment.pgp From dzonatas at dzonux.net Thu Jul 19 09:15:28 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 09:15:21 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719153521.GE21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> Message-ID: <469F8E20.90806@dzonux.net> I think I was able to reproduce it, I resized the face/texture as it uncompressed, and it looked funky. Dale Glass wrote: > On Thu, Jul 19, 2007 at 08:15:13AM -0700, Dzonatas wrote: > >> Let me know which ones, so that I can run ImageMagick's compare on them. >> >> > I have for example texture 5b9e9c17-f346-871e-8617-773335f5f3e2 > > To me it looks like this: > http://daleglass.net/scanner_bad.tga > > This is very old, so I'm not sure if I remember the details right, but > IIRC: > > Upload with openjpeg: Looks bad if seen with openjpeg, good with KDU > upload with kdu: looks good with both > > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/764a8928/attachment.htm From dzonatas at dzonux.net Thu Jul 19 09:23:33 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 09:23:25 2007 Subject: [sldev] compressed maps? In-Reply-To: <469F8E20.90806@dzonux.net> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <469F8E20.90806@dzonux.net> Message-ID: <469F9005.4080109@dzonux.net> scratch that.. resize didn't have anything to do with it.... There was a fix posted to the OpenJPEG library; I'll check if that helps. Dzonatas wrote: > I think I was able to reproduce it, I resized the face/texture as it > uncompressed, and it looked funky. > > > > Dale Glass wrote: >> On Thu, Jul 19, 2007 at 08:15:13AM -0700, Dzonatas wrote: >> >>> Let me know which ones, so that I can run ImageMagick's compare on them. >>> >>> >> I have for example texture 5b9e9c17-f346-871e-8617-773335f5f3e2 >> >> To me it looks like this: >> http://daleglass.net/scanner_bad.tga >> >> This is very old, so I'm not sure if I remember the details right, but >> IIRC: >> >> Upload with openjpeg: Looks bad if seen with openjpeg, good with KDU >> upload with kdu: looks good with both >> >> >> > > -- > Power to Change the Void -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/36bb7215/attachment.htm From Dana.Fagerstrom at Sun.COM Thu Jul 19 09:25:03 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Jul 19 09:23:38 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719153521.GE21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> Message-ID: <469F905F.4080302@sun.com> Sorry folks I was sucked into another issue. Since we're talking Solaris I'm only using openjpeg 1.2. Thanks, D > On Thu, Jul 19, 2007 at 08:15:13AM -0700, Dzonatas wrote: >> Let me know which ones, so that I can run ImageMagick's compare on them. >> > I have for example texture 5b9e9c17-f346-871e-8617-773335f5f3e2 > > To me it looks like this: > http://daleglass.net/scanner_bad.tga > > This is very old, so I'm not sure if I remember the details right, but > IIRC: > > Upload with openjpeg: Looks bad if seen with openjpeg, good with KDU > upload with kdu: looks good with both > > > > > ------------------------------------------------------------------------ > From tofu.linden at lindenlab.com Thu Jul 19 11:10:55 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Jul 19 11:11:27 2007 Subject: [sldev] Wanted: Standard cross-platform library for CPU detection In-Reply-To: <1184836148.31185.141.camel@localhost.localdomain> References: <1184620013.26499.21.camel@localhost.localdomain> <469D0983.8040901@lindenlab.com> <1184836148.31185.141.camel@localhost.localdomain> Message-ID: <469FA92F.8070307@lindenlab.com> Callum Lerwick wrote: > On Tue, 2007-07-17 at 19:25 +0100, Tofu Linden wrote: >> I've used liboil in the past - it's pretty cool. I seem to >> recall that it was fairly painful to package, though, if not >> anticipating relying upon a system-installed one. It's also >> quite large (another packaging concern). > > Large? Its 516kb on x86_64, which is a bit larger than I'd expect from > looking at the source. Not particularly large compared to the secondlife > binary itself, 24mb(!). That's not bad - smaller than I remember - though it'd be cool if we were using liboil for more than just CPU detection to justify it. Any OSX users with experience of liboil's happiness there? -Tofu From seg at haxxed.com Thu Jul 19 11:31:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 11:34:26 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719153521.GE21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> Message-ID: <1184869868.25858.35.camel@localhost.localdomain> On Thu, 2007-07-19 at 17:35 +0200, Dale Glass wrote: > On Thu, Jul 19, 2007 at 08:15:13AM -0700, Dzonatas wrote: > > Let me know which ones, so that I can run ImageMagick's compare on them. > > > I have for example texture 5b9e9c17-f346-871e-8617-773335f5f3e2 > > To me it looks like this: > http://daleglass.net/scanner_bad.tga > > This is very old, so I'm not sure if I remember the details right, but > IIRC: > > Upload with openjpeg: Looks bad if seen with openjpeg, good with KDU > upload with kdu: looks good with both ABOUT TIME someone else noticed this! This has been a problem ever since the slviewer source was first released. For some reason, textures encoded with OpenJPEG, then decoded with OpenJPEG, come up with errors like that. Decoding with KDU, you don't see it. It seems to be related to the fact that its using lossless encoding. Everyone using OpenJPEG PLEASE use this patch: http://jira.secondlife.com/browse/VWR-1475 We don't need to be clogging up the grid with lossless images, unless they're sculpties. :) Using lossy encoding seems to fix all these issues. Which, IMHO, is a work around. The buggyness in lossless coding is still worrisome and should probably still be tracked down. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/5b8c4423/attachment.pgp From seg at haxxed.com Thu Jul 19 11:42:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 11:45:32 2007 Subject: [sldev] compressed maps? In-Reply-To: <1184869868.25858.35.camel@localhost.localdomain> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> Message-ID: <1184870538.25858.42.camel@localhost.localdomain> On Thu, 2007-07-19 at 13:31 -0500, Callum Lerwick wrote: > We don't need to be clogging up the grid with lossless images, unless > they're sculpties. :) Using lossy encoding seems to fix all these > issues. Which, IMHO, is a work around. The buggyness in lossless coding > is still worrisome and should probably still be tracked down. Oh I forgot to mention, its looking like wherever the map compression is happening, has (had?) switched over to OpenJPEG, with the broken encoder setup. :) I noticed this a few days ago, for some reason, encoding with OpenJPEG tends to result in very distinct red/blue color fringing, like the RGB channels are not lining up properly. This seems like a bug. And also an artifact of not enabling the MCT to encode in YUV format, though that may just be hiding a real bug. Screenshot on Jira. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/7f5d05b4/attachment.pgp From dale at daleglass.net Thu Jul 19 12:00:01 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Jul 19 12:02:15 2007 Subject: [sldev] compressed maps? In-Reply-To: <1184869868.25858.35.camel@localhost.localdomain> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> Message-ID: <20070719190001.GG21466@bruno.sbruno> On Thu, Jul 19, 2007 at 01:31:08PM -0500, Callum Lerwick wrote: > ABOUT TIME someone else noticed this! This has been a problem ever since > the slviewer source was first released. For some reason, textures > encoded with OpenJPEG, then decoded with OpenJPEG, come up with errors > like that. Decoding with KDU, you don't see it. Hmm, that's strange. I've noticed it precisely when the source was first released, more or less. But I think I saw it mentioned on jira somewhere, which is why I didn't send my own bug report. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/907b22ca/attachment.pgp From secret.argent at gmail.com Thu Jul 19 12:03:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jul 19 12:04:03 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <20070719065244.8717641AFB5@stupor.lindenlab.com> References: <20070719065244.8717641AFB5@stupor.lindenlab.com> Message-ID: <7BFFB2B7-ED5F-48DD-922F-14E1C45CE5C9@gmail.com> Lots of interesting information there, Jake. > Right now, as has been mentioned, unsubscribe / subscribe is UDP and > will probably need to remain that way since UDP as asynchronous and > TCP > is not - if object updates are coming via UDP (and they need to, trust > me on this. Seems to me that if you go through with the "informational" subscription mechanism, then the subscriptions could be sent TCP since if something like TCP congestion causes a late subscription that just means a later ACK. > Further to this there are other things to be tried, like not sending > positional updates at all, but only sending velocity changes. This approach would seem likely to make the existing problems with rubberbanding exponentially worse. Sending position updates less frequently, or only when you get a velocity change, OK. But I suspect you still need to send position updates more frequently than you're going to want to be sending full updates. > If you don't remove those > objects from the stream that are not considered within the clients > perview (and not just frustrum perview as most FPS games have it - you > need to be able to consider objects behind you to ensure you get > sounds, > particles that overlap your view and so on) then it doesn't take long > before your stream is *full* of objects you can't see, don't care > about > and yet are getting updates for you don't need. Absolutely. I was just thinking that the client is already doing most of the analysis anyway. What about this scheme? The client could send a kill for an object to the server when it gets an update on the object and it determines that it's out of range. That way if the server "lost" a kill from the client, it would sync up quickly. > It enables people to ask the sim for > information about objects they can't see in an attempt to cheat at > games, and generally see stuff they don't have the permissions to see, Unless there's going to be some kind of genuine privacy scheme implemented in SL (which is another topic near and dear to my heart, but not one I'm going to go into now), I don't think there's much that the client can't see in the sim it's in. The longest diagonal in the building zone of a sim is 849 meters, which means that an agent at <128,128,384> with a draw distance of 512 can see any object in the sim. Worst case, you can see well over 50% of the volume of the sim from any point in the sim, and from a corner you can see well over 50% of the volume of four sims at once. I think the only consideration given to the "privacy" issues of this scheme are that a sim should kill objects for clients in sims more than two sims away. That's a *cheap* calculation, and more an optimization than anything else. From jhurliman at wsu.edu Thu Jul 19 12:09:22 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Jul 19 12:09:31 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <7BFFB2B7-ED5F-48DD-922F-14E1C45CE5C9@gmail.com> References: <20070719065244.8717641AFB5@stupor.lindenlab.com> <7BFFB2B7-ED5F-48DD-922F-14E1C45CE5C9@gmail.com> Message-ID: <469FB6E2.8000905@wsu.edu> Argent Stonecutter wrote: > > Unless there's going to be some kind of genuine privacy scheme > implemented in SL (which is another topic near and dear to my heart, > but not one I'm going to go into now), I don't think there's much that > the client can't see in the sim it's in. The longest diagonal in the > building zone of a sim is 849 meters, which means that an agent at > <128,128,384> with a draw distance of 512 can see any object in the > sim. Worst case, you can see well over 50% of the volume of the sim > from any point in the sim, and from a corner you can see well over 50% > of the volume of four sims at once. > > I think the only consideration given to the "privacy" issues of this > scheme are that a sim should kill objects for clients in sims more > than two sims away. That's a *cheap* calculation, and more an > optimization than anything else. You can actually have sim-culled privacy if you have a large enough plot with ban lines and build everything very very small. The simulator won't send *everything* in your draw distance, it culls small enough objects that are far away enough from your avatar, putting a damper on implementing good pathfinding code in libsecondlife. From dzonatas at dzonux.net Thu Jul 19 12:21:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 12:21:11 2007 Subject: [sldev] compressed maps? In-Reply-To: <20070719190001.GG21466@bruno.sbruno> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <20070719190001.GG21466@bruno.sbruno> Message-ID: <469FB9B0.1010601@dzonux.net> I was aware of a bug but only had loose data to go by a couple months ago. There is enough data evidence now to suggest that it is not directly DWT related but doesn't rule it out. Maybe a loop somewhere that ends short. Dale Glass wrote: > On Thu, Jul 19, 2007 at 01:31:08PM -0500, Callum Lerwick wrote: > >> ABOUT TIME someone else noticed this! This has been a problem ever since >> the slviewer source was first released. For some reason, textures >> encoded with OpenJPEG, then decoded with OpenJPEG, come up with errors >> like that. Decoding with KDU, you don't see it. >> > Hmm, that's strange. > > I've noticed it precisely when the source was first released, more or > less. But I think I saw it mentioned on jira somewhere, which is why I > didn't send my own bug report. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/6162e552/attachment.htm From Dana.Fagerstrom at Sun.COM Thu Jul 19 12:55:00 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Jul 19 12:53:35 2007 Subject: [sldev] compressed maps? In-Reply-To: <1184869868.25858.35.camel@localhost.localdomain> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> Message-ID: <469FC194.3090203@sun.com> Callum, I tried your patch and set OpenJPEGEncodeLossless to both to both true and false with no change. I attached a screenshot to my issue, http://jira.secondlife.com/browse/VWR-1815, to be sure folks can see it. That screenshot is with the patch for VWR-1475 and OpenJPEGEncodeLossless set to true. If I can get some of my other work finished, I'll dive in and see what I can find. Thanks, D Callum Lerwick wrote: > On Thu, 2007-07-19 at 17:35 +0200, Dale Glass wrote: >> On Thu, Jul 19, 2007 at 08:15:13AM -0700, Dzonatas wrote: >>> Let me know which ones, so that I can run ImageMagick's compare on them. >>> >> I have for example texture 5b9e9c17-f346-871e-8617-773335f5f3e2 >> >> To me it looks like this: >> http://daleglass.net/scanner_bad.tga >> >> This is very old, so I'm not sure if I remember the details right, but >> IIRC: >> >> Upload with openjpeg: Looks bad if seen with openjpeg, good with KDU >> upload with kdu: looks good with both > > ABOUT TIME someone else noticed this! This has been a problem ever since > the slviewer source was first released. For some reason, textures > encoded with OpenJPEG, then decoded with OpenJPEG, come up with errors > like that. Decoding with KDU, you don't see it. > > It seems to be related to the fact that its using lossless encoding. > Everyone using OpenJPEG PLEASE use this patch: > > http://jira.secondlife.com/browse/VWR-1475 > > We don't need to be clogging up the grid with lossless images, unless > they're sculpties. :) Using lossy encoding seems to fix all these > issues. Which, IMHO, is a work around. The buggyness in lossless coding > is still worrisome and should probably still be tracked down. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- ===================================================================== Dana Fagerstrom Phone: 877.851.6343 Sun Services Fax: 877.851.6343 400 Atrium Dr. Email: dana.fagerstrom@Sun.COM Somerset, NJ 08873 SneakerNet: USMT01 ===================================================================== Pressure - It can turn a lump of coal into a flawless diamond, and an average person into a perfect basketcase. -- www.despair.com ===================================================================== From dzonatas at dzonux.net Thu Jul 19 12:54:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 12:54:00 2007 Subject: [sldev] Sandbox viewer not working on Vista Message-ID: <469FC161.9000609@dzonux.net> I got reports that the Sandbox viewer doesn't work on Vista. Can someone with Vista confirm this, please? If so, what can be different to cause that? http://sourceforge.net/project/showfiles.php?group_id=191214 -- Power to Change the Void From seg at haxxed.com Thu Jul 19 12:56:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 12:59:30 2007 Subject: [sldev] compressed maps? In-Reply-To: <469FB9B0.1010601@dzonux.net> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <20070719190001.GG21466@bruno.sbruno> <469FB9B0.1010601@dzonux.net> Message-ID: <1184874969.25858.57.camel@localhost.localdomain> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/c8af1490/attachment.pgp From seg at haxxed.com Thu Jul 19 13:00:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 13:04:08 2007 Subject: [sldev] compressed maps? In-Reply-To: <469FC194.3090203@sun.com> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <469FC194.3090203@sun.com> Message-ID: <1184875253.25858.60.camel@localhost.localdomain> On Thu, 2007-07-19 at 15:55 -0400, Dana Fagerstrom wrote: > Callum, > > I tried your patch and set OpenJPEGEncodeLossless to both to both true > and false with no change. I attached a screenshot to my issue, > http://jira.secondlife.com/browse/VWR-1815, to be sure folks can see it. > That screenshot is with the patch for VWR-1475 and > OpenJPEGEncodeLossless set to true. VWR-1475 only effects encoding. To fix the map, someone has to apply VWR-1475 to the backend map generator and re-encode everything. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/aa1ec8fa/attachment-0001.pgp From seg at haxxed.com Thu Jul 19 13:10:41 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 13:13:55 2007 Subject: [sldev] compressed maps? In-Reply-To: <1184870538.25858.42.camel@localhost.localdomain> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <1184870538.25858.42.camel@localhost.localdomain> Message-ID: <1184875841.25858.66.camel@localhost.localdomain> On Thu, 2007-07-19 at 13:42 -0500, Callum Lerwick wrote: > Oh I forgot to mention, its looking like wherever the map compression is > happening, has (had?) switched over to OpenJPEG, with the broken encoder > setup. :) > > I noticed this a few days ago, for some reason, encoding with OpenJPEG > tends to result in very distinct red/blue color fringing, like the RGB > channels are not lining up properly. That should have been "I noticed this a few days ago, you can tell because..." Strangely, I wasn't getting the blue/yellow half size thing until today. Which is why I haven't gotten around to Jira-ing this before, just when I think I've nailed down the nature of the bug, it does something different. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/ec7b4047/attachment.pgp From robla at lindenlab.com Thu Jul 19 13:22:38 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 19 13:22:48 2007 Subject: [sldev] compressed maps? In-Reply-To: <1184875841.25858.66.camel@localhost.localdomain> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <1184870538.25858.42.camel@localhost.localdomain> <1184875841.25858.66.camel@localhost.localdomain> Message-ID: <469FC80E.4080906@lindenlab.com> Could everyone redirect this conversation to JIRA? https://jira.secondlife.com/browse/VWR-1475 It'll be much useful to have all of this info aggregated in the JIRA task rather than on the mailing list. Thanks Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/b03e5238/signature.pgp From seg at haxxed.com Thu Jul 19 13:21:25 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 13:24:40 2007 Subject: [sldev] compressed maps? In-Reply-To: <1184874969.25858.57.camel@localhost.localdomain> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <20070719190001.GG21466@bruno.sbruno> <469FB9B0.1010601@dzonux.net> <1184874969.25858.57.camel@localhost.localdomain> Message-ID: <1184876485.25858.74.camel@localhost.localdomain> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/51d32841/attachment.pgp From seg at haxxed.com Thu Jul 19 13:38:28 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 13:41:44 2007 Subject: [sldev] compressed maps? In-Reply-To: <469FC80E.4080906@lindenlab.com> References: <469F7442.60903@sun.com> <20070719164002.dv12jii5wckkos0o@datendelphin.net> <20070719150514.GB21466@bruno.sbruno> <469F7E49.1090602@dzonux.net> <20070719151018.GD21466@bruno.sbruno> <469F8001.3070005@dzonux.net> <20070719153521.GE21466@bruno.sbruno> <1184869868.25858.35.camel@localhost.localdomain> <1184870538.25858.42.camel@localhost.localdomain> <1184875841.25858.66.camel@localhost.localdomain> <469FC80E.4080906@lindenlab.com> Message-ID: <1184877508.25858.80.camel@localhost.localdomain> On Thu, 2007-07-19 at 13:22 -0700, Rob Lanphier wrote: > Could everyone redirect this conversation to JIRA? > https://jira.secondlife.com/browse/VWR-1475 > > It'll be much useful to have all of this info aggregated in the JIRA > task rather than on the mailing list. I'd rather people used VWR-1815 for this, I'd like to direct 1475 toward implementing lossless coding for sculpt maps. I consider it more of a side effect that it happens to fix VWR-1815. Its a work around, lossless coding is still broken. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/adbf346a/attachment.pgp From jake at lindenlab.com Thu Jul 19 14:18:28 2007 From: jake at lindenlab.com (Jake Simpson) Date: Thu Jul 19 14:18:47 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <7BFFB2B7-ED5F-48DD-922F-14E1C45CE5C9@gmail.com> References: <20070719065244.8717641AFB5@stupor.lindenlab.com> <7BFFB2B7-ED5F-48DD-922F-14E1C45CE5C9@gmail.com> Message-ID: <469FD524.3060909@lindenlab.com> Argent Stonecutter wrote: > Lots of interesting information there, Jake. > >> Right now, as has been mentioned, unsubscribe / subscribe is UDP and >> will probably need to remain that way since UDP as asynchronous and TCP >> is not - if object updates are coming via UDP (and they need to, trust >> me on this. > > Seems to me that if you go through with the "informational" > subscription mechanism, then the subscriptions could be sent TCP since > if something like TCP congestion causes a late subscription that just > means a later ACK. > >> Further to this there are other things to be tried, like not sending >> positional updates at all, but only sending velocity changes. > > This approach would seem likely to make the existing problems with > rubberbanding exponentially worse. > What issues specifically do you mean? I totally believe they are there, just trying to get a feel for what you guys feel they are? > Sending position updates less frequently, or only when you get a > velocity change, OK. But I suspect you still need to send position > updates more frequently than you're going to want to be sending full > updates. > >> If you don't remove those >> objects from the stream that are not considered within the clients >> perview (and not just frustrum perview as most FPS games have it - you >> need to be able to consider objects behind you to ensure you get sounds, >> particles that overlap your view and so on) then it doesn't take long >> before your stream is *full* of objects you can't see, don't care about >> and yet are getting updates for you don't need. > > Absolutely. I was just thinking that the client is already doing most > of the analysis anyway. > > What about this scheme? The client could send a kill for an object to > the server when it gets an update on the object and it determines that > it's out of range. That way if the server "lost" a kill from the > client, it would sync up quickly. > That might well work. Definitely worth investigating. I would just be concerned that if that was the only way an object is removed from the update stream then someone with a hacked client could then just sit in a sim and slowly start eating all the network bandwidth because they never send back a Kill message. Griefing, unfortunately, is something we have to consider which is why I more prefer to keep this sim side than not. >> It enables people to ask the sim for >> information about objects they can't see in an attempt to cheat at >> games, and generally see stuff they don't have the permissions to see, > > Unless there's going to be some kind of genuine privacy scheme > implemented in SL (which is another topic near and dear to my heart, > but not one I'm going to go into now), I don't think there's much that > the client can't see in the sim it's in. The longest diagonal in the > building zone of a sim is 849 meters, which means that an agent at > <128,128,384> with a draw distance of 512 can see any object in the > sim. Worst case, you can see well over 50% of the volume of the sim > from any point in the sim, and from a corner you can see well over 50% > of the volume of four sims at once. > > I think the only consideration given to the "privacy" issues of this > scheme are that a sim should kill objects for clients in sims more > than two sims away. That's a *cheap* calculation, and more an > optimization than anything else. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Thu Jul 19 14:47:15 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 19 14:47:22 2007 Subject: [sldev] Smily Raymaker live for the first time in meatspace. Message-ID: <469FDBE3.5070004@blueflash.cc> Nice typo :-) http://blog.secondlife.com/2007/07/19/brighton-rocks/ -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From secret.argent at gmail.com Thu Jul 19 14:51:13 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jul 19 14:51:19 2007 Subject: [sldev] Why does the simulator do object culling for clients? In-Reply-To: <469FD524.3060909@lindenlab.com> References: <20070719065244.8717641AFB5@stupor.lindenlab.com> <7BFFB2B7-ED5F-48DD-922F-14E1C45CE5C9@gmail.com> <469FD524.3060909@lindenlab.com> Message-ID: <13254B16-1CC8-4367-8CE9-070338810C2C@gmail.com> On 19-Jul-2007, at 16:18, Jake Simpson wrote: >> This approach would seem likely to make the existing problems with >> rubberbanding exponentially worse. > What issues specifically do you mean? I totally believe they are > there, just trying to get a feel for what you guys feel they are? Moving around in SL it's really common, even when there's only minor lag, for both position and velocity to get badly out of sync, resulting in snapback (rubberbanding) as you move around. Packet loss makes this much worse, and it's not unknown to have rubberbanding every few seconds. If you don't get position updates, the accumulated errors are going to have more time to build up. From seg at haxxed.com Thu Jul 19 15:25:14 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 15:28:36 2007 Subject: [sldev] Smily Raymaker live for the first time in meatspace. In-Reply-To: <469FDBE3.5070004@blueflash.cc> References: <469FDBE3.5070004@blueflash.cc> Message-ID: <1184883914.25858.93.camel@localhost.localdomain> On Thu, 2007-07-19 at 23:47 +0200, Nicholaz Beresford wrote: > Nice typo :-) > > http://blog.secondlife.com/2007/07/19/brighton-rocks/ Typo? http://en.wikipedia.org/wiki/Meatspace http://www.catb.org/~esr/jargon/html/M/meatspace.html Hint: YOU ARE MADE OF MEAT -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/729b30c5/attachment.pgp From robla at lindenlab.com Thu Jul 19 15:39:39 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 19 15:41:41 2007 Subject: [sldev] Partial downtime on wiki and jira tomorrow Message-ID: <469FE82B.9030702@lindenlab.com> Hi all, We're going to have some downtime tomorrow, Friday, July 20, within the maintenance window of 1pm-4pm PDT as some updates are done on wiki.secondlife.com and jira.secondlife.com. There won't be a solid outage during this time, but both services will be down for multiple, small periods of time during this period. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/4ac9f836/signature-0001.pgp From morris1 at ix.netcom.com Thu Jul 19 15:39:14 2007 From: morris1 at ix.netcom.com (morris) Date: Thu Jul 19 16:06:48 2007 Subject: [sldev] Sandbox viewer not working on Vista In-Reply-To: <469FC161.9000609@dzonux.net> References: <469FC161.9000609@dzonux.net> Message-ID: <200707191539.14159.morris1@ix.netcom.com> I tried the Sandbox version on my Vista system and it won't even start up, fails immediately. This is a dual-core P4 with nVidia 7950 card. Need any other information? Morris Ford On Thursday 19 July 2007 12:54, Dzonatas wrote: > I got reports that the Sandbox viewer doesn't work on Vista. Can someone > with Vista confirm this, please? > > If so, what can be different to cause that? > > http://sourceforge.net/project/showfiles.php?group_id=191214 From able.whitman at gmail.com Thu Jul 19 16:11:52 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 19 16:11:54 2007 Subject: [sldev] Sandbox viewer not working on Vista In-Reply-To: <200707191539.14159.morris1@ix.netcom.com> References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> Message-ID: <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> Could you try launching it with "-log" and post a reply with any log file that's generated? On 7/19/07, morris wrote: > > I tried the Sandbox version on my Vista system and it won't even start up, > fails immediately. This is a dual-core P4 with nVidia 7950 card. Need any > other information? > Morris Ford > > On Thursday 19 July 2007 12:54, Dzonatas wrote: > > I got reports that the Sandbox viewer doesn't work on Vista. Can someone > > with Vista confirm this, please? > > > > If so, what can be different to cause that? > > > > http://sourceforge.net/project/showfiles.php?group_id=191214 > _______________________________________________ > 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/20070719/1b112880/attachment.htm From dzonatas at dzonux.net Thu Jul 19 18:15:34 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 18:15:24 2007 Subject: [sldev] Sandbox viewer not working on Vista In-Reply-To: <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> Message-ID: <46A00CB6.9010204@dzonux.net> This may be FMOD related. I found notes about the older API/driver interface as known to have problems on Vista. Able Whitman wrote: > Could you try launching it with "-log" and post a reply with any log > file that's generated? > > On 7/19/07, *morris* < morris1@ix.netcom.com > > wrote: > > I tried the Sandbox version on my Vista system and it won't even > start up, > fails immediately. This is a dual-core P4 with nVidia 7950 card. > Need any > other information? > Morris Ford > > On Thursday 19 July 2007 12:54, Dzonatas wrote: > > I got reports that the Sandbox viewer doesn't work on Vista. Can > someone > > with Vista confirm this, please? > > > > If so, what can be different to cause that? > > > > http://sourceforge.net/project/showfiles.php?group_id=191214 > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/41593b07/attachment.htm From seg at haxxed.com Thu Jul 19 19:09:34 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jul 19 19:13:02 2007 Subject: [sldev] Sandbox viewer not working on Vista In-Reply-To: <46A00CB6.9010204@dzonux.net> References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> <46A00CB6.9010204@dzonux.net> Message-ID: <1184897374.25858.96.camel@localhost.localdomain> On Thu, 2007-07-19 at 18:15 -0700, Dzonatas wrote: > This may be FMOD related. I found notes about the older API/driver > interface as known to have problems on Vista. Perhaps now would be the time to test my OpenAL patch on Windows. :) http://www.haxxed.com/code/slviewer-1.17.1.0-openal-20070703.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/30f5077a/attachment.pgp From dzonatas at dzonux.net Thu Jul 19 19:14:02 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 19 19:13:52 2007 Subject: Solved. Re: [sldev] Sandbox viewer not working on Vista In-Reply-To: <46A00CB6.9010204@dzonux.net> References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> <46A00CB6.9010204@dzonux.net> Message-ID: <46A01A6A.70500@dzonux.net> It is STL related, instead. This means builds between VS7.1 and VS8.0 can't share the same libraries as they have been if we use Microsoft's MFC/STL version. There are incompatibilities in the way strings are passed between libraries. This is a quick note, and I know it leaves a lot of questions still. Dzonatas wrote: > This may be FMOD related. I found notes about the older API/driver > interface as known to have problems on Vista. > > Able Whitman wrote: >> Could you try launching it with "-log" and post a reply with any log >> file that's generated? >> >> On 7/19/07, *morris* < morris1@ix.netcom.com >> > wrote: >> >> I tried the Sandbox version on my Vista system and it won't even >> start up, >> fails immediately. This is a dual-core P4 with nVidia 7950 card. >> Need any >> other information? >> Morris Ford >> >> On Thursday 19 July 2007 12:54, Dzonatas wrote: >> > I got reports that the Sandbox viewer doesn't work on Vista. >> Can someone >> > with Vista confirm this, please? >> > >> > If so, what can be different to cause that? >> > >> > http://sourceforge.net/project/showfiles.php?group_id=191214 >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > -- > Power to Change the Void > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/8d20dd8f/attachment.htm From hawk.carter at unix-dev.de Thu Jul 19 19:54:49 2007 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Thu Jul 19 19:55:01 2007 Subject: Solved. Re: [sldev] Sandbox viewer not working on Vista References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com><46A00CB6.9010204@dzonux.net> <46A01A6A.70500@dzonux.net> Message-ID: <006601c7ca79$56baba40$0301a8c0@main1> Thats why MS is releasing VS 9 "Orca" soon, VS8 neighter VS7 are really compatible to Vista`s and the media blackboxing (DMCA) which is there completly new. (remember that MS has switched off hardware Audio/Video(creative labs is still pissed) in Vista completly and that all things are running on/over DX10). All in all thats why i dont use Vista in any manner as long xp will be supported (Service Pack 3 will be released soonish too). Hawk From able.whitman at gmail.com Thu Jul 19 20:07:30 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 19 20:07:33 2007 Subject: Solved. Re: [sldev] Sandbox viewer not working on Vista In-Reply-To: <006601c7ca79$56baba40$0301a8c0@main1> References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> <46A00CB6.9010204@dzonux.net> <46A01A6A.70500@dzonux.net> <006601c7ca79$56baba40$0301a8c0@main1> Message-ID: <7b3a84fb0707192007u8e5e3a5xe106fb24f52c5c39@mail.gmail.com> Actually, the problem Dzonatas found is unrelated to the Orcas release of VS. Neither VS7.1 nor VS8 are fundamentally incompatible with Vista; you can use either one under Vista to build and debug projects, and the executables you produce will run just fine on any supported target platform. The incompatibilities that exist between Vista and VS7.1 / VS8 are related to Vista's UAC features and how they interact with VS's debugging facilities and software deployment (like One-Click, etc.). This is why MS released a Vista compatibility update for VS8, to help work around those problems. And none of this stuff is really related to the "trusted media path" stuff that's baked into the Vista kernel; that stuff comes into play when you're dealing with DRM/HDCP/etc. protected media. The purpose of the Orcas release is to bake the "Vista compatibility" fixes into VS without needing a service pack, and to support new technologies that ship with v3.0 of the .NET framework, like Avalon / WPF and Indigo / WCF (or whatever they're called nowadays). On 7/19/07, Hawk Carter wrote: > > Thats why MS is releasing VS 9 "Orca" soon, VS8 neighter VS7 are really > compatible to Vista`s and the media blackboxing (DMCA) which is there > completly new. (remember that MS has switched off hardware > Audio/Video(creative labs is still pissed) in Vista completly and that all > things are running on/over DX10). > > All in all thats why i dont use Vista in any manner as long xp will be > supported (Service Pack 3 will be released soonish too). > > > Hawk > > > _______________________________________________ > 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/20070719/16ce4cb3/attachment-0001.htm From able.whitman at gmail.com Thu Jul 19 20:26:18 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jul 19 20:26:20 2007 Subject: [sldev] Getting a community/sandbox area in the SL SVN repository? Message-ID: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> At the Open Source meeting today ( https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-07-19), there was talk of getting a sandbox / community / insert-label-here area on svn.secondlife.com, along with giving folks with signed source contribution agreements SVN access to the repository. I think this is a great idea--and it seemed like the general consensus was extremely positive--so I'm curious if there's a timeline for putting something like this together. The reason I'm asking is that right now we've got a few people providing their own viewer distributions (me, Nicholaz, and Dale) with varying combinations of patches. And Dzonatas has been putting together a proper repository for the OS.1, .2, and .3 releases, which serve as a good testbed of all the community-submitted JIRA patches all in one big pot. And every different flavor of viewer has different installers, different branding changes, etc. It's great to give people the chance to test JIRA patches before they're integrated into the official viewer, but it's also a pretty fractious situation. Having a single recognized repository for integrating community-contributed patches helps simplify the problem of "what patches are where", it will make branding / icon / trademark changes easier to standardize, it will make it possible to have common installers for each platform, among other things. Plus as we've already seen with the recent Vista issue with OS.3, problems like providing libraries built against the right source with the right compiler (at least for Windows) are easier to solve when there's one place to go for build scripts and such. If getting set up with svn.secondlife.com is something that can happen in the fairly near future, that would be awesome. If it's going to take some time, then in the meantime I think it makes sense to use the repository Dzonatas has setup as a sort of stop-gap for the time being, if necessary. My concern is just that doing the work to get such a repository working and able to produce builds for each platform will require a good amount of work from a bunch of people. It would be really nice to know if it made sense to do that work now, or wait until svn.secondlife.com was available and do that work then. Cheers, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070719/330d1b49/attachment.htm From robla at lindenlab.com Thu Jul 19 21:35:35 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jul 19 21:36:58 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> Message-ID: <46A03B97.1010605@lindenlab.com> Alright, let's go for it. If you meet the following criteria, and you are interested in getting an SVN account on svn.secondlife.com, let me know: 1. You have a contribution agreement on file 2. You have at least one patch accepted into the viewer (you show up in doc/contributions.txt in the official builds) 3. You are widely recognized as an active and positive contributor by the community #3 is subjective. Basically, I want to make sure everyone working in this branch is comfortable working together, and that we're comfortable working with you. We want there to be some sort of track record. Note that svn write access is a privilege and not a right. We reserve the right not to give you access, and to yank your access for any reason. As far as actually distributing any official builds from this repository, that's TBD. Let's get a good routine for getting the code in, and then figure out a good routine for getting bits out. I've created a sandbox directory here: http://svn.secondlife.com/svn/linden/sandbox/ ...but nothing has gone in yet. I haven't yet created any actual branches. I'd like to make sure we use "svn copy" of an already checked in version of the code to serve as a base point for any new branches. It sounds like there's a few ideas for long-lived branches. Here's the guidelines I'd like to follow: 1. Only check things into linden/sandbox. The other areas are reserved for code pushed from the official repository 2. Let's get a consensus on the branch structure before we go nuts creating new branches 3. Only if a branch is going to be long lived should it be at the root of linden/sandbox . Everything else should go into a year-based directory (e.g. linden/sandbox/2007/throwaway) Rob On 7/19/07 8:26 PM, Able Whitman wrote: > At the Open Source meeting today > (https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-07-19 > ), > there was talk of getting a sandbox / community / insert-label-here > area on svn.secondlife.com , along with > giving folks with signed source contribution agreements SVN access to > the repository. > > I think this is a great idea--and it seemed like the general consensus > was extremely positive--so I'm curious if there's a timeline for > putting something like this together. > > The reason I'm asking is that right now we've got a few people > providing their own viewer distributions (me, Nicholaz, and Dale) with > varying combinations of patches. And Dzonatas has been putting > together a proper repository for the OS.1, .2, and .3 releases, which > serve as a good testbed of all the community-submitted JIRA patches > all in one big pot. And every different flavor of viewer has different > installers, different branding changes, etc. > > It's great to give people the chance to test JIRA patches before > they're integrated into the official viewer, but it's also a pretty > fractious situation. Having a single recognized repository for > integrating community-contributed patches helps simplify the problem > of "what patches are where", it will make branding / icon / trademark > changes easier to standardize, it will make it possible to have common > installers for each platform, among other things. Plus as we've > already seen with the recent Vista issue with OS.3, problems like > providing libraries built against the right source with the right > compiler (at least for Windows) are easier to solve when there's one > place to go for build scripts and such. > > If getting set up with svn.secondlife.com > is something that can happen in the fairly near future, that would be > awesome. If it's going to take some time, then in the meantime I think > it makes sense to use the repository Dzonatas has setup as a sort of > stop-gap for the time being, if necessary. My concern is just that > doing the work to get such a repository working and able to produce > builds for each platform will require a good amount of work from a > bunch of people. It would be really nice to know if it made sense to > do that work now, or wait until svn.secondlife.com > was available and do that work then. > > Cheers, > --Able > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070719/a671929b/signature.pgp From nicholaz at blueflash.cc Thu Jul 19 22:36:43 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 19 22:36:48 2007 Subject: [sldev] Smily Raymaker live for the first time in meatspace. In-Reply-To: <1184883914.25858.93.camel@localhost.localdomain> References: <469FDBE3.5070004@blueflash.cc> <1184883914.25858.93.camel@localhost.localdomain> Message-ID: <46A049EB.8000003@blueflash.cc> Ouch ... I guess sometimes I should turn on my brain before writing :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Callum Lerwick wrote: > On Thu, 2007-07-19 at 23:47 +0200, Nicholaz Beresford wrote: >> Nice typo :-) >> >> http://blog.secondlife.com/2007/07/19/brighton-rocks/ > > Typo? > > http://en.wikipedia.org/wiki/Meatspace > http://www.catb.org/~esr/jargon/html/M/meatspace.html > > Hint: YOU ARE MADE OF MEAT > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From okumoto at ucsd.edu Fri Jul 20 08:26:54 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Fri Jul 20 08:26:59 2007 Subject: [sldev] crash due to freeing invalid pointers on linux client during quit? Message-ID: <46A0D43E.3030300@ucsd.edu> Hi is anyone compiling the linux client from source and seeing crashes when you quit the client 1.18.0.6? It's happening everytime for me so there is a good chance I will be able to track it down soon. It looks like a double free, or an invalid pointer in the llimage library with a std::string object. Max (gdb) info reg eax 0x29273e4 43152356 ecx 0xbfa29baf -1079862353 edx 0xbfa2a727 -1079859417 ebx 0x293fff4 43253748 esp 0xbfa29b94 0xbfa29b94 ebp 0xbfa29bc4 0xbfa29bc4 esi 0x2 2 edi 0xb6b81f0 191594992 eip 0x286e79a 0x286e79a eflags 0x202 [ IF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) where #0 0x02862be6 in __libc_message () from /lib/libc.so.6 #1 0x0286e79a in free_check () from /lib/libc.so.6 #2 0x0286df55 in free () from /lib/libc.so.6 #3 0x0278c691 in operator delete () from /usr/lib/libstdc++.so.6 #4 0x0276924d in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6 #5 0x0068f090 in __tcf_1 () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:233 #6 0x0282fb09 in __cxa_finalize () from /lib/libc.so.6 #7 0x00688ca4 in __do_global_dtors_aux () from /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so #8 0x006cc6dc in _fini () from /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so #9 0x007ba5de in _dl_fini () from /lib/ld-linux.so.2 #10 0x0282f859 in exit () from /lib/libc.so.6 #11 0x02819df4 in __libc_start_main () from /lib/libc.so.6 #12 0x08069b31 in _start () (gdb) cont *** glibc detected *** /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin: free(): invalid pointer: 0x0b6b81f0 *** ======= Backtrace: ========= /lib/libc.so.6[0x286e79a] /lib/libc.so.6(cfree+0x35)[0x286df55] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x278c691] /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x276924d] /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x68f090] /lib/libc.so.6(__cxa_finalize+0xa9)[0x282fb09] /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x688ca4] /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x6cc6dc] /lib/ld-linux.so.2[0x7ba5de] /lib/libc.so.6(exit+0xe9)[0x282f859] /lib/libc.so.6(__libc_start_main+0xe4)[0x2819df4] /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin[0x8069b31] ======= Memory map: ======== From nicholaz at blueflash.cc Fri Jul 20 09:00:49 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 20 09:00:55 2007 Subject: [sldev] crash due to freeing invalid pointers on linux client during quit? In-Reply-To: <46A0D43E.3030300@ucsd.edu> References: <46A0D43E.3030300@ucsd.edu> Message-ID: <46A0DC31.6000208@blueflash.cc> I know that there is an issue with one of the buttons on the login screen accessing memory after it was freed (not sure if this is related though). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Max Okumoto wrote: > Hi is anyone compiling the linux client from source and seeing crashes > when you > quit the client 1.18.0.6? It's happening everytime for me so there is a > good chance > I will be able to track it down soon. > > It looks like a double free, or an invalid pointer in the llimage > library with a > std::string object. > > Max > > (gdb) info reg > eax 0x29273e4 43152356 > ecx 0xbfa29baf -1079862353 > edx 0xbfa2a727 -1079859417 > ebx 0x293fff4 43253748 > esp 0xbfa29b94 0xbfa29b94 > ebp 0xbfa29bc4 0xbfa29bc4 > esi 0x2 2 > edi 0xb6b81f0 191594992 > eip 0x286e79a 0x286e79a > eflags 0x202 [ IF ] > cs 0x73 115 > ss 0x7b 123 > ds 0x7b 123 > es 0x7b 123 > fs 0x0 0 > gs 0x33 51 > (gdb) where > #0 0x02862be6 in __libc_message () from /lib/libc.so.6 > #1 0x0286e79a in free_check () from /lib/libc.so.6 > #2 0x0286df55 in free () from /lib/libc.so.6 > #3 0x0278c691 in operator delete () from /usr/lib/libstdc++.so.6 > #4 0x0276924d in std::string::_Rep::_M_destroy () from > /usr/lib/libstdc++.so.6 > #5 0x0068f090 in __tcf_1 () > at > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:233 > > #6 0x0282fb09 in __cxa_finalize () from /lib/libc.so.6 > #7 0x00688ca4 in __do_global_dtors_aux () > from /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so > #8 0x006cc6dc in _fini () from > /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so > #9 0x007ba5de in _dl_fini () from /lib/ld-linux.so.2 > #10 0x0282f859 in exit () from /lib/libc.so.6 > #11 0x02819df4 in __libc_start_main () from /lib/libc.so.6 > #12 0x08069b31 in _start () > (gdb) cont > *** glibc detected *** > /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin: > free(): invalid pointer: 0x0b6b81f0 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x286e79a] > /lib/libc.so.6(cfree+0x35)[0x286df55] > /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x278c691] > /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x276924d] > /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x68f090] > /lib/libc.so.6(__cxa_finalize+0xa9)[0x282fb09] > /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x688ca4] > /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x6cc6dc] > /lib/ld-linux.so.2[0x7ba5de] > /lib/libc.so.6(exit+0xe9)[0x282f859] > /lib/libc.so.6(__libc_start_main+0xe4)[0x2819df4] > /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin[0x8069b31] > > ======= Memory map: ======== > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Fri Jul 20 09:01:58 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 20 09:02:05 2007 Subject: [sldev] VWR-1577 ... you can help :-) Message-ID: <46A0DC76.7050009@blueflash.cc> Feeling bored? On VWR-1577 https://jira.secondlife.com/browse/VWR-1577 there's a nice list of buglets and improvelets which seem suitable for open source coders. Enjoy! Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Fri Jul 20 10:00:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 10:00:38 2007 Subject: [sldev] crash due to freeing invalid pointers on linux client during quit? In-Reply-To: <46A0DC31.6000208@blueflash.cc> References: <46A0D43E.3030300@ucsd.edu> <46A0DC31.6000208@blueflash.cc> Message-ID: <46A0EA45.3000705@dzonux.net> I'm pretty sure that the use of coLinux along with the malloc tools you use will nail that down. =p http://colinux.wikia.com/wiki/Main_Page Nicholaz Beresford wrote: > > I know that there is an issue with one of the buttons > on the login screen accessing memory after it was freed > (not sure if this is related though). > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Max Okumoto wrote: >> Hi is anyone compiling the linux client from source and seeing >> crashes when you >> quit the client 1.18.0.6? It's happening everytime for me so there >> is a good chance >> I will be able to track it down soon. >> >> It looks like a double free, or an invalid pointer in the llimage >> library with a >> std::string object. >> >> Max >> >> (gdb) info reg >> eax 0x29273e4 43152356 >> ecx 0xbfa29baf -1079862353 >> edx 0xbfa2a727 -1079859417 >> ebx 0x293fff4 43253748 >> esp 0xbfa29b94 0xbfa29b94 >> ebp 0xbfa29bc4 0xbfa29bc4 >> esi 0x2 2 >> edi 0xb6b81f0 191594992 >> eip 0x286e79a 0x286e79a >> eflags 0x202 [ IF ] >> cs 0x73 115 >> ss 0x7b 123 >> ds 0x7b 123 >> es 0x7b 123 >> fs 0x0 0 >> gs 0x33 51 >> (gdb) where >> #0 0x02862be6 in __libc_message () from /lib/libc.so.6 >> #1 0x0286e79a in free_check () from /lib/libc.so.6 >> #2 0x0286df55 in free () from /lib/libc.so.6 >> #3 0x0278c691 in operator delete () from /usr/lib/libstdc++.so.6 >> #4 0x0276924d in std::string::_Rep::_M_destroy () from >> /usr/lib/libstdc++.so.6 >> #5 0x0068f090 in __tcf_1 () >> at >> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:233 >> >> #6 0x0282fb09 in __cxa_finalize () from /lib/libc.so.6 >> #7 0x00688ca4 in __do_global_dtors_aux () >> from /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so >> #8 0x006cc6dc in _fini () from >> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so >> #9 0x007ba5de in _dl_fini () from /lib/ld-linux.so.2 >> #10 0x0282f859 in exit () from /lib/libc.so.6 >> #11 0x02819df4 in __libc_start_main () from /lib/libc.so.6 >> #12 0x08069b31 in _start () >> (gdb) cont >> *** glibc detected *** >> /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin: >> free(): invalid pointer: 0x0b6b81f0 *** >> ======= Backtrace: ========= >> /lib/libc.so.6[0x286e79a] >> /lib/libc.so.6(cfree+0x35)[0x286df55] >> /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x278c691] >> /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x276924d] >> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x68f090] >> /lib/libc.so.6(__cxa_finalize+0xa9)[0x282fb09] >> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x688ca4] >> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x6cc6dc] >> /lib/ld-linux.so.2[0x7ba5de] >> /lib/libc.so.6(exit+0xe9)[0x282f859] >> /lib/libc.so.6(__libc_start_main+0xe4)[0x2819df4] >> /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin[0x8069b31] >> >> ======= Memory map: ======== >> >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From gigstaggart at gmail.com Fri Jul 20 10:01:51 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jul 20 10:01:58 2007 Subject: [sldev] 2 core changes? Message-ID: <46A0EA7F.1040702@gmail.com> It appears that in recent versions, the SL client is using a lot more CPU on multicore machines. The effect on performance seems to be strongly positive but it does have some quirks. Prior to this, when SL was on a desktop that I wasn't using, its CPU usage was near zero, now it uses about 100% of one CPU all the time, even when it's on a hidden desktop. When it is on screen, now it uses nearly 2 full CPUs, and the framerate seems to be very nice, about a 20% increase. Can anyone explain the design changes that lead to this new behavior? Whatever the "new" loop is doing, can it shut down when the rendering shuts down too, so that SL doesn't burn up electricity when I'm not looking at it? -Jason From hawk.carter at unix-dev.de Fri Jul 20 10:16:39 2007 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Fri Jul 20 10:16:52 2007 Subject: [sldev] svn from me Message-ID: <000901c7caf1$bcd73ce0$0301a8c0@main1> So some asked for the source, so i made an svn (pure svn..no http etc access) it includes : Dales Revesion 76 (base) + patches 18b from Nicholaz + Ables Mute Visibility svn://svn.unix-dev.de/branches/1_18 Test it :) use it , upload it to other svn`s :) hope i did all right with the svn and that all works Hawk. From iridium at lindenlab.com Fri Jul 20 10:17:47 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Fri Jul 20 10:17:51 2007 Subject: [sldev] UI Bug Triage Agenda is up! Message-ID: <46A0EE3B.7060907@lindenlab.com> As some of you have noticed (thanks to those of you, especially Nicholaz, who have commented and made changes already), the UI Bug Triage Agenda has been posted for our next meeting (Tuesday July 24, 2007). Feel free to make additions/changes. Also, feel free to take over the entire Agenda creating project, hehe. See you Tuesday, Iridium -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070720/33d5b8f4/attachment.htm From hawk.carter at unix-dev.de Fri Jul 20 10:19:19 2007 From: hawk.carter at unix-dev.de (Hawk Carter) Date: Fri Jul 20 10:19:20 2007 Subject: [sldev] svn from me References: <000901c7caf1$bcd73ce0$0301a8c0@main1> Message-ID: <001601c7caf2$1b78dab0$0301a8c0@main1> Ahh and, it works mostly only with VC++ 2005 and or Linuc Scons :) Hawk ----- Original Message ----- From: "Hawk Carter" To: Sent: Friday, July 20, 2007 7:16 PM Subject: [sldev] svn from me > So some asked for the source, so i made an svn (pure svn..no http etc > access) > > it includes : > > Dales Revesion 76 (base) > + patches 18b from Nicholaz > + Ables Mute Visibility > > svn://svn.unix-dev.de/branches/1_18 > > Test it :) use it , upload it to other svn`s :) > > hope i did all right with the svn and that all works > > > Hawk. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Fri Jul 20 10:29:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jul 20 10:33:23 2007 Subject: [sldev] crash due to freeing invalid pointers on linux client during quit? In-Reply-To: <46A0D43E.3030300@ucsd.edu> References: <46A0D43E.3030300@ucsd.edu> Message-ID: <1184952580.25858.100.camel@localhost.localdomain> On Fri, 2007-07-20 at 08:26 -0700, Max Okumoto wrote: > Hi is anyone compiling the linux client from source and seeing crashes > when you > quit the client 1.18.0.6? It's happening everytime for me so there is a > good chance > I will be able to track it down soon. > > It looks like a double free, or an invalid pointer in the llimage > library with a > std::string object. Not seeing any such thing here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070720/e5249ee3/attachment.pgp From Dana.Fagerstrom at Sun.COM Fri Jul 20 11:12:48 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Fri Jul 20 11:11:29 2007 Subject: [sldev] where's SCons getting the compiler string Message-ID: <46A0FB20.9020001@sun.com> This is more for Linux folks. I know most of you have never seen this because you only have one compiler installed on your build systems but ever since 1.17.0 I've been having trouble getting SCons to use the gcc_bin defined in my SConstruct file. Instead it insists on using the default compiler on Solaris, CC instead of g++. I opened an issue, http://jira.secondlife.com/browse/VWR-1831, in hopes that someone closer to SCons will have an idea as to what's happening. Note that I do not have a CC, CXX, or other compiler related variable defined in my bash shell so SCons can't be getting it from there. My workaround is to use the SConstruct from 1.16.0. Thanks, D From bos at lindenlab.com Fri Jul 20 11:17:26 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Jul 20 11:17:59 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <46A0FB20.9020001@sun.com> References: <46A0FB20.9020001@sun.com> Message-ID: <46A0FC36.3090909@lindenlab.com> Dana Fagerstrom wrote: > This is more for Linux folks. I know most of you have never seen this > because you only have one compiler installed on your build systems but > ever since 1.17.0 I've been having trouble getting SCons to use the > gcc_bin defined in my SConstruct file. Instead it insists on using the > default compiler on Solaris, CC instead of g++. Unfortunately, the guy who switched us over to SCons left the company several months ago. I'm probably the person who knows most about it now, and I don't know the answer to your question. I'm pretty sure you'll need to look at the SCons internals to figure it out. Good luck with that - the code is horrible :-( References: <46A0FB20.9020001@sun.com> <46A0FC36.3090909@lindenlab.com> Message-ID: <46A0FE44.6000502@sun.com> Hmmm... Do I even dare asking if people would like to switch to make? I recall seeing a "makefile" patch being offered a while back. Hey, I'm only asking :) I'm now studying the differences between the 1.16.0 and 1.18.0 SConstructs. The cause has to be a change in that file since I have not changed the version of SCons on my system. If I have to I'll dive into the SCons source - been there and you are right, it's UGLY. Thanks, D > Dana Fagerstrom wrote: >> This is more for Linux folks. I know most of you have never seen this >> because you only have one compiler installed on your build systems but >> ever since 1.17.0 I've been having trouble getting SCons to use the >> gcc_bin defined in my SConstruct file. Instead it insists on using >> the default compiler on Solaris, CC instead of g++. > > Unfortunately, the guy who switched us over to SCons left the company > several months ago. I'm probably the person who knows most about it > now, and I don't know the answer to your question. I'm pretty sure > you'll need to look at the SCons internals to figure it out. Good luck > with that - the code is horrible :-( From dzonatas at dzonux.net Fri Jul 20 11:29:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 11:29:13 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <46A0FC36.3090909@lindenlab.com> References: <46A0FB20.9020001@sun.com> <46A0FC36.3090909@lindenlab.com> Message-ID: <46A0FF00.9040408@dzonux.net> Hi Dana, I've have reconfigured, twisted, chewed-up, and spit-out the SConstruct file in many ways. I already have several customized versions that uses MSVC, MinGW, and like. They are located here: http://oslcc.svn.sourceforge.net/svnroot/oslcc/osl One thing about SConstruct is that it resets the defaults, so that every build is the same. There are ways to reset that either through the tool-chain def or through the individual maps like, CC, CXX, AR, etc. Let me know how I can help. =) Bryan O'Sullivan wrote: > Dana Fagerstrom wrote: >> This is more for Linux folks. I know most of you have never seen this >> because you only have one compiler installed on your build systems >> but ever since 1.17.0 I've been having trouble getting SCons to use >> the gcc_bin defined in my SConstruct file. Instead it insists on >> using the default compiler on Solaris, CC instead of g++. > > Unfortunately, the guy who switched us over to SCons left the company > several months ago. I'm probably the person who knows most about it > now, and I don't know the answer to your question. I'm pretty sure > you'll need to look at the SCons internals to figure it out. Good > luck with that - the code is horrible :-( > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From dzonatas at dzonux.net Fri Jul 20 11:38:23 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 11:38:06 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <46A0FC36.3090909@lindenlab.com> References: <46A0FB20.9020001@sun.com> <46A0FC36.3090909@lindenlab.com> Message-ID: <46A1011F.1040308@dzonux.net> Bryan O'Sullivan wrote: > Unfortunately, the guy who switched us over to SCons left the company > several months ago. I'm probably the person who knows most about it > now, and I don't know the answer to your question. I'm pretty sure > you'll need to look at the SCons internals to figure it out. Good > luck with that - the code is horrible :-( > Hopefully, you'll accept clean-up patches. I was very skeptical at first, but until I made all the custom files on http://oslcc.svn.sourceforge.net/svnroot/oslcc/osl I found it to be way better then makefiles. SCons is actually really nice. =) -- Power to Change the Void From seg at haxxed.com Fri Jul 20 11:49:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jul 20 11:52:53 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <46A0FB20.9020001@sun.com> References: <46A0FB20.9020001@sun.com> Message-ID: <1184957348.25858.111.camel@localhost.localdomain> On Fri, 2007-07-20 at 14:12 -0400, Dana Fagerstrom wrote: > This is more for Linux folks. I know most of you have never seen this > because you only have one compiler installed on your build systems but > ever since 1.17.0 I've been having trouble getting SCons to use the > gcc_bin defined in my SConstruct file. Instead it insists on using the > default compiler on Solaris, CC instead of g++. > > I opened an issue, http://jira.secondlife.com/browse/VWR-1831, in hopes > that someone closer to SCons will have an idea as to what's happening. > > Note that I do not have a CC, CXX, or other compiler related variable > defined in my bash shell so SCons can't be getting it from there. if standalone: gcc_bin = 'g++' elif build_target != 'client': gcc_bin = 'g++-3.3' elif arch == 'x86_64cross': gcc_bin = '/opt/crosstool/gcc-4.0.2-glibc-2.3.6/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gcc' strip_cmd = '/opt/crosstool/gcc-4.0.2-glibc-2.3.6/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/strip -S -o $TARGET $SOURCE' else: gcc_bin = 'g++-3.4' Which is then passed into the environment as CXX. I really don't see where it would be getting anything else... I find not propagating the existing environment to be complete crackrock, but I guess I'm the only one using ccache and distcc together. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070720/4b5e1110/attachment-0001.pgp From dzonatas at dzonux.net Fri Jul 20 12:01:48 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 12:01:31 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <1184957348.25858.111.camel@localhost.localdomain> References: <46A0FB20.9020001@sun.com> <1184957348.25858.111.camel@localhost.localdomain> Message-ID: <46A1069C.4040307@dzonux.net> Callum Lerwick wrote: > I find not propagating the existing environment to be complete > crackrock, but I guess I'm the only one using ccache and distcc > together. > Easily solved. The SConstruct file should check for a local file that can make such customizations and allow it. The local file could override as you like. -- Power to Change the Void From tateru.nino at gmail.com Fri Jul 20 12:21:30 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jul 20 12:21:38 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <46A0FC36.3090909@lindenlab.com> References: <46A0FB20.9020001@sun.com> <46A0FC36.3090909@lindenlab.com> Message-ID: <46A10B3A.8050808@gmail.com> Bryan O'Sullivan wrote: > Dana Fagerstrom wrote: >> This is more for Linux folks. I know most of you have never seen this >> because you only have one compiler installed on your build systems >> but ever since 1.17.0 I've been having trouble getting SCons to use >> the gcc_bin defined in my SConstruct file. Instead it insists on >> using the default compiler on Solaris, CC instead of g++. > > Unfortunately, the guy who switched us over to SCons left the company > several months ago. I'm probably the person who knows most about it > now, and I don't know the answer to your question. I'm pretty sure > you'll need to look at the SCons internals to figure it out. Good > luck with that - the code is horrible :-( A quick glance at the Scons manual suggests that this path is the place to eyeball: /usr/lib/scons/SCons/Tool/ -- Tateru Nino http://dwellonit.blogspot.com/ From kerdezixe at gmail.com Fri Jul 20 13:01:01 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jul 20 13:01:03 2007 Subject: [sldev] JIRA sandbox on electrosphere Message-ID: <8a1bfe660707201301j4095e057nf8b6fb30b25cb96d@mail.gmail.com> Hello hello ! i installed JIRA on one of my server, you can find it here : http://bug.electrosphere.fr:8080/ it is NOT in production. The database will be deleted and jira reinstalled soon. i created a SANDBOX project. Feel free to play with it if you want to do some experiment with this awesome tool. Please remember it's not linked with the SL database and you shouldn't register with your SL password. Feel free to mail me some suggestion or advice. And play all your soul, it will be deleted and reinstalled... so ... have fun ! -- kerunix Flan From able.whitman at gmail.com Fri Jul 20 13:04:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jul 20 13:04:37 2007 Subject: [sldev] Building thee Mute Visibility patch on Linux Message-ID: <7b3a84fb0707201304u486f2d96i397a09445509e71a@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- diff -urw -X '..\diff-excludes.txt' linden-aw41572\/indra/llprimitive/llprimitive.cpp linden\/indra/llprimitive/llprimitive.cpp --- linden-aw41572\/indra/llprimitive/llprimitive.cpp 2007-07-20 15:39:32.359375000 -0400 +++ linden\/indra/llprimitive/llprimitive.cpp 2007-07-19 19:09:20.562500000 -0400 @@ -343,7 +343,7 @@ // pick the minimum between currrent alpha and the requested alpha, // in case the requested alpha is lower (e..g, for phantom prims) - color.setAlpha(min(mTextureList[te].getColor().mV[VALPHA], te_color.mV[VALPHA])); + color.setAlpha(llmin(mTextureList[te].getColor().mV[VALPHA], te_color.mV[VALPHA])); if (color.mV[VALPHA] > mVisiblyMutedMaxAlpha) { color.setAlpha(mVisiblyMutedMaxAlpha); @@ -371,7 +371,7 @@ // pick the minimum between the visibly muted max alpha and the // requested alpha, in case the requested alpha is lower (e..g, for phantom prims) - color.setAlpha(min(mTextureList[te].getColor().mV[VALPHA], te_color.mV[VALPHA])); + color.setAlpha(llmin(mTextureList[te].getColor().mV[VALPHA], te_color.mV[VALPHA])); if (color.mV[VALPHA] > mVisiblyMutedMaxAlpha) { color.setAlpha(mVisiblyMutedMaxAlpha); @@ -1815,7 +1815,7 @@ for (U32 i = 0; i < count; i++) { mTextureList[i].setColor(LLColor4::white); - mTextureList[i].setAlpha(min(mTextureList[i].getColor().mV[VALPHA], mVisiblyMutedMaxAlpha)); + mTextureList[i].setAlpha(llmin(mTextureList[i].getColor().mV[VALPHA], mVisiblyMutedMaxAlpha)); mTextureList[i].setBumpShinyFullbright(0); mTextureList[i].setID(IMG_DEFAULT); mTextureList[i].setShiny(0); @@ -1830,7 +1830,7 @@ LLTextureEntry new_te(te); new_te.setColor(LLColor4::white); - new_te.setAlpha(min(te.getColor().mV[VALPHA], mVisiblyMutedMaxAlpha)); + new_te.setAlpha(llmin(te.getColor().mV[VALPHA], mVisiblyMutedMaxAlpha)); new_te.setBumpShinyFullbright(0); new_te.setID(IMG_DEFAULT); new_te.setShiny(0); diff -urw -X '..\diff-excludes.txt' linden-aw41572\/indra/newview/llmutelist.cpp linden\/indra/newview/llmutelist.cpp --- linden-aw41572\/indra/newview/llmutelist.cpp 2007-07-20 15:39:32.421875000 -0400 +++ linden\/indra/newview/llmutelist.cpp 2007-07-20 12:53:41.031250000 -0400 @@ -1194,14 +1194,14 @@ return FALSE; } - FILE* fp = LLFile::fopen(filename.c_str(), "rb"); /*Flawfinder: ignore*/ - if (!fp) + std::ifstream fpin; + fpin.open(filename.c_str()); + if (!fpin) { llwarns << "Couldn't open mute list " << filename << llendl; return FALSE; } - std::ifstream fpin(fp); LLString line; while (std::getline(fpin, line)) { @@ -1256,7 +1256,7 @@ } } - fclose(fp); + fpin.close(); // only clear once in a row gSavedSettings.setBOOL("MuteListClearOnNextLogin", FALSE); diff -urw -X '..\diff-excludes.txt' linden-aw41572\/indra/newview/llmutelist.h linden\/indra/newview/llmutelist.h --- linden-aw41572\/indra/newview/llmutelist.h 2007-07-20 15:39:32.421875000 -0400 +++ linden\/indra/newview/llmutelist.h 2007-07-19 19:47:58.984375000 -0400 @@ -84,16 +84,15 @@ { public: LLParcelMute() - : mParcelID(0), mRegionHandle(0), mName("(unknown parcel)") + : mID(LLUUID::null), mDataID(LLUUID::null), mName("(unknown parcel)"), + mParcelID(0), mRegionHandle(0), + mGlobalPosMin(LLVector3d::zero), mGlobalPosMax(LLVector3d::zero) { // in order to fake up parcel mute entries so they can be persisted, // the parcel entry needs an LLUUID associated with it. since there's // no meaningful LLUUID to use (ParcelProperties messages don't provide one), // make a new random one - mID = LLUUID::null; mID.generate(); - - mDataID = LLUUID::null; } LLParcelMute(const LLParcelMute& parcelmute) diff -urw -X '..\diff-excludes.txt' linden-aw41572\/indra/newview/llviewerobject.cpp linden\/indra/newview/llviewerobject.cpp --- linden-aw41572\/indra/newview/llviewerobject.cpp 2007-07-20 15:39:32.515625000 -0400 +++ linden\/indra/newview/llviewerobject.cpp 2007-07-20 15:55:05.312500000 -0400 @@ -3549,7 +3549,7 @@ // don't make objects invisible unless they are already invisible, // since non-phantom objects will still collide with avatars even // if they are invisible - F32 mutealpha = min(mVisiblyMutedMaxAlpha, curcolor.mV[VALPHA]); + F32 mutealpha = llmin(mVisiblyMutedMaxAlpha, curcolor.mV[VALPHA]); // make phantom objects entirely invisible, since avatars can walk through them if (flagPhantom()) From robla at lindenlab.com Fri Jul 20 13:20:39 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jul 20 13:20:52 2007 Subject: [sldev] At OSCON next week Message-ID: <46A11917.2050704@lindenlab.com> Hi folks, A bunch of us going to be down in Portland next week at OSCON at various times. I'll be down there all week. Philip Linden is giving a keynote on Friday, and Phoenix Linden and I will be giving a presentation after that. Philip: http://conferences.oreillynet.com/cs/os2007/view/e_sess/14656 Phoenix and I: http://conferences.oreillynet.com/cs/os2007/view/e_sess/14583 If you're going to be at OSCON, let me know. If you aren't, you'll know what my latest excuse for not responding to you is ;-) Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070720/83db92e5/signature.pgp From dzonatas at dzonux.net Fri Jul 20 14:24:29 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 14:24:12 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <46A03B97.1010605@lindenlab.com> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> <46A03B97.1010605@lindenlab.com> Message-ID: <46A1280D.6050106@dzonux.net> Here is a suggestion for linden/sandbox: linden/sandbox/stable linden/sandbox/testing linden/sandbox/branches/unstable linden/sandbox/branches/2007 The first three branches work in the traditional sense. Debian is a good example to understand that concept. The code flows from out of the branches/2007, to unstable, then to testing, then to stable. QA is done on stable and testing. Only buildme requests can be made on stable only after testing has passed a QA phase, which is when testing is copied in-full to stable if it passes. That's the basic suggested principle used by Debian http://www.debian.org/releases/, and it is similar to what I used 12-14 years ago to automate over 600 legal documents. =) Rob Lanphier wrote: > Alright, let's go for it. If you meet the following criteria, and you > are interested in getting an SVN account on svn.secondlife.com, let me know: > > 1. You have a contribution agreement on file > 2. You have at least one patch accepted into the viewer (you show up in > doc/contributions.txt in the official builds) > 3. You are widely recognized as an active and positive contributor by > the community > > #3 is subjective. Basically, I want to make sure everyone working in > this branch is comfortable working together, and that we're comfortable > working with you. We want there to be some sort of track record. > > Note that svn write access is a privilege and not a right. We reserve > the right not to give you access, and to yank your access for any reason. > > As far as actually distributing any official builds from this > repository, that's TBD. Let's get a good routine for getting the code > in, and then figure out a good routine for getting bits out. > > I've created a sandbox directory here: > http://svn.secondlife.com/svn/linden/sandbox/ > > ...but nothing has gone in yet. > > I haven't yet created any actual branches. I'd like to make sure we use > "svn copy" of an already checked in version of the code to serve as a > base point for any new branches. It sounds like there's a few ideas for > long-lived branches. Here's the guidelines I'd like to follow: > > 1. Only check things into linden/sandbox. The other areas are reserved > for code pushed from the official repository > 2. Let's get a consensus on the branch structure before we go nuts > creating new branches > 3. Only if a branch is going to be long lived should it be at the root > of linden/sandbox . Everything else should go into a year-based > directory (e.g. linden/sandbox/2007/throwaway) > > Rob > > On 7/19/07 8:26 PM, Able Whitman wrote: > >> At the Open Source meeting today >> (https://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-07-19 >> ), >> there was talk of getting a sandbox / community / insert-label-here >> area on svn.secondlife.com , along with >> giving folks with signed source contribution agreements SVN access to >> the repository. >> >> I think this is a great idea--and it seemed like the general consensus >> was extremely positive--so I'm curious if there's a timeline for >> putting something like this together. >> >> The reason I'm asking is that right now we've got a few people >> providing their own viewer distributions (me, Nicholaz, and Dale) with >> varying combinations of patches. And Dzonatas has been putting >> together a proper repository for the OS.1, .2, and .3 releases, which >> serve as a good testbed of all the community-submitted JIRA patches >> all in one big pot. And every different flavor of viewer has different >> installers, different branding changes, etc. >> >> It's great to give people the chance to test JIRA patches before >> they're integrated into the official viewer, but it's also a pretty >> fractious situation. Having a single recognized repository for >> integrating community-contributed patches helps simplify the problem >> of "what patches are where", it will make branding / icon / trademark >> changes easier to standardize, it will make it possible to have common >> installers for each platform, among other things. Plus as we've >> already seen with the recent Vista issue with OS.3, problems like >> providing libraries built against the right source with the right >> compiler (at least for Windows) are easier to solve when there's one >> place to go for build scripts and such. >> >> If getting set up with svn.secondlife.com >> is something that can happen in the fairly near future, that would be >> awesome. If it's going to take some time, then in the meantime I think >> it makes sense to use the repository Dzonatas has setup as a sort of >> stop-gap for the time being, if necessary. My concern is just that >> doing the work to get such a repository working and able to produce >> builds for each platform will require a good amount of work from a >> bunch of people. It would be really nice to know if it made sense to >> do that work now, or wait until svn.secondlife.com >> was available and do that work then. >> >> Cheers, >> --Able >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070720/849e932c/attachment-0001.htm From kerdezixe at gmail.com Fri Jul 20 15:15:04 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jul 20 15:15:07 2007 Subject: [sldev] Re: JIRA sandbox on electrosphere In-Reply-To: <8a1bfe660707201301j4095e057nf8b6fb30b25cb96d@mail.gmail.com> References: <8a1bfe660707201301j4095e057nf8b6fb30b25cb96d@mail.gmail.com> Message-ID: <8a1bfe660707201515k38eaf7f8se22ab483c5e2275c@mail.gmail.com> Someone asked in private "what the point of that ?". So, i'll explain the point, goal, and future projects. And, more important, why do i post that on SLDev, huh ? The most obvious point : You can play and test JIRA without being chased with stick by angry mob if you break something on the official LL's public JIRA. Because, if you break something, it's not a problem : the database will be deleted anyway. The future project : Well...many ! And related to second life. - Experimenting JIRA for non-code related problems. e.g : Estate Managment. ("please move this tree on this public road") - Bugtracking for LSL opensource project. (e.g : https://wiki.secondlife.com/wiki/LSL_Library ) - The most important, but i'd like to ask Linden Lab about that : Provide a website to report bug in french for peoples who don't know english. I'll read the bug, check on the official JIRA if it isn't duplicated, then translate it in english and submit it to the LL's public JIRA. I don't expect a lot of traffic (hopefully) but it's still a nice idea and/or experiment. I may be able to provide JIRA project space, as long as it's public and opensource project. As my coding skills aren't good enough for patching the SL viewer, i try to help with my others skills. e.g : empowering people. ;) -- kerunix Flan From kerdezixe at gmail.com Fri Jul 20 15:31:32 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Fri Jul 20 15:31:34 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <46A1280D.6050106@dzonux.net> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> <46A03B97.1010605@lindenlab.com> <46A1280D.6050106@dzonux.net> Message-ID: <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> On 7/20/07, Dzonatas wrote: > > Here is a suggestion for linden/sandbox: > > linden/sandbox/stable > linden/sandbox/testing > linden/sandbox/branches/unstable > linden/sandbox/branches/2007 My idea of a sandbox is something simple, quick, efficient and easy to use/manage. Some kind of "quick and (not-so)dirty". The "debian way" is a slow process, spend an insane amount of energy and time. And it work, for sure ! But the debian project is managed by thousands of people managing thousands of projects over many years. It's far from being a "sandbox". A Secondlife viewer is released every 2 weeks for the official client, and many times a week for the FirstLook client. If you follow the debian guideline, a "sandbox project" will never, ever, be *stable*. -- kerunix Flan From gigstaggart at gmail.com Fri Jul 20 15:46:23 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jul 20 15:46:25 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> <46A03B97.1010605@lindenlab.com> <46A1280D.6050106@dzonux.net> <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> Message-ID: <46A13B3F.4020509@gmail.com> Laurent Laborde wrote: > On 7/20/07, Dzonatas wrote: >> >> Here is a suggestion for linden/sandbox: >> >> linden/sandbox/stable >> linden/sandbox/testing >> linden/sandbox/branches/unstable >> linden/sandbox/branches/2007 > > A Secondlife viewer is released every 2 weeks for the official client, > and many times a week for the FirstLook client. If you follow the > debian guideline, a "sandbox project" will never, ever, be *stable*. Yes, I agree, we shouldn't go too crazy with a bunch of branches/versions. From dzonatas at dzonux.net Fri Jul 20 16:15:45 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 16:15:28 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> <46A03B97.1010605@lindenlab.com> <46A1280D.6050106@dzonux.net> <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> Message-ID: <46A14221.90909@dzonux.net> Laurent Laborde wrote: > On 7/20/07, Dzonatas wrote: >> >> Here is a suggestion for linden/sandbox: >> >> linden/sandbox/stable >> linden/sandbox/testing >> linden/sandbox/branches/unstable >> linden/sandbox/branches/2007 > > My idea of a sandbox is something simple, quick, efficient and easy to > use/manage. > Some kind of "quick and (not-so)dirty". > > The "debian way" is a slow process, Debian team didn't invent the process, but they did highly innovate the way updates are fed. The update process would be "The Debian Way"... not the structure. As far as Debian comes into role at this time, it is easier to go reference Debian on its structure than to spend time to write-up a 10 page essay on the scheme. =) Let's not confuse this with Debian in that way. Anything less of a structure than suggested I feel will quickly run into stepping on toes. Please do post your example of a structure. -- Power to Change the Void From able.whitman at gmail.com Fri Jul 20 16:53:43 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jul 20 16:53:45 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <46A14221.90909@dzonux.net> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> <46A03B97.1010605@lindenlab.com> <46A1280D.6050106@dzonux.net> <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> <46A14221.90909@dzonux.net> Message-ID: <7b3a84fb0707201653m13873f2dl70a08e562a21faed@mail.gmail.com> I think your branching scheme makes sense, Dzonatas, but I'm curious about what kinds of changes / checkins would be candidates to become their own branches. The way I envision things, most JIRA patches would go straight into unstable, without having to be placed in their own branch first. More complex changes (like Dale's integration of an external rating system, or my mute visibility stuff) might warrant their own branches, however. So I think as that for most patches, the process could work like this: 0. Patches attached to JIRA issue 1. Patches integrated into unstable from JIRA 2. Sanity tests done on unstable to shake out any glaring bugs 3. Changes in unstable integrated into testing 4. More extensive QA done on testing 5. Changes in testing which pass QA integrated into stable That way the majority of work happens in JIRA -> unstable -> testing -> stable, and avoids the problem of having to wrangle many many branches. On 7/20/07, Dzonatas wrote: > > Laurent Laborde wrote: > > On 7/20/07, Dzonatas wrote: > >> > >> Here is a suggestion for linden/sandbox: > >> > >> linden/sandbox/stable > >> linden/sandbox/testing > >> linden/sandbox/branches/unstable > >> linden/sandbox/branches/2007 > > > > My idea of a sandbox is something simple, quick, efficient and easy to > > use/manage. > > Some kind of "quick and (not-so)dirty". > > > > The "debian way" is a slow process, > Debian team didn't invent the process, but they did highly innovate the > way updates are fed. The update process would be "The Debian Way"... not > the structure. As far as Debian comes into role at this time, it is > easier to go reference Debian on its structure than to spend time to > write-up a 10 page essay on the scheme. =) > > Let's not confuse this with Debian in that way. > > Anything less of a structure than suggested I feel will quickly run into > stepping on toes. > > Please do post your example of a structure. > > -- > Power to Change the Void > _______________________________________________ > 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/20070720/579b53e3/attachment.htm From dzonatas at dzonux.net Fri Jul 20 17:27:16 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 20 17:27:02 2007 Subject: [sldev] Re: Getting a community/sandbox area in the SL SVN repository? In-Reply-To: <7b3a84fb0707201653m13873f2dl70a08e562a21faed@mail.gmail.com> References: <7b3a84fb0707192026l47f7cb7bk76ed0b33b84cc9bc@mail.gmail.com> <46A03B97.1010605@lindenlab.com> <46A1280D.6050106@dzonux.net> <8a1bfe660707201531m52262b4fqe2b80519f8f5b8f5@mail.gmail.com> <46A14221.90909@dzonux.net> <7b3a84fb0707201653m13873f2dl70a08e562a21faed@mail.gmail.com> Message-ID: <46A152E4.8070905@dzonux.net> We pretty much agree there. The detail to notes would be to take a "svn copy" of the stable or unstable branch first to a user directory to apply the patches and basically test that it compiles before being committed to unstable. What changes to the patch can be done in the user directory. I say user directory, but it could be like a project directory for a range of patches, too. Apropos to subjects raised at the Open Source meeting, I'm concerned with the history or any auditing not being effective enough under a structure too minimal, so I only suggested a structure and simple flow on par with such concern. (scratch that Debian was ever mentioned -- it obviously confused the idea of the traditional structure) Able Whitman wrote: > I think your branching scheme makes sense, Dzonatas, but I'm curious > about what kinds of changes / checkins would be candidates to become > their own branches. > > The way I envision things, most JIRA patches would go straight into > unstable, without having to be placed in their own branch first. More > complex changes (like Dale's integration of an external rating system, > or my mute visibility stuff) might warrant their own branches, however. > > So I think as that for most patches, the process could work like this: > > 0. Patches attached to JIRA issue > 1. Patches integrated into unstable from JIRA > 2. Sanity tests done on unstable to shake out any glaring bugs > 3. Changes in unstable integrated into testing > 4. More extensive QA done on testing > 5. Changes in testing which pass QA integrated into stable > > That way the majority of work happens in JIRA -> unstable -> testing > -> stable, and avoids the problem of having to wrangle many many > branches. > > On 7/20/07, *Dzonatas* > wrote: > > Laurent Laborde wrote: > > On 7/20/07, Dzonatas > wrote: > >> > >> Here is a suggestion for linden/sandbox: > >> > >> linden/sandbox/stable > >> linden/sandbox/testing > >> linden/sandbox/branches/unstable > >> linden/sandbox/branches/2007 > > > > My idea of a sandbox is something simple, quick, efficient and > easy to > > use/manage. > > Some kind of "quick and (not-so)dirty". > > > > The "debian way" is a slow process, > Debian team didn't invent the process, but they did highly > innovate the > way updates are fed. The update process would be "The Debian > Way"... not > the structure. As far as Debian comes into role at this time, it is > easier to go reference Debian on its structure than to spend time to > write-up a 10 page essay on the scheme. =) > > Let's not confuse this with Debian in that way. > > Anything less of a structure than suggested I feel will quickly > run into > stepping on toes. > > Please do post your example of a structure. > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070720/f8906287/attachment-0001.htm From okumoto at ucsd.edu Fri Jul 20 17:33:17 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Fri Jul 20 17:33:23 2007 Subject: [sldev] crash due to freeing invalid pointers on linux client during quit? In-Reply-To: <46A0EA45.3000705@dzonux.net> References: <46A0D43E.3030300@ucsd.edu> <46A0DC31.6000208@blueflash.cc> <46A0EA45.3000705@dzonux.net> Message-ID: <46A1544D.4090707@ucsd.edu> Hmmmm..... Looks like there is a threading issue or a linking problem. There should only be one instance of a LLDir_Linux object, linden/indra/llvfs/lldir.cpp line 50: LLDir_Linux gDirUtil; But it looks like the destructor for the object is being called twice! Max 2007-07-21T00:25:53Z INFO: cleanup_app: VFS cleaned up 2007-07-21T00:25:53Z INFO: saveToFile: Saving settings to file: /home/okumoto/.secondlife/user_settings/settings.xml 2007-07-21T00:25:53Z INFO: cleanup_app: Saved settings 2007-07-21T00:25:53Z INFO: saveToFile: Saving settings to file: /home/okumoto/.secondlife/user_settings/crash_settings.xml 2007-07-21T00:25:53Z INFO: remove_marker_file() 2007-07-21T00:25:53Z WARNING: cleanup_app: Quitting with pending background tasks. 2007-07-21T00:25:53Z INFO: run: QUEUED THREAD TextureCache EXITING. 2007-07-21T00:25:53Z INFO: LLThread::staticRun() Exiting: TextureCache 2007-07-21T00:25:53Z INFO: run: QUEUED THREAD ImageDecode EXITING. 2007-07-21T00:25:53Z INFO: LLThread::staticRun() Exiting: ImageDecode [Thread -1455207536 (LWP 4787) exited] [Thread -1465697392 (LWP 4788) exited] [Thread -1396315248 (LWP 4785) exited] [Thread -1444717680 (LWP 4786) exited] [Thread -1374082160 (LWP 4783) exited] [Thread -1476187248 (LWP 4789) exited] [Thread -1385825392 (LWP 4784) exited] [Thread -1208534128 (LWP 4782) exited] [Thread 126131088 (LWP 4781) exited] [Switching to Thread 9668304 (LWP 4758)] Breakpoint 3, 0x00b54dd6 in ~LLDir_Linux (this=0xb5c920) at /tmp/linden/local/home/linden/linden/indra/i686-linux-client-releasefordownload/llvfs/lldir_linux.cpp:118 118 LLDir_Linux::~LLDir_Linux() (gdb) cont Continuing. 2007-07-21T00:26:01Z INFO: run: QUEUED THREAD VFS EXITING. 2007-07-21T00:26:01Z INFO: LLThread::staticRun() Exiting: VFS 2007-07-21T00:26:01Z INFO: run: QUEUED THREAD LFS EXITING. 2007-07-21T00:26:01Z INFO: LLThread::staticRun() Exiting: LFS 2007-07-21T00:26:01Z INFO: cleanup_app: VFS Thread finished 2007-07-21T00:26:01Z INFO: ll_cleanup_apr: Cleaning up APR 2007-07-21T00:26:01Z INFO: main: Goodbye [Thread 115641232 (LWP 4779) exited] [Thread 95976336 (LWP 4780) exited] Breakpoint 3, 0x00b54dd6 in ~LLDir_Linux (this=0xb5c920) at /tmp/linden/local/home/linden/linden/indra/i686-linux-client-releasefordownload/llvfs/lldir_linux.cpp:118 118 LLDir_Linux::~LLDir_Linux() Dzonatas wrote: > I'm pretty sure that the use of coLinux along with the malloc tools > you use will nail that down. =p > > http://colinux.wikia.com/wiki/Main_Page > > Nicholaz Beresford wrote: >> >> I know that there is an issue with one of the buttons >> on the login screen accessing memory after it was freed >> (not sure if this is related though). >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Max Okumoto wrote: >>> Hi is anyone compiling the linux client from source and seeing >>> crashes when you >>> quit the client 1.18.0.6? It's happening everytime for me so there >>> is a good chance >>> I will be able to track it down soon. >>> >>> It looks like a double free, or an invalid pointer in the llimage >>> library with a >>> std::string object. >>> >>> Max >>> >>> (gdb) info reg >>> eax 0x29273e4 43152356 >>> ecx 0xbfa29baf -1079862353 >>> edx 0xbfa2a727 -1079859417 >>> ebx 0x293fff4 43253748 >>> esp 0xbfa29b94 0xbfa29b94 >>> ebp 0xbfa29bc4 0xbfa29bc4 >>> esi 0x2 2 >>> edi 0xb6b81f0 191594992 >>> eip 0x286e79a 0x286e79a >>> eflags 0x202 [ IF ] >>> cs 0x73 115 >>> ss 0x7b 123 >>> ds 0x7b 123 >>> es 0x7b 123 >>> fs 0x0 0 >>> gs 0x33 51 >>> (gdb) where >>> #0 0x02862be6 in __libc_message () from /lib/libc.so.6 >>> #1 0x0286e79a in free_check () from /lib/libc.so.6 >>> #2 0x0286df55 in free () from /lib/libc.so.6 >>> #3 0x0278c691 in operator delete () from /usr/lib/libstdc++.so.6 >>> #4 0x0276924d in std::string::_Rep::_M_destroy () from >>> /usr/lib/libstdc++.so.6 >>> #5 0x0068f090 in __tcf_1 () >>> at >>> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:233 >>> >>> #6 0x0282fb09 in __cxa_finalize () from /lib/libc.so.6 >>> #7 0x00688ca4 in __do_global_dtors_aux () >>> from /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so >>> #8 0x006cc6dc in _fini () from >>> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so >>> #9 0x007ba5de in _dl_fini () from /lib/ld-linux.so.2 >>> #10 0x0282f859 in exit () from /lib/libc.so.6 >>> #11 0x02819df4 in __libc_start_main () from /lib/libc.so.6 >>> #12 0x08069b31 in _start () >>> (gdb) cont >>> *** glibc detected *** >>> /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin: >>> free(): invalid pointer: 0x0b6b81f0 *** >>> ======= Backtrace: ========= >>> /lib/libc.so.6[0x286e79a] >>> /lib/libc.so.6(cfree+0x35)[0x286df55] >>> /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x278c691] >>> /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0x276924d] >>> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x68f090] >>> /lib/libc.so.6(__cxa_finalize+0xa9)[0x282fb09] >>> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x688ca4] >>> /opt/SecondLife_i686_1_18_0_6/lib/libllimage.so[0x6cc6dc] >>> /lib/ld-linux.so.2[0x7ba5de] >>> /lib/libc.so.6(exit+0xe9)[0x282f859] >>> /lib/libc.so.6(__libc_start_main+0xe4)[0x2819df4] >>> /opt/SecondLife_i686_1_18_0_6/bin/do-not-directly-run-secondlife-bin[0x8069b31] >>> >>> ======= Memory map: ======== >>> >>> >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > From Paul.Hampson at Pobox.com Fri Jul 20 20:27:06 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Fri Jul 20 20:27:14 2007 Subject: [sldev] where's SCons getting the compiler string In-Reply-To: <1184957348.25858.111.camel@localhost.localdomain> References: <46A0FB20.9020001@sun.com> <1184957348.25858.111.camel@localhost.localdomain> Message-ID: <20070721032706.GA9516@keitarou> On Fri, Jul 20, 2007 at 01:49:08PM -0500, Callum Lerwick wrote: > I find not propagating the existing environment to be complete > crackrock, but I guess I'm the only one using ccache and distcc > together. Which is bizarre, given the SConstruct file is set up to support both ccache and distcc, although with a fixed list of distcc hosts... -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070721/9ca5d6d5/attachment.pgp From pnolan at dsl.pipex.com Sat Jul 21 00:51:39 2007 From: pnolan at dsl.pipex.com (Paul Nolan) Date: Sat Jul 21 00:52:02 2007 Subject: [sldev] Test Server ? Message-ID: Which is the current test server for 1.18.0.6 ? I want to work on some stuff that requires payment and don't want to use my own meagre stash of L$. If there is a place/document I should check for this rather than ask the list, please advise... Paul. From able.whitman at gmail.com Sat Jul 21 01:11:00 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sat Jul 21 01:11:03 2007 Subject: [sldev] Test Server ? In-Reply-To: References: Message-ID: <7b3a84fb0707210111m610c47fbxd0a13596c06a3daf@mail.gmail.com> This brings up a good question... which grids are available to test? I know Agni is the main grid, and Aditi is the beta grid. Back in February, Josh wrote that Uma was supposed to be an open source test grid ( https://lists.secondlife.com/pipermail/sldev/2007-February/000618.html). Is this still the case? If so, is there a place I can go to see the current status of Uma -- like the current version it's running, when it was last updated, etc.? The last SLDev message I found referencing Uma was from April, so it's not clear if the grid has been updated so that 1.18-derivedclients can connect to it (and I haven't tried recently). Are there any other entries in the list of grids that are usable by open source clients? I don't know how often Aditi is reset/updated (once a week? once a month?) but it would be handy if Uma were updated/reset regularly as well. Cheers, --Able On 7/21/07, Paul Nolan wrote: > > Which is the current test server for 1.18.0.6 ? > > I want to work on some stuff that requires payment and don't want to use > my > own meagre stash of L$. > > If there is a place/document I should check for this rather than ask the > list, please advise... > > Paul. > > > _______________________________________________ > 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/20070721/1894db83/attachment.htm From kamilion at gmail.com Sat Jul 21 04:02:51 2007 From: kamilion at gmail.com (Kamilion) Date: Sat Jul 21 04:02:53 2007 Subject: [sldev] Is it just me or is both the wiki and email slow right now? Message-ID: The wiki seems to be performing awfully slow right now... It took about 3 minutes just to load the Second Life icon. Plus the email queues seem to be backed up again... http://www.rpgstats.com/SL/maillog.txt is showing lags of *hours* between mail deliveries. Could someone poke James Linden or one of the other plumbers? ;) From dzonatas at dzonux.net Sat Jul 21 05:56:43 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 21 05:56:23 2007 Subject: [sldev] Test Server ? In-Reply-To: <7b3a84fb0707210111m610c47fbxd0a13596c06a3daf@mail.gmail.com> References: <7b3a84fb0707210111m610c47fbxd0a13596c06a3daf@mail.gmail.com> Message-ID: <46A2028B.3080102@dzonux.net> I haven't got a successful login with Uma as of yet, and I just tried again. Able Whitman wrote: > This brings up a good question... which grids are available to test? I > know Agni is the main grid, and Aditi is the beta grid. Back in > February, Josh wrote that Uma was supposed to be an open source test > grid ( > https://lists.secondlife.com/pipermail/sldev/2007-February/000618.html). > > Is this still the case? If so, is there a place I can go to see the > current status of Uma -- like the current version it's running, when > it was last updated, etc.? The last SLDev message I found referencing > Uma was from April, so it's not clear if the grid has been updated so > that 1.18-derived clients can connect to it (and I haven't tried > recently). > > Are there any other entries in the list of grids that are usable by > open source clients? I don't know how often Aditi is reset/updated > (once a week? once a month?) but it would be handy if Uma were > updated/reset regularly as well. > > Cheers, > --Able > > > > > On 7/21/07, *Paul Nolan* > wrote: > > Which is the current test server for 1.18.0.6 ? > > I want to work on some stuff that requires payment and don't want > to use my > own meagre stash of L$. > > If there is a place/document I should check for this rather than > ask the > list, please advise... > > Paul. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070721/470d50f7/attachment.htm From lenglish5 at cox.net Sat Jul 21 07:38:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Jul 21 07:38:17 2007 Subject: [sldev] "scripting the user interface" jira Message-ID: <46A21A57.90706@cox.net> https://jira.secondlife.com/browse/VWR-1847 The user interface for the Second Life client should be scriptable using Lua or some other scripting language in a fashion similar to that found here: http://www.wowwiki.com/WoW_UI_Customization_Guide A description of the Lua language is found here: http://www.lua.org/manual/5.1/manual.html Any language *other than* LSL might be used to script the GUI for the client. The most that LSL or some mono-based language should ever do in this regard is evoke the client-side scripting language and pass scripts to the client that are cached in notecards in a HUD (or whatever). This allows for a cleaner design, with less clutter of the SL scripting language and allows GUI scripting to remain independent of the capabilities of whatever language is used for SL scripting. From dzonatas at dzonux.net Sat Jul 21 07:46:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 21 07:46:38 2007 Subject: [sldev] "scripting the user interface" jira In-Reply-To: <46A21A57.90706@cox.net> References: <46A21A57.90706@cox.net> Message-ID: <46A21C63.9070106@dzonux.net> I agree, but I don't use Lua. I've been anxious to devote more time to put the OO language in that I developed. There are just a few issues that I've wanted to get done first. From the looks of the UI Roadmap ( https://wiki.secondlife.com/wiki/UI_Roadmap ) it appears a neutral API is workable for any script engine capable to plug-in to the API can also work. There is no specific API as of yet. Lawson English wrote: > https://jira.secondlife.com/browse/VWR-1847 > > > The user interface for the Second Life client should be scriptable > using Lua or some other scripting language in a fashion similar to > that found here: > > http://www.wowwiki.com/WoW_UI_Customization_Guide > > A description of the Lua language is found here: > > http://www.lua.org/manual/5.1/manual.html > > Any language *other than* LSL might be used to script the GUI for the > client. The most that LSL or some mono-based language should ever do > in this regard is evoke the client-side scripting language and pass > scripts to the client that are cached in notecards in a HUD (or > whatever). This allows for a cleaner design, with less clutter of the > SL scripting language and allows GUI scripting to remain independent > of the capabilities of whatever language is used for SL scripting. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From scott at scottnorman.com Sat Jul 21 15:35:04 2007 From: scott at scottnorman.com (Scott T. Norman) Date: Sat Jul 21 15:35:12 2007 Subject: [sldev] Browser In-Reply-To: <469DFE75.2020901@gmail.com> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> Message-ID: <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> On profile page there is the web page which can be loaded into a browser type window in SL, is there a way to access that in SL, if not does LL have any plans for it? It would be great to be able show info in world that's nicely formatted instead of just note cards. Blessings, Scott (aka Mokelembembe Mokeev) www.scottnorman.com God's covenant of revival fire has fallen upon Orange County, California, so that the Church of Orange County will become one and bring healing, salvation, and redemption to the county, and to take part in the harvest of one billion plus souls into the Kingdom of God. - Scott Norman On Jul 18, 2007, at 4:50 AM, Jason Giglio wrote: > jianren chua wrote: >> Hi, >> i know that the the LSL provides the lloadUrl function to load a >> url on an external browser, but is it possible to load the URL >> content without opening a browser? > > No, not really. There are some hacks with quicktime, but they are > cumbersome. > > -Jason > _______________________________________________ > 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/20070721/d29ba978/attachment.htm From dzonatas at dzonux.net Sat Jul 21 16:25:03 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 21 16:24:48 2007 Subject: [sldev] Browser In-Reply-To: <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> Message-ID: <46A295CF.4060703@dzonux.net> See if this is close to what your asking for: http://wiki.secondlife.com/wiki/Web_Textures Also: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Use_Cases &: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Taxonomy Be aware that although those concept over very good and much effort has been done to justify further progress, there is greater and or proven technology that has existed but not yet used in Second Life. Sad... no... more of a shame that the features you seek, same features many seek, are being held up in politics even when the Tao of Linden is against such slimy politics. Accessibility has already become a greater concern within LL, so I sincerely feel the feature you seek will be driven by that path. Cheers! Scott T. Norman wrote: > On profile page there is the web page which can be loaded into a > browser type window in SL, is there a way to access that in SL, if not > does LL have any plans for it? It would be great to be able show > info in world that's nicely formatted instead of just note cards. > > Blessings, > > Scott (aka Mokelembembe Mokeev) > www.scottnorman.com > > > God's covenant of revival fire has fallen upon Orange County, > California, so that the Church of Orange County will become one and > bring healing, salvation, and redemption to the county, and to take > part in the harvest of one billion plus souls into the Kingdom of God. > - Scott Norman > > > > On Jul 18, 2007, at 4:50 AM, Jason Giglio wrote: > >> jianren chua wrote: >>> Hi, >>> i know that the the LSL provides the lloadUrl function to load a url >>> on an external browser, but is it possible to load the URL content >>> without opening a browser? >> >> No, not really. There are some hacks with quicktime, but they are >> cumbersome. >> >> -Jason >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070721/9c9235f6/attachment.htm From secret.argent at gmail.com Sat Jul 21 16:39:17 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 21 16:39:16 2007 Subject: [sldev] "scripting the user interface" jira In-Reply-To: <20070721143817.9997941AF90@stupor.lindenlab.com> References: <20070721143817.9997941AF90@stupor.lindenlab.com> Message-ID: Been suggested many times. Since the gecko source tree is already in the client, an instance of Javascript could be used *so long as it is a completely separate instance of JS from the one used by the in- world browser*. From secret.argent at gmail.com Sat Jul 21 17:16:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 21 17:16:21 2007 Subject: [sldev] Re: "scripting the user interface" jira (Dzonatas) In-Reply-To: <20070721190009.E713641B055@stupor.lindenlab.com> References: <20070721190009.E713641B055@stupor.lindenlab.com> Message-ID: <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> Using an existing language for the in-world SL would not have made as big a difference as you think, since they'd have to reimplement the runtime and possibly the compiler anyway. There are very few, if any, publicly available runtimes that are suitable for the kind of ultra- lightweight execution model that's needed when you have to support thousands of concurrent and mutually untrusted scripts performing realtime control in a single execution context, and none of them are as fast or provide as good a protection model as LSL. The closest alternatives are the implementation languages in MUDs and Mucks, and they don't have to provide real-time response nor support the level of concurrency that SL does, because all of them are strictly driven by user action (the ability for scripts to run autonomously without users present initiating actions is pretty unique to SL)... and I don't know of any of them that use a general purpose runtime in the server. From dzonatas at dzonux.net Sat Jul 21 17:38:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jul 21 17:38:36 2007 Subject: [sldev] Re: "scripting the user interface" jira (Dzonatas) In-Reply-To: <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> References: <20070721190009.E713641B055@stupor.lindenlab.com> <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> Message-ID: <46A2A71B.6060109@dzonux.net> Right. We were talking client-side, however. Argent Stonecutter wrote: > Using an existing language for the in-world SL would not have made as > big a difference as you think, since they'd have to reimplement the > runtime and possibly the compiler anyway. There are very few, if any, > publicly available runtimes that are suitable for the kind of > ultra-lightweight execution model that's needed when you have to > support thousands of concurrent and mutually untrusted scripts > performing realtime control in a single execution context, and none of > them are as fast or provide as good a protection model as LSL. The > closest alternatives are the implementation languages in MUDs and > Mucks, and they don't have to provide real-time response nor support > the level of concurrency that SL does, because all of them are > strictly driven by user action (the ability for scripts to run > autonomously without users present initiating actions is pretty unique > to SL)... and I don't know of any of them that use a general purpose > runtime in the server. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From secret.argent at gmail.com Sat Jul 21 17:48:32 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 21 17:48:36 2007 Subject: [sldev] Re: "scripting the user interface" jira (Dzonatas) In-Reply-To: <46A2A71B.6060109@dzonux.net> References: <20070721190009.E713641B055@stupor.lindenlab.com> <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> <46A2A71B.6060109@dzonux.net> Message-ID: <3D2F0220-5D45-4DE8-A990-28DDD5D49E1F@gmail.com> On 21-Jul-2007, at 19:38, Dzonatas wrote: > Right. We were talking client-side, however. The message I was responding to was expressing dissatisfaction the Linden Labs had devised LSL rather than using an existing language on the server. I agree that LSL on the client would be a poor allocation of resources. :) From scott at scottnorman.com Sat Jul 21 18:25:29 2007 From: scott at scottnorman.com (Scott T. Norman) Date: Sat Jul 21 18:25:34 2007 Subject: [sldev] Browser In-Reply-To: <46A295CF.4060703@dzonux.net> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> Message-ID: Dzonata, thanks for the info, the HTML on a prim, that's what I'm looking for. Its unfortunate it hasn't been developed yet. Went to the wiki links and seems like more then enough justification for having the features built in. Putting text on graphic then uploading it as a texture doesn't make any sense to me. I'll guess I'll look into it more, because there's stuff I'd like to do where HTML on a prim makes more sense then putting text as an image. Since mozilla is already built into the viewer then I'm wondering maybe it would be possible to have a browser window in the viewer like the website in the user profile and then add to the HTTP command in LSL display the web page. Could be a stop gap to having HTML on a prim. Blessings, Scott www.scottnorman.com God's covenant of revival fire has fallen upon Orange County, California, so that the Church of Orange County will become one and bring healing, salvation, and redemption to the county, and to take part in the harvest of one billion plus souls into the Kingdom of God. - Scott Norman On Jul 21, 2007, at 4:25 PM, Dzonatas wrote: > See if this is close to what your asking for: http:// > wiki.secondlife.com/wiki/Web_Textures > > Also: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/ > HTML_on_a_Prim_Use_Cases > &: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/ > HTML_on_a_Prim_Taxonomy > > Be aware that although those concept over very good and much effort > has been done to justify further progress, there is greater and or > proven technology that has existed but not yet used in Second Life. > Sad... no... more of a shame that the features you seek, same > features many seek, are being held up in politics even when the Tao > of Linden is against such slimy politics. > > Accessibility has already become a greater concern within LL, so I > sincerely feel the feature you seek will be driven by that path. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070721/ea08ed93/attachment.htm From secret.argent at gmail.com Sat Jul 21 18:44:41 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jul 21 18:44:40 2007 Subject: [sldev] Browser In-Reply-To: <20070722004835.7718A41AFCA@stupor.lindenlab.com> References: <20070722004835.7718A41AFCA@stupor.lindenlab.com> Message-ID: <6BF661B0-8709-4B02-90FF-A917DC0B13BC@gmail.com> HTML shouldn't be taken to imply either "HTTP" or "on a prim". There really SHOULD be a way to load a notecard into Gecko rather than just displaying it as a notecard. Embedded textures in the notecard could be referenced the same way embedded images in HTML email are, as "", and other embedded objects could be ignored or made illegal. This would be much easier to implement than HTML on a prim, and would avoid the various issues with web-based solutions (among other things... anyone can make a notecard or drop a texture into a notecard, but not everyone has a webserver). From dale at daleglass.net Sat Jul 21 18:53:35 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Jul 21 18:53:45 2007 Subject: Solved. Re: [sldev] Sandbox viewer not working on Vista In-Reply-To: <7b3a84fb0707192007u8e5e3a5xe106fb24f52c5c39@mail.gmail.com> References: <469FC161.9000609@dzonux.net> <200707191539.14159.morris1@ix.netcom.com> <7b3a84fb0707191611i4cb03257p1d45225c85fa1278@mail.gmail.com> <46A00CB6.9010204@dzonux.net> <46A01A6A.70500@dzonux.net> <006601c7ca79$56baba40$0301a8c0@main1> <7b3a84fb0707192007u8e5e3a5xe106fb24f52c5c39@mail.gmail.com> Message-ID: <20070722015334.GA16376@bruno.sbruno> On Thu, Jul 19, 2007 at 11:07:30PM -0400, Able Whitman wrote: > Neither VS7.1 nor VS8 are fundamentally incompatible with Vista; you can use > either one under Vista to build and debug projects, and the executables you > produce will run just fine on any supported target platform. The > incompatibilities that exist between Vista and VS7.1 / VS8 are related to > Vista's UAC features and how they interact with VS's debugging facilities > and software deployment (like One-Click, etc.). This is why MS released a > Vista compatibility update for VS8, to help work around those problems. Ok, so what would be needed to get it to work on Vista? Maybe I missed a message somewhere, but I don't think I've seen anybody mention how to fix it yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070722/c15d53c7/attachment.pgp From tateru.nino at gmail.com Sat Jul 21 22:42:00 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jul 21 22:42:10 2007 Subject: [sldev] Re: "scripting the user interface" jira (Dzonatas) In-Reply-To: <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> References: <20070721190009.E713641B055@stupor.lindenlab.com> <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> Message-ID: <46A2EE28.4000504@gmail.com> Genesis/ColdC comes immediately to mind: http://cold.org/coldc/ Argent Stonecutter wrote: > Using an existing language for the in-world SL would not have made as > big a difference as you think, since they'd have to reimplement the > runtime and possibly the compiler anyway. There are very few, if any, > publicly available runtimes that are suitable for the kind of > ultra-lightweight execution model that's needed when you have to > support thousands of concurrent and mutually untrusted scripts > performing realtime control in a single execution context, and none of > them are as fast or provide as good a protection model as LSL. The > closest alternatives are the implementation languages in MUDs and > Mucks, and they don't have to provide real-time response nor support > the level of concurrency that SL does, because all of them are > strictly driven by user action (the ability for scripts to run > autonomously without users present initiating actions is pretty unique > to SL)... and I don't know of any of them that use a general purpose > runtime in the server. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From matthew.dowd at hotmail.co.uk Sun Jul 22 02:55:11 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jul 22 02:55:11 2007 Subject: [sldev] Re: "scripting the user interface" jira (Dzonatas) Message-ID: > Genesis/ColdC comes immediately to mind: http://cold.org/coldc/ Mmmmm, hardly mainstream - if the issue is that people are put off LSL because it isn't a commonly known language, coldc isn't going to help! (Anyway the bulk of the learning curve in LSL are the ll... functions especially given some of the inconsistencies e.g. it is llGetListLength but nor llGetStringLength; llListInsertList, llListReplaceList but not llListDeleteList etc.) As regards reliability, the coldc website doesn't inspire me with confidence - quite a few of the pages seemed to have a [an error occurred while processing this directive] and a number of pages are returning 404s. I couldn't see how large or active the community behind it was since the e-mail archive links are all 404ing and the list of contributors is "[an error occurred while processing this directive]". Matthew _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From dzonatas at dzonux.net Sun Jul 22 06:11:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 22 06:11:00 2007 Subject: [sldev] Browser In-Reply-To: References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> Message-ID: <46A35775.6000108@dzonux.net> In thinking of the path of least resistance, it may be easier to have the browser window outside of viewer. That would not be HTML on a prim, but it would allow the features of HTML to be put into a notecard or LSL string and made displayable in a web browser on the client. This keeps in mind the potential to have more than one monitor where the notecards and such windows can be moved to another monitor. Scott T. Norman wrote: > Dzonata, thanks for the info, the HTML on a prim, that's what I'm > looking for. Its unfortunate it hasn't been developed yet. Went to the > wiki links and seems like more then enough justification for having > the features built in. Putting text on graphic then uploading it as a > texture doesn't make any sense to me. I'll guess I'll look into it > more, because there's stuff I'd like to do where HTML on a prim makes > more sense then putting text as an image. > > Since mozilla is already built into the viewer then I'm wondering > maybe it would be possible to have a browser window in the viewer like > the website in the user profile and then add to the HTTP command in > LSL display the web page. Could be a stop gap to having HTML on a prim. > > Blessings, > > > Scott > > www.scottnorman.com > > > God's covenant of revival fire has fallen upon Orange County, > California, so that the Church of Orange County will become one and > bring healing, salvation, and redemption to the county, and to take > part in the harvest of one billion plus souls into the Kingdom of God. > - Scott Norman > > > > On Jul 21, 2007, at 4:25 PM, Dzonatas wrote: > >> See if this is close to what your asking >> for: http://wiki.secondlife.com/wiki/Web_Textures >> >> Also: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Use_Cases >> &: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Taxonomy >> >> Be aware that although those concept over very good and much effort >> has been done to justify further progress, there is greater and or >> proven technology that has existed but not yet used in Second Life. >> Sad... no... more of a shame that the features you seek, same >> features many seek, are being held up in politics even when the Tao >> of Linden is against such slimy politics. >> >> Accessibility has already become a greater concern within LL, so I >> sincerely feel the feature you seek will be driven by that path. > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070722/177eda97/attachment-0001.htm From tateru.nino at gmail.com Sun Jul 22 08:28:39 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jul 22 08:28:51 2007 Subject: [sldev] Browser In-Reply-To: <46A35775.6000108@dzonux.net> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> <46A35775.6000108@dzonux.net> Message-ID: <46A377A7.5010508@gmail.com> How well would that interact with SL in full-screen mode? (which I understand to be pretty common) Dzonatas wrote: > In thinking of the path of least resistance, it may be easier to have > the browser window outside of viewer. > > That would not be HTML on a prim, but it would allow the features of > HTML to be put into a notecard or LSL string and made displayable in a > web browser on the client. > > This keeps in mind the potential to have more than one monitor where > the notecards and such windows can be moved to another monitor. > > Scott T. Norman wrote: >> Dzonata, thanks for the info, the HTML on a prim, that's what I'm >> looking for. Its unfortunate it hasn't been developed yet. Went to >> the wiki links and seems like more then enough justification for >> having the features built in. Putting text on graphic then uploading >> it as a texture doesn't make any sense to me. I'll guess I'll look >> into it more, because there's stuff I'd like to do where HTML on a >> prim makes more sense then putting text as an image. >> >> Since mozilla is already built into the viewer then I'm wondering >> maybe it would be possible to have a browser window in the viewer >> like the website in the user profile and then add to the HTTP >> command in LSL display the web page. Could be a stop gap to having >> HTML on a prim. >> >> Blessings, >> >> >> Scott >> >> www.scottnorman.com >> >> >> God's covenant of revival fire has fallen upon Orange County, >> California, so that the Church of Orange County will become one and >> bring healing, salvation, and redemption to the county, and to take >> part in the harvest of one billion plus souls into the Kingdom of >> God. - Scott Norman >> >> >> >> On Jul 21, 2007, at 4:25 PM, Dzonatas wrote: >> >>> See if this is close to what your asking >>> for: http://wiki.secondlife.com/wiki/Web_Textures >>> >>> Also: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Use_Cases >>> &: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Taxonomy >>> >>> Be aware that although those concept over very good and much effort >>> has been done to justify further progress, there is greater and or >>> proven technology that has existed but not yet used in Second Life. >>> Sad... no... more of a shame that the features you seek, same >>> features many seek, are being held up in politics even when the Tao >>> of Linden is against such slimy politics. >>> >>> Accessibility has already become a greater concern within LL, so I >>> sincerely feel the feature you seek will be driven by that path. >> > > -- > Power to Change the Void > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From Paul.Hampson at Pobox.com Sun Jul 22 08:37:25 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sun Jul 22 08:37:35 2007 Subject: [sldev] Debian 1.18.0.6 packages uploaded (Was: shared objects output during standalone build) In-Reply-To: <20070717102705.GB23391@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <1184639588.31185.5.camel@localhost.localdomain> <20070717102705.GB23391@keitarou> Message-ID: <20070722153725.GA1325@keitarou> On Tue, Jul 17, 2007 at 08:27:05PM +1000, Paul TBBle Hampson wrote: > Either way, I've not seen anything here that convinces me that private > shared libraries aren't a good idea for my Debian package builds, so > I'll still go ahead and futz with that when I have a little more time. OK, futzed with as promised. In fact, I ended up making all the client's create_static_module calls into create_cond_module calls. [1] This has reduced the build-time on my laptop to 1:50. I haven't tried a fullly static build, but at some point over the last few releases I was seeing consisten three hour build times. I also expanded the use of the module_libs such that all the shared libraries have NEEDED sections appropriate to their symbols (at least. I haven't culled unneeded entries yet, I need to do a script for that), except libllimagej2coj.so, which needs symbols from libllimage.so AND is NEEDED already by libllimage.so. I doubt much can be done about that, but really the whole NEEDED thing is mainly for my own amusement anyway, although the eventual goal is to remove some of the NEEDED entries from the client that are actually only needed by the libraries. I strongly suspect the compile commands of much of this system could be made drastically shorter (I mean the length of the actual commands, not time taken or anything) by doing this. Newview is the overwhelming majority of build-time, after all, and I would like to see if any gains can be squeezed out by trimming -I's from the compile and -ls from the link command. The above futzing also turned up a buglet, llui's files.list showed a header file in the list, for some reason. Removing it had no apparently ill effects, unless I'm overlooking something. Of course, I suspect from the discussion here earlier that most of the above changes will be broken by the next release, but I hope not, since it shows such a massive improvement in build-time, without any substantial detriment otherwise. (I think it runs faster too, but that could just be 1.18 itself or the latest openjpeg release...) I also made more stuff pkgconfig'd [2], along the lines of the existing pkgconfig stuff. (Thanks for that, by the way. It integrated a lot more cleanly than my own changes did) Those are the two most interesting patches, I think, the whole series is available at [3]. I'll be going through and submitting interesting ones to Jira next chance I get. I'm pretty sure I already submitted 32 and 38, but 40, 42 and 44 I think are good candidates, 45 is disabled and is Debian-specific anyway, and we've already had a discussion about 49, to which this email is attached, and which I still think I'm right about, but suspect I'm in a fairly overwhelming minority. Packages themselves are available if people are interested at [4], and artwork package at [5]. Still just waiting on a response regarding the artwork licensing, and then I think these are good to go. [1] http://www.tbble.net/debian/slviewer/dpatch/49_shared_libraries_are_good.dpatch [2] http://www.tbble.net/debian/slviewer/dpatch/44_pkgconfig_me_harder.dpatch [3] http://www.tbble.net/debian/slviewer/dpatch/ [4] http://www.tbble.net/debian/slviewer/ [5] http://www.tbble.net/debian/slviewer-artwork/ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/0a38c973/attachment.pgp From dzonatas at dzonux.net Sun Jul 22 09:12:33 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jul 22 09:12:15 2007 Subject: [sldev] Browser In-Reply-To: <46A377A7.5010508@gmail.com> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> <46A35775.6000108@dzonux.net> <46A377A7.5010508@gmail.com> Message-ID: <46A381F1.8070003@dzonux.net> In respect to the request to reduce preference options, if in full-screen mode and there is only one monitor, use llmozlib like it does now in the profile to display a web-page, and provide a button on the in-world window to open the same page externally. =) Tateru Nino wrote: > How well would that interact with SL in full-screen mode? (which I > understand to be pretty common) > > Dzonatas wrote: > >> In thinking of the path of least resistance, it may be easier to have >> the browser window outside of viewer. >> >> That would not be HTML on a prim, but it would allow the features of >> HTML to be put into a notecard or LSL string and made displayable in a >> web browser on the client. >> >> This keeps in mind the potential to have more than one monitor where >> the notecards and such windows can be moved to another monitor. >> >> Scott T. Norman wrote: >> >>> Dzonata, thanks for the info, the HTML on a prim, that's what I'm >>> looking for. Its unfortunate it hasn't been developed yet. Went to >>> the wiki links and seems like more then enough justification for >>> having the features built in. Putting text on graphic then uploading >>> it as a texture doesn't make any sense to me. I'll guess I'll look >>> into it more, because there's stuff I'd like to do where HTML on a >>> prim makes more sense then putting text as an image. >>> >>> Since mozilla is already built into the viewer then I'm wondering >>> maybe it would be possible to have a browser window in the viewer >>> like the website in the user profile and then add to the HTTP >>> command in LSL display the web page. Could be a stop gap to having >>> HTML on a prim. >>> >>> Blessings, >>> >>> >>> Scott >>> >>> www.scottnorman.com >>> >>> >>> God's covenant of revival fire has fallen upon Orange County, >>> California, so that the Church of Orange County will become one and >>> bring healing, salvation, and redemption to the county, and to take >>> part in the harvest of one billion plus souls into the Kingdom of >>> God. - Scott Norman >>> >>> >>> >>> On Jul 21, 2007, at 4:25 PM, Dzonatas wrote: >>> >>> >>>> See if this is close to what your asking >>>> for: http://wiki.secondlife.com/wiki/Web_Textures >>>> >>>> Also: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Use_Cases >>>> &: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/HTML_on_a_Prim_Taxonomy >>>> >>>> Be aware that although those concept over very good and much effort >>>> has been done to justify further progress, there is greater and or >>>> proven technology that has existed but not yet used in Second Life. >>>> Sad... no... more of a shame that the features you seek, same >>>> features many seek, are being held up in politics even when the Tao >>>> of Linden is against such slimy politics. >>>> >>>> Accessibility has already become a greater concern within LL, so I >>>> sincerely feel the feature you seek will be driven by that path. >>>> >> -- >> Power to Change the Void >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070722/c555fa20/attachment.htm From cnd at knowprose.com Sun Jul 22 12:21:46 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Sun Jul 22 12:22:12 2007 Subject: [sldev] Browser In-Reply-To: References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> Message-ID: <46A3AE4A.4000508@knowprose.com> Scott T. Norman wrote: > Dzonata, thanks for the info, the HTML on a prim, that's what I'm > looking for. XY Text. http://wiki.secondlife.com/wiki/XyText_1.5 Texture mapping to display alphanumeric characters. While not ideal, scaling text to the various sizes of prims is also an issue, so true 'HTML on a prim' may not be as workable presently as we would wish. Now, a creative LSL hacker could use the same texture mapping technique with multiple textures to signify bold, italic and underlined and do simple rendering from a notecard or llHTTPRequest using the given HTML tags. Given time, I'll probably do it (or someone else will) but it simply may not be worth the effort. llHTTPRequest itself is handicapped at around 2k, it seems - thought *that* isn't quite clear either. Plus, llHTTPRequest doesn't allow one to disregard the body tags, etc... But a notecard reader with XYText 1.5 adapted to handle different aspects of the same font through different textures is a nice thing to work on. This does not solve display of textures from within the notecard, unless one uses a linked object with (perhaps) a dedicated prim for displaying textures. The latter has been done. We call them vendors. :-) -- Taran Rampersad 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 cnd at knowprose.com Sun Jul 22 12:25:33 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Sun Jul 22 12:25:54 2007 Subject: [sldev] Browser In-Reply-To: <46A381F1.8070003@dzonux.net> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> <46A35775.6000108@dzonux.net> <46A377A7.5010508@gmail.com> <46A381F1.8070003@dzonux.net> Message-ID: <46A3AF2D.5030104@knowprose.com> Dzonatas wrote: > In respect to the request to reduce preference options, if in > full-screen mode and there is only one monitor, use llmozlib like it > does now in the profile to display a web-page, and provide a button on > the in-world window to open the same page externally. > > =) With the 'external blue dialog button' present as an option in preferences that can be turned off - yes. And it is usually safe to assume that people are using one monitor. I lay odds that most computer users have one monitor per box. -- Taran Rampersad 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 gigstaggart at gmail.com Sun Jul 22 12:29:19 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jul 22 12:29:19 2007 Subject: [sldev] 2 core changes? In-Reply-To: <46A0EA7F.1040702@gmail.com> References: <46A0EA7F.1040702@gmail.com> Message-ID: <46A3B00F.2030800@gmail.com> Jason Giglio wrote: > It appears that in recent versions, the SL client is using a lot more > CPU on multicore machines. The effect on performance seems to be > strongly positive but it does have some quirks. > > Prior to this, when SL was on a desktop that I wasn't using, its CPU > usage was near zero, now it uses about 100% of one CPU all the time, > even when it's on a hidden desktop. > > When it is on screen, now it uses nearly 2 full CPUs, and the framerate > seems to be very nice, about a 20% increase. > > Can anyone explain the design changes that lead to this new behavior? > > Whatever the "new" loop is doing, can it shut down when the rendering > shuts down too, so that SL doesn't burn up electricity when I'm not > looking at it? Sorry to reply to myself, but this only seems to happen "sometimes". This is looking more like a bug than a performance enhancement. Sometimes the client takes 200% CPU in focus and 100% out of focus, sometimes 100% and 0%. I should note this is the OpenJPEG based client. Maybe OpenJPEG is getting stuck spinning sometimes? -Jason From gigstaggart at gmail.com Sun Jul 22 12:31:12 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jul 22 12:31:14 2007 Subject: [sldev] Browser In-Reply-To: <46A3AE4A.4000508@knowprose.com> References: <76d226120707172118y266ef8c0j6dd9c453f0a66c87@mail.gmail.com> <469DFE75.2020901@gmail.com> <1FBABD4B-EC63-4712-B591-AADE04DCE197@scottnorman.com> <46A295CF.4060703@dzonux.net> <46A3AE4A.4000508@knowprose.com> Message-ID: <46A3B080.7070501@gmail.com> Taran Rampersad wrote: > Scott T. Norman wrote: >> Dzonata, thanks for the info, the HTML on a prim, that's what I'm >> looking for. > XY Text. http://wiki.secondlife.com/wiki/XyText_1.5 http://wiki.secondlife.com/wiki/XyzzyText Please use XyzzyText instead for most large display uses. It's much more efficient. -Jason From sl at phoca.com Sun Jul 22 13:11:24 2007 From: sl at phoca.com (Second Life) Date: Sun Jul 22 13:11:32 2007 Subject: [sldev] 2 core changes? In-Reply-To: <46A3B00F.2030800@gmail.com> References: <46A0EA7F.1040702@gmail.com> <46A3B00F.2030800@gmail.com> Message-ID: <91648B288DB549BDB5AEBB8639281DEA@SanMiguel> If you are running an nvidia driver and you have the multithreaded optimizations on on the driver preferences (I forget what the default is, maybe "Auto") then the OpenGL driver from nvidia is actually multithreaded and you will gain about 20% in frame rate while eating up about 40% more total CPU I've noticed. I have also noticed that is it buggier and leads to more crashing than without so I've turned it of "off". I also noticed it worked better sometimes than others, maybe due to what other programs I have running or ran then stopped (poser/blender etc) while SL was open. Farallon ----- Original Message ----- From: "Jason Giglio" To: "Second Life Developer Mailing List" Sent: Sunday, July 22, 2007 12:29 PM Subject: Re: [sldev] 2 core changes? > > > Jason Giglio wrote: >> It appears that in recent versions, the SL client is using a lot more CPU >> on multicore machines. The effect on performance seems to be strongly >> positive but it does have some quirks. >> >> Prior to this, when SL was on a desktop that I wasn't using, its CPU >> usage was near zero, now it uses about 100% of one CPU all the time, even >> when it's on a hidden desktop. >> >> When it is on screen, now it uses nearly 2 full CPUs, and the framerate >> seems to be very nice, about a 20% increase. >> >> Can anyone explain the design changes that lead to this new behavior? >> >> Whatever the "new" loop is doing, can it shut down when the rendering >> shuts down too, so that SL doesn't burn up electricity when I'm not >> looking at it? > > > Sorry to reply to myself, but this only seems to happen "sometimes". This > is looking more like a bug than a performance enhancement. Sometimes the > client takes 200% CPU in focus and 100% out of focus, sometimes 100% and > 0%. > > I should note this is the OpenJPEG based client. Maybe OpenJPEG is > getting stuck spinning sometimes? > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From seg at haxxed.com Sun Jul 22 19:21:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Jul 22 19:25:50 2007 Subject: [sldev] 2 core changes? In-Reply-To: <46A3B00F.2030800@gmail.com> References: <46A0EA7F.1040702@gmail.com> <46A3B00F.2030800@gmail.com> Message-ID: <1185157268.25858.130.camel@localhost.localdomain> On Sun, 2007-07-22 at 15:29 -0400, Jason Giglio wrote: > I should note this is the OpenJPEG based client. Maybe OpenJPEG is > getting stuck spinning sometimes? It does, it usually gets stuck trying to decode what seems to be your own avatar's eye texture. Just one of many annoying quirks with lossless encoding, that go away when patched to use lossy encoding. (VWR-1475) Or are you using it already? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070722/92c45881/attachment.pgp From robla at lindenlab.com Sun Jul 22 20:33:43 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Jul 22 20:33:57 2007 Subject: [sldev] Reminder: Nomination closing tonight for the Linden Lab Innovation Awards Message-ID: <46A42197.2060002@lindenlab.com> Hi everyone, Just a reminder, the nomination window is closing TONIGHT (11:59pm PDT, less than 3.5 hours from now) for the Linden Lab Innovation Awards: http://blog.secondlife.com/2007/07/17/linden-lab-to-recognize-open-source-contributors/ Please make sure you get your nominations in. Perhaps scour the archives for people from months gone by that made some key early contributions. I'd hate to have /too/ much of a bias toward the most recent contributors, though clearly we want to reward those that have stuck with it and whose best contributions are perhaps yet to come. Rob -------- Original Message -------- Subject: [sldev] Announcing the Linden Lab Innovation Awards Date: Tue, 10 Jul 2007 09:05:42 -0700 From: Liana Holmberg Reply-To: liana@lindenlab.com, liana@airpost.net Organization: Linden Lab / Second Life To: sldev@lists.secondlife.com Dear Second Life Open Source Community Members: We are pleased to announce the inception of the annual Linden Lab Innovation Awards for excellence in developing the Second Life platform. The awards will acknowledge open source contributors who have made the biggest impact on the quality and advancement of the Second Life Viewer. We are now accepting nominations from the SL open source community for the 2007 Linden Lab Innovation Awards. Judges will include Linden developers and open source team members. Award winners will be announced during the Second Life Community Convention. How It Works 1. Nominations If you would like to nominate an open source developer or open source community contributor, then * sign in to the Issue Tracker and add the person's Second Life avatar name as a subtask to the appropriate category (below), and * write a comment about what their contribution was and why you find it to be exemplary. Linden Lab employees and family members are not eligible. Nominations are open from now through 22 July 2007 23:59 PDT. This year's categories are: *Contributor of the Year https://jira.secondlife.com/browse/MISC-392 *Best Contribution https://jira.secondlife.com/browse/MISC-393 *Best Feature https://jira.secondlife.com/browse/MISC-394 *Best Bug Hunter https://jira.secondlife.com/browse/MISC-395 *Best Community Organizer https://jira.secondlife.com/browse/MISC-396 2. Judging Judges will be announced separately and will include Linden developers and open source team members. These are juried awards, and they will be awarded based on a set of criteria and point system used by the judges. A note about voting: JIRA has this nifty voting feature. You are welcome to vote for nominees you believe have merit. However, winners will not be selected by popular vote but through the juried process above. 3. Awards Award winners will be announced in Second Life and during the Second Life Community Convention, held August 24-26 in Chicago, IL (http://slcc2007.wordpress.com/). A later announcement will give the date, time, and location of this event. The Contributor of the Year will receive a MacBook Pro. We appreciate all the contributions of the Second Life open source community, and we'll be listening to your feedback and recommendations for improving the awards program for next year. Please add constructive comments to this wiki https://wiki.secondlife.com/wiki/Linden_Lab_Innovation_Awards. Any questions, post them to sldev@lists.secondlife.com or email liana@lindenlab.com. Thanks, Liana - - - - - The LINDEN LAB INNOVATION AWARDS are for entertainment purposes only and have no monetary or other value. LINDEN LAB, LINDEN RESEARCH, and SECOND LIFE are trademarks or registered trademarks of Linden Research, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070722/943e1a39/signature.pgp From agrimes at speakeasy.net Sun Jul 22 22:12:25 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Sun Jul 22 21:12:41 2007 Subject: [sldev] What a way to blow L$100... =( Message-ID: <46A438B9.8030103@speakeasy.net> I started a group, fee L$100. I go off line for a few days, and come back to find that it had been deleted for lack of members!!! =(((( WTF???? you just stole L$100 from me!!! You were always allowed to keep e-mail lists on yahogroups/egroups/sixderees/onelist/etc etc etc open for several months while you waited for people to find it.... My interest in SL has just droped 95%. =( -- Opera: Sing it loud! :o( )>-< From adam at gwala.net Sun Jul 22 21:22:10 2007 From: adam at gwala.net (Adam Frisby) Date: Sun Jul 22 21:22:52 2007 Subject: [sldev] What a way to blow L$100... =( In-Reply-To: <46A438B9.8030103@speakeasy.net> References: <46A438B9.8030103@speakeasy.net> Message-ID: <46A42CF2.3070700@gwala.net> It does say it when you create the group that you need 3 members within 3 days. Adam Alan Grimes wrote: > I started a group, fee L$100. > > I go off line for a few days, and come back to find that it had been > deleted for lack of members!!! =(((( > > WTF???? > > you just stole L$100 from me!!! > > You were always allowed to keep e-mail lists on > yahogroups/egroups/sixderees/onelist/etc etc etc open for several months > while you waited for people to find it.... > > My interest in SL has just droped 95%. =( > From tshephard at gmail.com Sun Jul 22 21:27:58 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sun Jul 22 21:28:02 2007 Subject: [sldev] What a way to blow L$100... =( In-Reply-To: <46A438B9.8030103@speakeasy.net> References: <46A438B9.8030103@speakeasy.net> Message-ID: <3b19a500707222127j4a401e4fv75415b45c068ab6c@mail.gmail.com> What's your SL account? I'll send you 100 L$. On 7/22/07, Alan Grimes wrote: > I started a group, fee L$100. > > I go off line for a few days, and come back to find that it had been > deleted for lack of members!!! =(((( > > WTF???? > > you just stole L$100 from me!!! > > You were always allowed to keep e-mail lists on > yahogroups/egroups/sixderees/onelist/etc etc etc open for several months > while you waited for people to find it.... > > My interest in SL has just droped 95%. =( > > -- > Opera: Sing it loud! :o( )>-< > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From yazzgoth at gmail.com Mon Jul 23 01:09:32 2007 From: yazzgoth at gmail.com (Bartosz Ptaszynski) Date: Mon Jul 23 01:09:34 2007 Subject: [sldev] About the Open Source Viewer In-Reply-To: <00a001c7c967$4ac49480$8901a8c0@main1> References: <01a401c7c827$65504e70$a4689943@gwsystems2.com> <00a001c7c967$4ac49480$8901a8c0@main1> Message-ID: I think a "Community Edition" is appropriate as it is maintained by the community. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070723/15bd1c38/attachment.htm From dale at daleglass.net Mon Jul 23 03:10:15 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 23 03:10:25 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? Message-ID: <20070723101014.GA7339@bruno.sbruno> Hi! My avatar scanner (see http://sl.daleglass.net) calculates ages of residents based on the birth date. On Linux I use strptime for this, but Windows lacks the function, so currently this functionality isn't available there. I'd like to be able to merge this into the official source some day, so I'd like to know if LL would accept a 3-clause BSD licensed implementation of strptime. Of course, if somebody knows of a better alternative, that works for me as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/c7487713/attachment.pgp From nicholaz at blueflash.cc Mon Jul 23 03:28:12 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 23 03:28:26 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723101014.GA7339@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> Message-ID: <46A482BC.9010309@blueflash.cc> What kind of date string do you get there? (Do the Lindens really just send a string for the avatar?) Nick Dale Glass wrote: > Hi! > > My avatar scanner (see http://sl.daleglass.net) calculates ages of > residents based on the birth date. On Linux I use strptime for this, but > Windows lacks the function, so currently this functionality isn't > available there. > > I'd like to be able to merge this into the official source some day, so > I'd like to know if LL would accept a 3-clause BSD licensed > implementation of strptime. > > Of course, if somebody knows of a better alternative, that works for me > as well. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dale at daleglass.net Mon Jul 23 03:33:29 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 23 03:33:35 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <46A482BC.9010309@blueflash.cc> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> Message-ID: <20070723103329.GB7339@bruno.sbruno> On Mon, Jul 23, 2007 at 12:28:12PM +0200, Nicholaz Beresford wrote: > > What kind of date string do you get there? (Do the > Lindens really just send a string for the avatar?) Yep, the date as it appears in the profile. I suppose I could roll my own as well, but why reinvent the wheel if there's perfectly good code out there? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/32af28b1/attachment.pgp From nicholaz at blueflash.cc Mon Jul 23 03:51:48 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 23 03:51:57 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723103329.GB7339@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> Message-ID: <46A48844.8030705@blueflash.cc> It's Linden-deprecated, but I'd simply use sscanf before I'd jump through the licensing hoops (but of course I'm pretty old-school :-)) S32 d,m,y,n; n= sscanf(buf, "%d/%d/%d", &m, &d, &y); if (n!=3) return FALSE; struct tm birth = { 0, 0, 0, d, m-1, y-1900, 0, 0, 0 }; Nick Dale Glass wrote: > On Mon, Jul 23, 2007 at 12:28:12PM +0200, Nicholaz Beresford wrote: >> What kind of date string do you get there? (Do the >> Lindens really just send a string for the avatar?) > Yep, the date as it appears in the profile. > > I suppose I could roll my own as well, but why reinvent the wheel if > there's perfectly good code out there? From dale at daleglass.net Mon Jul 23 04:26:03 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 23 04:26:08 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <46A48844.8030705@blueflash.cc> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <46A48844.8030705@blueflash.cc> Message-ID: <20070723112603.GA19033@bruno.sbruno> On Mon, Jul 23, 2007 at 12:51:48PM +0200, Nicholaz Beresford wrote: > > It's Linden-deprecated, but I'd simply use sscanf > before I'd jump through the licensing hoops (but of > course I'm pretty old-school :-)) > > S32 d,m,y,n; > n= sscanf(buf, "%d/%d/%d", &m, &d, &y); > if (n!=3) return FALSE; > struct tm birth = { 0, 0, 0, d, m-1, y-1900, 0, 0, 0 }; Well, from a LL acceptance POV, I suppose I could do this but without deprecated functions. Was kinda hoping that there already was something suitable that I didn't notice though. Then, I'm not sure this thing is likely to ever get merged anyway :-) Not with all of its features at least. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/414f302a/attachment.pgp From nicholaz at blueflash.cc Mon Jul 23 04:35:13 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 23 04:35:22 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723112603.GA19033@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <46A48844.8030705@blueflash.cc> <20070723112603.GA19033@bruno.sbruno> Message-ID: <46A49271.2020809@blueflash.cc> Dunno if there's something more suitable in the LLStrings or std::string ... like easy splitting into tokens or similar. But my point is that with a task as simple as that (not eving having to parse a string month), inserting BSD license code would be the bigger hassle. Just my two L$ worth of opinion thouth. Nick PS: Oh, and the S32 down there should be an "int" ... which is probably one of the reasons why it'd deprecated :-) Dale Glass wrote: > On Mon, Jul 23, 2007 at 12:51:48PM +0200, Nicholaz Beresford wrote: >> It's Linden-deprecated, but I'd simply use sscanf >> before I'd jump through the licensing hoops (but of >> course I'm pretty old-school :-)) >> >> S32 d,m,y,n; >> n= sscanf(buf, "%d/%d/%d", &m, &d, &y); >> if (n!=3) return FALSE; >> struct tm birth = { 0, 0, 0, d, m-1, y-1900, 0, 0, 0 }; > > Well, from a LL acceptance POV, I suppose I could do this but without > deprecated functions. Was kinda hoping that there already was something > suitable that I didn't notice though. > > Then, I'm not sure this thing is likely to ever get merged anyway :-) > Not with all of its features at least. From dale at daleglass.net Mon Jul 23 04:50:33 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 23 04:50:43 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <46A49271.2020809@blueflash.cc> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <46A48844.8030705@blueflash.cc> <20070723112603.GA19033@bruno.sbruno> <46A49271.2020809@blueflash.cc> Message-ID: <20070723115033.GB19033@bruno.sbruno> On Mon, Jul 23, 2007 at 01:35:13PM +0200, Nicholaz Beresford wrote: > > Dunno if there's something more suitable in the LLStrings > or std::string ... like easy splitting into tokens or similar. > > But my point is that with a task as simple as that (not eving > having to parse a string month), inserting BSD license code > would be the bigger hassle. > > Just my two L$ worth of opinion thouth. Sure, that works, but it's a bit specific. Since AFAIK, the standard viewer doesn't try to interpret it anywhere, LL is quite free to suddenly decide to send the month as a string, or something of that sort. Then, LLSD seems to have date support, they probably should be using that instead. Also, if anybody from LL is reading this, I'd still like to know if 3-BSD code would be accepted. BSD being what it is (especially the version without the advertising clause) I assume that using it should involve very minimal hassle. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/465a51ee/attachment.pgp From eponymousdylan at googlemail.com Mon Jul 23 06:45:39 2007 From: eponymousdylan at googlemail.com (EponymousDylan Ra) Date: Mon Jul 23 06:45:43 2007 Subject: [sldev] temporarily show only avatars Message-ID: Hi all Just thinking that a nice viewer feature for SL photographers would be to temporarily hide everything except the avatars currently in view. So no background or sky at all - just a solid background colour. Any ideas where to start with that? Is it likely to be doable with a small amount of code? Thanks E -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070723/046cc7d5/attachment.htm From nicholaz at blueflash.cc Mon Jul 23 07:08:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jul 23 07:08:23 2007 Subject: [sldev] temporarily show only avatars In-Reply-To: References: Message-ID: <46A4B64B.1080902@blueflash.cc> Did you look at the render features in the debug menus? Besides that, you can probably work your way down from the main loop into the render functions ... skipping them probably isn't too hard if you take the render debug options as an example. Nick EponymousDylan Ra wrote: > Hi all > > Just thinking that a nice viewer feature for SL photographers would be > to temporarily hide everything except the avatars currently in view. So > no background or sky at all - just a solid background colour. > > Any ideas where to start with that? Is it likely to be doable with a > small amount of code? > > Thanks > > E > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From eponymousdylan at googlemail.com Mon Jul 23 08:04:00 2007 From: eponymousdylan at googlemail.com (EponymousDylan Ra) Date: Mon Jul 23 08:04:04 2007 Subject: [sldev] temporarily show only avatars In-Reply-To: <46A4B64B.1080902@blueflash.cc> References: <46A4B64B.1080902@blueflash.cc> Message-ID: > Did you look at the render features in the debug menus? No - that sounds like a great place to start. Thanks very much. From liana at lindenlab.com Mon Jul 23 09:11:46 2007 From: liana at lindenlab.com (Liana Holmberg) Date: Mon Jul 23 09:12:46 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723101014.GA7339@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> Message-ID: <46A4D342.2090003@lindenlab.com> Dale, I caught your question and will discuss with our licensing crew. Thanks, Liana Dale Glass wrote: > Hi! > > My avatar scanner (see http://sl.daleglass.net) calculates ages of > residents based on the birth date. On Linux I use strptime for this, but > Windows lacks the function, so currently this functionality isn't > available there. > > I'd like to be able to merge this into the official source some day, so > I'd like to know if LL would accept a 3-clause BSD licensed > implementation of strptime. > > Of course, if somebody knows of a better alternative, that works for me > as well. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070723/d542f9e7/attachment.htm From josh at lindenlab.com Mon Jul 23 10:30:08 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jul 23 10:30:15 2007 Subject: [sldev] Test Server ? In-Reply-To: <46A2028B.3080102@dzonux.net> References: <7b3a84fb0707210111m610c47fbxd0a13596c06a3daf@mail.gmail.com> <46A2028B.3080102@dzonux.net> Message-ID: <46A4E5A0.7050103@lindenlab.com> Yep, sorry, we started using Uma for some internal testing. Now that we've hit "message template liberation" you should be able to connect any 1.18 or later viewer to Aditi for the foreseeable future. We're pushing some internal test builds to Aditi on an irregular basis as well, but leaving the grid open, and none should affect compatibility. Dzonatas wrote: > I haven't got a successful login with Uma as of yet, and I just tried > again. > > Able Whitman wrote: >> This brings up a good question... which grids are available to test? >> I know Agni is the main grid, and Aditi is the beta grid. Back in >> February, Josh wrote that Uma was supposed to be an open source test >> grid ( >> https://lists.secondlife.com/pipermail/sldev/2007-February/000618.html). >> >> Is this still the case? If so, is there a place I can go to see the >> current status of Uma -- like the current version it's running, when >> it was last updated, etc.? The last SLDev message I found referencing >> Uma was from April, so it's not clear if the grid has been updated so >> that 1.18-derived clients can connect to it (and I haven't tried >> recently). >> >> Are there any other entries in the list of grids that are usable by >> open source clients? I don't know how often Aditi is reset/updated >> (once a week? once a month?) but it would be handy if Uma were >> updated/reset regularly as well. >> >> Cheers, >> --Able >> >> >> >> >> On 7/21/07, *Paul Nolan* > > wrote: >> >> Which is the current test server for 1.18.0.6 ? >> >> I want to work on some stuff that requires payment and don't want >> to use my >> own meagre stash of L$. >> >> If there is a place/document I should check for this rather than >> ask the >> list, please advise... >> >> Paul. >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > -- > Power to Change the Void > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sl at phoca.com Mon Jul 23 10:32:33 2007 From: sl at phoca.com (Second Life) Date: Mon Jul 23 10:32:47 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <46A49271.2020809@blueflash.cc> References: <20070723101014.GA7339@bruno.sbruno><46A482BC.9010309@blueflash.cc><20070723103329.GB7339@bruno.sbruno><46A48844.8030705@blueflash.cc><20070723112603.GA19033@bruno.sbruno> <46A49271.2020809@blueflash.cc> Message-ID: Not to mention that writing in single platform only code is going to be a BIG no-no. SL has gone to great lengths to make this code cross platform, the last thing we want to do is start fracturing it on an OS basis... Especially if you did plan on it being merged with the main code base. As long as it has to be rewritten for another platform it should be written cross platform to begin with. Farallon ----- Original Message ----- From: "Nicholaz Beresford" To: "Nicholaz Beresford" ; Sent: Monday, July 23, 2007 4:35 AM Subject: Re: [sldev] Can I include source licensed under the 3-clause BSD? > > Dunno if there's something more suitable in the LLStrings > or std::string ... like easy splitting into tokens or similar. > > But my point is that with a task as simple as that (not eving > having to parse a string month), inserting BSD license code > would be the bigger hassle. > > Just my two L$ worth of opinion thouth. > > > Nick > > PS: Oh, and the S32 down there should be an "int" ... which > is probably one of the reasons why it'd deprecated :-) > > > > Dale Glass wrote: >> On Mon, Jul 23, 2007 at 12:51:48PM +0200, Nicholaz Beresford wrote: >>> It's Linden-deprecated, but I'd simply use sscanf >>> before I'd jump through the licensing hoops (but of >>> course I'm pretty old-school :-)) >>> >>> S32 d,m,y,n; >>> n= sscanf(buf, "%d/%d/%d", &m, &d, &y); >>> if (n!=3) return FALSE; >>> struct tm birth = { 0, 0, 0, d, m-1, y-1900, 0, 0, 0 }; >> >> Well, from a LL acceptance POV, I suppose I could do this but without >> deprecated functions. Was kinda hoping that there already was something >> suitable that I didn't notice though. >> >> Then, I'm not sure this thing is likely to ever get merged anyway :-) >> Not with all of its features at least. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From me at hamncheeseomlet.com Mon Jul 23 11:12:55 2007 From: me at hamncheeseomlet.com (ham) Date: Mon Jul 23 11:12:59 2007 Subject: [sldev] comments on patch for VWR-423 References: <20070723101014.GA7339@bruno.sbruno><46A482BC.9010309@blueflash.cc><20070723103329.GB7339@bruno.sbruno><46A48844.8030705@blueflash.cc><20070723112603.GA19033@bruno.sbruno><46A49271.2020809@blueflash.cc> Message-ID: <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> Hi all. I've attached a patch to VWR-423 to cover both VWR-423 and VWR-1187. I've tested on a windows build using 1.18, but would like some more eyes on it since this is my first patch. VWR-423 is "Selecting group charter text causes Apply/Ignore/Cancel popup even if the text wasn't changed" and VWR-1187 is "Profile > Classifieds tab shows confirmation dialog when no changes are made" http://jira.secondlife.com/browse/VWR-423 http://jira.secondlife.com/browse/VWR-1187 There are two types of fixes here. For the first change LLTextEditor now only calls onCommit within LLTextEditor::onFocusLost if the text has changed (similar to how LLLineEditor handle it). The other changes are to filter calls to onFocusReceived in LLPanelClassified, LLPanelGroupRolesSubTab and LLPanelGroupGeneral. There is an assumption made in the code for LLUICtrl::setFocus that disabled (readonly) controls never get the focus and hence never will call onFocusReceived. You cannot disable the LLTextEditor when setting read only because that would take away the ability for users to scroll long text (such as no copy notecard). So all that to say...that the onFocusReceived and some onCommit calls had to filtered to make sure if onCommit is being called that the user has the rights to change and that in fact the text is changed. By itself, this fix won't affect performance of one viewer but I would imagine with all the update messages not happening, this change will help overall scale. One example this will help is that spurious PickInfoUpdate messages that were being generated just by clicking the description of someone else's Picks and losing focus. Anywho...let me know if you have any problems or questions if you incorporate this patch. thanks, Jon Price/Hamncheese Omlet From gigstaggart at gmail.com Mon Jul 23 13:13:21 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jul 23 13:13:26 2007 Subject: [sldev] Triage agenda done Message-ID: <46A50BE1.5020802@gmail.com> Triage agenda is done, T minus 2 hours and counting. I won't be able to attend the triage, however. https://wiki.secondlife.com/wiki/Bug_triage/Monday_Agenda From able.whitman at gmail.com Mon Jul 23 13:45:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jul 23 13:45:33 2007 Subject: [sldev] Triage agenda done In-Reply-To: <46A50BE1.5020802@gmail.com> References: <46A50BE1.5020802@gmail.com> Message-ID: <7b3a84fb0707231345n28782b3asce10e351641e7158@mail.gmail.com> Thanks, Gigs! On 7/23/07, Jason Giglio wrote: > > Triage agenda is done, T minus 2 hours and counting. I won't be able to > attend the triage, however. > > https://wiki.secondlife.com/wiki/Bug_triage/Monday_Agenda > _______________________________________________ > 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/20070723/0b1e31b0/attachment.htm From liana at lindenlab.com Mon Jul 23 14:44:48 2007 From: liana at lindenlab.com (Liana Holmberg) Date: Mon Jul 23 14:44:43 2007 Subject: [sldev] Nominations closed for the Linden Lab Innovation Awards In-Reply-To: <46A42197.2060002@lindenlab.com> References: <46A42197.2060002@lindenlab.com> Message-ID: <46A52150.7070904@lindenlab.com> My thanks to everyone who participated in the nomination process -- and, of course, to the community for all your contributions to SL open source. I was particularly touched to see your nominations in-memoriam of Jesse Malthus. We share your appreciation for his work and his spirit. -liana Rob Lanphier wrote: > Hi everyone, > > Just a reminder, the nomination window is closing TONIGHT (11:59pm PDT, > less than 3.5 hours from now) for the Linden Lab Innovation Awards: > http://blog.secondlife.com/2007/07/17/linden-lab-to-recognize-open-source-contributors/ > > Please make sure you get your nominations in. Perhaps scour the > archives for people from months gone by that made some key early > contributions. I'd hate to have /too/ much of a bias toward the most > recent contributors, though clearly we want to reward those that have > stuck with it and whose best contributions are perhaps yet to come. > > Rob > -------- Original Message -------- > Subject: [sldev] Announcing the Linden Lab Innovation Awards > Date: Tue, 10 Jul 2007 09:05:42 -0700 > From: Liana Holmberg > Reply-To: liana@lindenlab.com, liana@airpost.net > Organization: Linden Lab / Second Life > To: sldev@lists.secondlife.com > > > > Dear Second Life Open Source Community Members: > > We are pleased to announce the inception of the annual Linden Lab > Innovation Awards for excellence in developing the Second Life platform. > The awards will acknowledge open source contributors who have made the > biggest impact on the quality and advancement of the Second Life Viewer. > > We are now accepting nominations from the SL open source community for > the 2007 Linden Lab Innovation Awards. Judges will include Linden > developers and open source team members. Award winners will be announced > during the Second Life Community Convention. > > How It Works > > 1. Nominations > If you would like to nominate an open source developer or open source > community contributor, then > * sign in to the Issue Tracker and add the person's Second Life avatar > name as a subtask to the appropriate category (below), and > * write a comment about what their contribution was and why you find it > to be exemplary. > Linden Lab employees and family members are not eligible. > Nominations are open from now through 22 July 2007 23:59 PDT. > > This year's categories are: > *Contributor of the Year https://jira.secondlife.com/browse/MISC-392 > *Best Contribution https://jira.secondlife.com/browse/MISC-393 > *Best Feature https://jira.secondlife.com/browse/MISC-394 > *Best Bug Hunter https://jira.secondlife.com/browse/MISC-395 > *Best Community Organizer https://jira.secondlife.com/browse/MISC-396 > > 2. Judging > Judges will be announced separately and will include Linden developers > and open source team members. These are juried awards, and they will be > awarded based on a set of criteria and point system used by the judges. > A note about voting: JIRA has this nifty voting feature. You are welcome > to vote for nominees you believe have merit. However, winners will not > be selected by popular vote but through the juried process above. > > 3. Awards > Award winners will be announced in Second Life and during the Second > Life Community Convention, held August 24-26 in Chicago, IL > (http://slcc2007.wordpress.com/). A later announcement will give the > date, time, and location of this event. > The Contributor of the Year will receive a MacBook Pro. > > > We appreciate all the contributions of the Second Life open source > community, and we'll be listening to your feedback and recommendations > for improving the awards program for next year. Please add constructive > comments to this wiki > https://wiki.secondlife.com/wiki/Linden_Lab_Innovation_Awards. Any > questions, post them to sldev@lists.secondlife.com or email > liana@lindenlab.com. > > Thanks, > Liana > > - - - - - > > The LINDEN LAB INNOVATION AWARDS are for entertainment purposes only and > have no monetary or other value. LINDEN LAB, LINDEN RESEARCH, and SECOND > LIFE are trademarks or registered trademarks of Linden Research, Inc. > > From sllists at boroon.dasgupta.ch Mon Jul 23 14:55:58 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Jul 23 14:56:06 2007 Subject: [sldev] No sound on Linux Viewer when homebrewed Message-ID: <20070723235558.nznajq706co84w4o@datendelphin.net> With 1.18.0.6 I'm having sound when I use the official binary download. However, when I build from source, there's no sound at all (be it UI or Inworld) in the viewer. I haven't set FMOD=NO and the fmod libary is in place. I can't remember to have had this problem with versions previous to 1.18.0.* Is this some bug or am I doing something wrong? Boroondas ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070723/55e93eb8/attachment.htm From seg at haxxed.com Mon Jul 23 14:56:16 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jul 23 15:01:17 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723103329.GB7339@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> Message-ID: <1185227776.25858.192.camel@localhost.localdomain> On Mon, 2007-07-23 at 12:33 +0200, Dale Glass wrote: > On Mon, Jul 23, 2007 at 12:28:12PM +0200, Nicholaz Beresford wrote: > > > > What kind of date string do you get there? (Do the > > Lindens really just send a string for the avatar?) > Yep, the date as it appears in the profile. This kind of thing is bad from an internationalization point of view, you either have to push i18n into the backend or hackishly re-parse it on the front end. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/ef456058/attachment.pgp From secret.argent at gmail.com Mon Jul 23 15:49:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 23 15:49:25 2007 Subject: [sldev] Re: "scripting the user interface" jira (Dzonatas) In-Reply-To: <46A2EE28.4000504@gmail.com> References: <20070721190009.E713641B055@stupor.lindenlab.com> <615A3672-434C-4213-B7C7-78BF3B5ECC33@gmail.com> <46A2EE28.4000504@gmail.com> Message-ID: <550E3EC2-99ED-4D16-AE92-27691503A25A@gmail.com> On 22-Jul-2007, at 00:42, Tateru Nino wrote: > Genesis/ColdC comes immediately to mind: http://cold.org/coldc/ Like I said, there are a number of MUD/MUSH/MUCK/MOO/... runtimes, and the ones I've looked at aren't designed to provide real-time response for thousands of concurrently active scripts. And I don't see anything like that in the ColdC feature list. From secret.argent at gmail.com Mon Jul 23 16:11:03 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 23 16:10:58 2007 Subject: [sldev] Re: Can I include source licensed under the 3-clause BSD? (Dale Glass) In-Reply-To: <20070723150405.6C1F241B038@stupor.lindenlab.com> References: <20070723150405.6C1F241B038@stupor.lindenlab.com> Message-ID: Since the "modified BSD license" allows you to take the code proprietary, let alone GPL, so long as you retain it intact... you should be able to contribute it yourself under your own code contribution agreement with Linden Labs. From secret.argent at gmail.com Mon Jul 23 16:19:24 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jul 23 16:19:19 2007 Subject: [sldev] Re: SLDev Digest, Vol 7, Issue 110 In-Reply-To: <20070723190010.2766941B088@stupor.lindenlab.com> References: <20070723190010.2766941B088@stupor.lindenlab.com> Message-ID: <6055EB12-84EA-4556-AE0F-625E672F327F@gmail.com> Farallon Greyskin writes: > Not to mention that writing in single platform only code is going > to be a > BIG no-no. > > SL has gone to great lengths to make this code cross platform, the > last > thing we want to do is start fracturing it on an OS basis... > Especially if > you did plan on it being merged with the main code base. As long as > it has > to be rewritten for another platform it should be written cross > platform to > begin with. I'm not sure what you're referring to here, but the point of including the BSD licensed code is to make it *less* platform dependent. There are basically three alternatives: 1. Write code that uses the POSIX standard strptime() routine, that's available on all platforms except strict Win32 without Microsoft's enhanced POSIX subsystem (Interix), and include a platform- independent implementation of that routine. 2. Write code that calls strptime() on POSIX and some comparable Win32 call on Windows, with the possibility that it might parse some date differently on Windows and other platforms. 3. Implement a subset of strptime() by hand, with the possibility that it will not be able to parse some date provided in the future... or alternatively that it would lock Linden Labs into a limited date format. The first, truly, is the least platform-dependent. From dale at daleglass.net Mon Jul 23 17:16:53 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 23 17:16:59 2007 Subject: [sldev] No sound on Linux Viewer when homebrewed In-Reply-To: <20070723235558.nznajq706co84w4o@datendelphin.net> References: <20070723235558.nznajq706co84w4o@datendelphin.net> Message-ID: <20070724001653.GC19033@bruno.sbruno> On Mon, Jul 23, 2007 at 11:55:58PM +0200, Boroondas Gupte wrote: > > > With 1.18.0.6 I'm having sound when I use the official binary > download. However, when I build from source, there's no sound at all > (be it UI or Inworld) in the viewer. I haven't set FMOD=NO and the > fmod libary is in place. I can't remember to have had this problem > with versions previous to 1.18.0.* > > Is this some bug or am I doing something wrong? OPENSOURCE=yes is now set by default, and that disables FMOD. Got to compile with OPENSOURCE=no for it to work. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070724/ddc960be/attachment-0001.pgp From dzonatas at dzonux.net Mon Jul 23 17:37:58 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jul 23 17:37:38 2007 Subject: [sldev] OpenJPEG crash on x86_64 Message-ID: <46A549E6.2050703@dzonux.net> Bringing attention to: https://jira.secondlife.com/browse/VWR-1864 2007-07-23T02:19:45Z INFO: onBakedTextureMasksLoaded(): unexpected image id: 1af46d96-b5af-bfa9-1707-9a9af1fcca0d Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1098926400 (LWP 27804)] 0x00002b38a56f1bdf in dwt_decode_tile () from ... This happened on a x86_64 machine. Can anybody reproduce? -- Power to Change the Void From dale at daleglass.net Mon Jul 23 18:23:17 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jul 23 18:23:33 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <1185227776.25858.192.camel@localhost.localdomain> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <1185227776.25858.192.camel@localhost.localdomain> Message-ID: <20070724012317.GD19033@bruno.sbruno> On Mon, Jul 23, 2007 at 04:56:16PM -0500, Callum Lerwick wrote: > On Mon, 2007-07-23 at 12:33 +0200, Dale Glass wrote: > > On Mon, Jul 23, 2007 at 12:28:12PM +0200, Nicholaz Beresford wrote: > > > > > > What kind of date string do you get there? (Do the > > > Lindens really just send a string for the avatar?) > > Yep, the date as it appears in the profile. > > This kind of thing is bad from an internationalization point of view, > you either have to push i18n into the backend or hackishly re-parse it > on the front end. I don't think there was any the last time I looked. And that makes for a lot of confused people as the MM/DD/YYYY format is a rather strange one. LLSD seems to support dates though, which probably would be the best to do it. But, the whole thing is rather crusty. http://doc.daleglass.net/llpanelavatar_8cpp-source.html#l01786 See for example the whole mess with the CharterMember part of the message. If length is 1, then it's a byte corresponding to an enum of the account type. If longer, then it gets interpreted as a string, for a custom title. The name "CharterMember" leads me to believe that it started as a boolean value, then was adapted to handle additional account types, then the account title hack was added. > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070724/06f9c50c/attachment.pgp From seg at haxxed.com Mon Jul 23 21:44:45 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jul 23 21:49:54 2007 Subject: [sldev] OpenJPEG crash on x86_64 In-Reply-To: <46A549E6.2050703@dzonux.net> References: <46A549E6.2050703@dzonux.net> Message-ID: <1185252285.25858.201.camel@localhost.localdomain> On Mon, 2007-07-23 at 17:37 -0700, Dzonatas wrote: > Bringing attention to: https://jira.secondlife.com/browse/VWR-1864 > > 2007-07-23T02:19:45Z INFO: onBakedTextureMasksLoaded(): unexpected image > id: 1af46d96-b5af-bfa9-1707-9a9af1fcca0d > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1098926400 (LWP 27804)] > 0x00002b38a56f1bdf in dwt_decode_tile () from ... > > This happened on a x86_64 machine. Can anybody reproduce? Works fine here. Not very useful without a line number. OpenJPEG appears to be statically linked, and stripped of debug info. Does VWR-1475 help at all? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070723/916e3220/attachment.pgp From nicholaz at blueflash.cc Tue Jul 24 00:56:41 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 24 00:56:54 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070724012317.GD19033@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <1185227776.25858.192.camel@localhost.localdomain> <20070724012317.GD19033@bruno.sbruno> Message-ID: <46A5B0B9.4040601@blueflash.cc> Dale Glass wrote: > This kind of thing is bad from an internationalization point of view, > you either have to push i18n into the backend or hackishly re-parse it > on the front end. Well, as long as they don't change it, it's as good as any defined way to transfer the date. I don't see more hackish reparse for this format compared to let's say yyyy-mm-dd In fact it's a lot better than doing internationalisation on the back end, because in that case Dale would have to deal with 10 possible variants for his calculations. Nick From seg at haxxed.com Tue Jul 24 02:36:53 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jul 24 02:42:07 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <46A5B0B9.4040601@blueflash.cc> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <1185227776.25858.192.camel@localhost.localdomain> <20070724012317.GD19033@bruno.sbruno> <46A5B0B9.4040601@blueflash.cc> Message-ID: <1185269813.25858.213.camel@localhost.localdomain> On Tue, 2007-07-24 at 09:56 +0200, Nicholaz Beresford wrote: > Well, as long as they don't change it, it's as good as any defined way to > transfer the date. I don't see more hackish reparse for this format > compared to let's say yyyy-mm-dd I was thinking more along the lines of an integer "days since epoch", of which I'm sure Windows has a perfectly reasonable API with which to deal with such a thing... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070724/6c282608/attachment.pgp From dale at daleglass.net Tue Jul 24 02:50:42 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 24 02:50:49 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <1185269813.25858.213.camel@localhost.localdomain> References: <20070723101014.GA7339@bruno.sbruno> <46A482BC.9010309@blueflash.cc> <20070723103329.GB7339@bruno.sbruno> <1185227776.25858.192.camel@localhost.localdomain> <20070724012317.GD19033@bruno.sbruno> <46A5B0B9.4040601@blueflash.cc> <1185269813.25858.213.camel@localhost.localdomain> Message-ID: <20070724095041.GA5550@bruno.sbruno> On Tue, Jul 24, 2007 at 04:36:53AM -0500, Callum Lerwick wrote: > On Tue, 2007-07-24 at 09:56 +0200, Nicholaz Beresford wrote: > > Well, as long as they don't change it, it's as good as any defined way to > > transfer the date. I don't see more hackish reparse for this format > > compared to let's say yyyy-mm-dd > > I was thinking more along the lines of an integer "days since epoch", of > which I'm sure Windows has a perfectly reasonable API with which to deal > with such a thing... Why do that, when there is this? http://wiki.secondlife.com/wiki/LLSD#date -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070724/504e86f1/attachment.pgp From nicholaz at blueflash.cc Tue Jul 24 05:10:58 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 24 05:11:05 2007 Subject: [sldev] comments on patch for VWR-423 In-Reply-To: <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> References: <20070723101014.GA7339@bruno.sbruno><46A482BC.9010309@blueflash.cc><20070723103329.GB7339@bruno.sbruno><46A48844.8030705@blueflash.cc><20070723112603.GA19033@bruno.sbruno><46A49271.2020809@blueflash.cc> <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> Message-ID: <46A5EC52.7060601@blueflash.cc> Ham I was looking over the patch (just the patch, didn't apply it) but it somehow seems like it tries to fix things on both ends. I'm not sure which approach I'd be choosing but I usually go for minimum source impact and minimum side effect, so I'd probably just do the isTextChanged trick. But as said, I have not looked at the specifics. Also, there are a couple of lines in the patch with trailing spaces or tabs which make the patch a bit harder to read than necessary. (1st hunk) - mWText = utf8str_to_wstring(mUTF8Text); + mWText = utf8str_to_wstring(mUTF8Text); (2nd hunk) - setText(value.asString()); + setText(value.asString()); (3rd hunk odd curlys) - if (mCommitOnFocusLost) + if (!mReadOnly && mCommitOnFocusLost && isTextChanged()) { - onCommit(); + { + onCommit(); + } } and again trailing tabs in texteditor.h @@ -340,7 +341,8 @@ - mutable LLString mUTF8Text; + LLWString mWPrev; + mutable LLString mUTF8Text; Nick ham wrote: > Hi all. I've attached a patch to VWR-423 to cover both VWR-423 and > VWR-1187. > I've tested on a windows build using 1.18, but would like some more eyes on > it since this is my first patch. VWR-423 is "Selecting group charter text > causes Apply/Ignore/Cancel popup even if the text wasn't changed" and > VWR-1187 is "Profile > Classifieds tab shows confirmation dialog when no > changes are made" > > http://jira.secondlife.com/browse/VWR-423 > http://jira.secondlife.com/browse/VWR-1187 > > There are two types of fixes here. For the first change LLTextEditor now > only calls onCommit within LLTextEditor::onFocusLost if the text has > changed > (similar to how LLLineEditor handle it). > > The other changes are to filter calls to onFocusReceived in > LLPanelClassified, LLPanelGroupRolesSubTab and LLPanelGroupGeneral. > There is > an assumption made in the code for LLUICtrl::setFocus that disabled > (readonly) controls never get the focus and hence never will call > onFocusReceived. > > You cannot disable the LLTextEditor when setting read only because that > would take away the ability for users to scroll long text (such as no copy > notecard). So all that to say...that the onFocusReceived and some onCommit > calls had to filtered to make sure if onCommit is being called that the > user > has the rights to change and that in fact the text is changed. > > By itself, this fix won't affect performance of one viewer but I would > imagine with all the update messages not happening, this change will help > overall scale. One example this will help is that spurious PickInfoUpdate > messages that were being generated just by clicking the description of > someone else's Picks and losing focus. > > Anywho...let me know if you have any problems or questions if you > incorporate this patch. > > thanks, > > Jon Price/Hamncheese Omlet > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From alissa_sabre at yahoo.co.jp Tue Jul 24 07:16:38 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Jul 24 07:36:53 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723101014.GA7339@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> Message-ID: <1ef4ds4ds4dv9ds4er494.alissa_sabre@yahoo.co.jp> Hmmmmmm. > > > I use strptime > > What kind of date string do you get there? (Do the > > Lindens really just send a string for the avatar?) > Yep, the date as it appears in the profile. I'd like to point out that the _feature_ that the date string is always formatted in American style is filed as a bug (VWR-721), and I support the idea that viewers show date strings in a localized format. For now, I don't know how we can achieve this, but I feel uncomfortable that you are adding a new feature that presumes the date string is always in American format. # strptime has a feature that parses the given string in an locale dependent manner, but it may or may not compatible between systems, or a given locale data may not exist on the OS. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From alissa_sabre at yahoo.co.jp Tue Jul 24 06:32:42 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Jul 24 07:36:57 2007 Subject: [sldev] comments on patch for VWR-423 In-Reply-To: <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> <20070723190010.43F0441B08B@stupor.lindenlab.com> References: <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> Message-ID: <2tJ8soark8rkcrQ8tG8rkhf.alissa_sabre@yahoo.co.jp> > I've attached a patch to VWR-423 to cover both VWR-423 and VWR-1187. Thank you for the effort! > would like some more eyes on > it since this is my first patch. I glanced at the patch and noticed that you forgot another change. I added a comment on JIRA. # I've just glanced; not tested... Other comments: - Please be more specific on the source version that your patch is against. Indicate "1.18.0.6" instead of "1.18" in this case. - Use of full path names with DOS drive letter for the patched files confused my tools... It is appreciated if you use relative paths without drive letters next time. - You made some white-space-only change on the source. It makes the patch redundant. Please revert those changes before submission, or enable "ignore white-space-only changes" on your diff tool. Hope this helps, Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From dale at daleglass.net Tue Jul 24 07:47:43 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jul 24 07:47:53 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <1ef4ds4ds4dv9ds4er494.alissa_sabre@yahoo.co.jp> References: <20070723101014.GA7339@bruno.sbruno> <1ef4ds4ds4dv9ds4er494.alissa_sabre@yahoo.co.jp> Message-ID: <20070724144743.GA8439@bruno.sbruno> On Tue, Jul 24, 2007 at 11:16:38PM +0900, Alissa Sabre wrote: > Hmmmmmm. > > > > > I use strptime > > > > What kind of date string do you get there? (Do the > > > Lindens really just send a string for the avatar?) > > > Yep, the date as it appears in the profile. > > I'd like to point out that the _feature_ that the date string is > always formatted in American style is filed as a bug (VWR-721), and I > support the idea that viewers show date strings in a localized > format. > > For now, I don't know how we can achieve this, but I feel > uncomfortable that you are adding a new feature that presumes the date > string is always in American format. Well, I suggested it several times already: The grid should send the date using the functionality in LLSD for doing so, then it can be transformed into a localized format client-side. But meanwhile, I have to use what I have. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070724/6235083e/attachment-0001.pgp From me at hamncheeseomlet.com Tue Jul 24 08:17:47 2007 From: me at hamncheeseomlet.com (ham) Date: Tue Jul 24 08:17:52 2007 Subject: [sldev] comments on patch for VWR-423 References: <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> <2tJ8soark8rkcrQ8tG8rkhf.alissa_sabre@yahoo.co.jp> Message-ID: Thanks for the responses Nick and Alissa. >Use of full path names with DOS drive letter for the patched files >confused my tools... It is appreciated if you use relative paths > without drive letters next time. I'm using the cygwin tool on my c: drive and the code is on my d: drive and unfortunately i've only used ClearCase and StarTeam which does the merging for you and you just confirm visually if there is a question. I'm new at using this kind of tool for diffs so I apologize. I didn't realize that where my code is stored made a difference to others downstream when applying the patch so if anyone would be kind enough to respond either on list or off doesn't matter to me and help me make this change I would be extremely grateful :) I will clean up the whitespace issue and don't need help with that. I have a couple of other changes based on Nicks's feedback so I'll post a new patch. I've put a note on jira as well. ----- Original Message ----- From: Alissa Sabre To: sldev@lists.secondlife.com Sent: Tuesday, July 24, 2007 9:32 AM Subject: Re: [sldev] comments on patch for VWR-423 > I've attached a patch to VWR-423 to cover both VWR-423 and VWR-1187. Thank you for the effort! > would like some more eyes on > it since this is my first patch. I glanced at the patch and noticed that you forgot another change. I added a comment on JIRA. # I've just glanced; not tested... Other comments: - Please be more specific on the source version that your patch is against. Indicate "1.18.0.6" instead of "1.18" in this case. - Use of full path names with DOS drive letter for the patched files confused my tools... It is appreciated if you use relative paths without drive letters next time. - You made some white-space-only change on the source. It makes the patch redundant. Please revert those changes before submission, or enable "ignore white-space-only changes" on your diff tool. Hope this helps, Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Tue Jul 24 09:13:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jul 24 09:13:36 2007 Subject: [sldev] comments on patch for VWR-423 In-Reply-To: References: <9BF3BBED5E894DF98A23A06991A93646@ad.reyrey.com> <2tJ8soark8rkcrQ8tG8rkhf.alissa_sabre@yahoo.co.jp> Message-ID: <46A62517.70807@blueflash.cc> > I'm new at using this kind of tool for diffs so I apologize. I didn't > realize that where my code is stored made a difference to others > downstream when applying the patch so if anyone would be kind enough to > respond either on list or off doesn't matter to me and help me make this > change I would be extremely grateful :) Not a biggie, just something that's helpful for other to appy. Just chdir into the d: path where you see the linden path if you type dir and call c:\cygwin\bin\diff -u from there. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From bridie at lindenlab.com Tue Jul 24 10:51:43 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Tue Jul 24 10:51:45 2007 Subject: [sldev] Announcing Another Bug Triage Meeting! Message-ID: <055D4C60-C635-4B8D-9AC6-38D67BFDC91F@lindenlab.com> Following the lead of Rob Linden and Benjamin Linden, I'll be starting my own weekly bug triages focusing on Viewer Crashes. I created a new filter in the Issue Tracker titled (appropriately!) "Viewer Crashes". We'll be looking through issues that have not already been imported into Linden Lab's internal issue tracker, sorted by priority. The Viewer Crashes bug triage will be on Wednesdays at 3:00 pm at my house in Linden Village. We'll use the same general process the other triages have been following. Minutes and transcripts from the triage will be posted to the Wiki after each triage. I?ll be your host, but expect to see other Lindens make appearances and help out. The first Viewer Crashes bug triage will be held Wednesday, July 25th. I could really use some help with the agenda for this first triage. Any volunteers? Thanks! --Bridie Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070724/f9e4a8ee/attachment.htm From gigstaggart at gmail.com Tue Jul 24 11:25:03 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jul 24 11:25:08 2007 Subject: [sldev] Re: Can I include source licensed under the 3-clause BSD? (Dale Glass) In-Reply-To: References: <20070723150405.6C1F241B038@stupor.lindenlab.com> Message-ID: <46A643FF.6060605@gmail.com> Argent Stonecutter wrote: > Since the "modified BSD license" allows you to take the code > proprietary, let alone GPL, so long as you retain it intact... you > should be able to contribute it yourself under your own code > contribution agreement with Linden Labs. While this would probably be OK in practice, legally you don't have the right to grant or represent the things the contribution agreement requires you to do for BSD licensed code, or any code you don't actually own the copyright on. Taking BSD code proprietary doesn't actually change its license, and taking BSD code into a GPL work doesn't make that BSD code GPL either. The derived work is indeed GPL, but the BSD bits are still BSD (and you still must comply with the 3 clauses). So really, until LL says it's OK, I wouldn't do this. -Jason From jianr3n at gmail.com Tue Jul 24 20:37:31 2007 From: jianr3n at gmail.com (jianren chua) Date: Tue Jul 24 20:37:38 2007 Subject: [sldev] Ball kicking Message-ID: <76d226120707242037n5341ec19s7f97fc760f02b928@mail.gmail.com> Hi all, is it possible to make the avatar in 2nd life to kick a ball? ?? ?? ? -- Jr Time aNd t|de waIt f0r No mAn, St0p t|me! ~Life is for now, work is for later~ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070725/ac927bd3/attachment.htm From A.J.Delaney at brighton.ac.uk Tue Jul 24 06:14:04 2007 From: A.J.Delaney at brighton.ac.uk (A.J.Delaney@brighton.ac.uk) Date: Wed Jul 25 00:52:47 2007 Subject: [sldev] Script to build "open source" client Message-ID: <1185282844.12861.27.camel@localhost> Dear all, We've been using a script internally to build SL viewer from _only_ open source components (i686-linux and ia64-linux). This means no FMOD or JPEG 2000 library. We're actually using it to build a GStreamer backend for SL to support codecs other than QuickTime. There are several "internalisms" in the script, particularly to do with patching prereqs. But all the patches are floating around the Interweb somewhere (we just patched some of them first). We've been really slow about punting stuff out of here, so attached is the script, warts-and-all. There is another script on the Linux build side of the wiki, but that uses the pre-rolled Linden support binaries. So consider this script complementary (we'll merge them in time) not a competitor (the other script is actually better written :)). -- Aidan Delaney -------------- next part -------------- A non-text attachment was scrubbed... Name: get_and_compile_sl.sh Type: application/x-shellscript Size: 4953 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070724/db1bbfb9/get_and_compile_sl.bin From A.J.Delaney at brighton.ac.uk Tue Jul 24 07:43:12 2007 From: A.J.Delaney at brighton.ac.uk (A.J.Delaney@brighton.ac.uk) Date: Wed Jul 25 00:52:51 2007 Subject: [sldev] llresolv6 code Message-ID: <1185288192.12861.29.camel@localhost> Hey all, Where's the code for llresolv6? -- Aidan Delaney From sllists at boroon.dasgupta.ch Wed Jul 25 01:28:43 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed Jul 25 01:28:56 2007 Subject: [sldev] No sound on Linux Viewer when homebrewed In-Reply-To: <20070724001653.GC19033@bruno.sbruno> References: <20070723235558.nznajq706co84w4o@datendelphin.net> <20070724001653.GC19033@bruno.sbruno> Message-ID: <20070725102843.0o3ecmpv0gw88osg@datendelphin.net> Zitat von Dale Glass : > > OPENSOURCE=yes is now set by default, and that disables FMOD. Got to > compile with OPENSOURCE=no for it to work. > Thanks alot, this was it :-) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070725/348ac06d/attachment.htm From tofu.linden at lindenlab.com Wed Jul 25 03:18:07 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed Jul 25 03:18:08 2007 Subject: [sldev] llresolv6 code In-Reply-To: <1185288192.12861.29.camel@localhost> References: <1185288192.12861.29.camel@localhost> Message-ID: <46A7235F.40709@lindenlab.com> A.J.Delaney@brighton.ac.uk wrote: > Hey all, > Where's the code for llresolv6? It's ISC BIND - https://wiki.secondlife.com/wiki/Building_libllresolv -Tofu From tofu.linden at lindenlab.com Wed Jul 25 03:58:39 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed Jul 25 03:58:40 2007 Subject: [sldev] Script to build "open source" client In-Reply-To: <1185282844.12861.27.camel@localhost> References: <1185282844.12861.27.camel@localhost> Message-ID: <46A72CDF.6080904@lindenlab.com> A.J.Delaney@brighton.ac.uk wrote: > Dear all, > We've been using a script internally to build SL viewer from _only_ > open source components (i686-linux and ia64-linux). This means no FMOD > or JPEG 2000 library. We're actually using it to build a GStreamer > backend for SL to support codecs other than QuickTime. FYI, GStreamer video support will be in the next trunk-based Linden source-drop - which should be very soon. I expect there are plenty of ways in which it could be improved though, if you are experienced with GStreamer and want to help out! -Tofu From jorrit.tyberghein at gmail.com Wed Jul 25 05:06:39 2007 From: jorrit.tyberghein at gmail.com (Jorrit Tyberghein) Date: Wed Jul 25 05:06:44 2007 Subject: [sldev] Using Crystal Space as a 3D client for Second Life Message-ID: Hi, I'm the project manager of Crystal Space (http://www.crystalspace3d.org). Crystal Space is an Open Source 3D engine that runs on GNU/Linux, Windows, and MacOS/X. We support OpenGL and have a lot of features. I feel that Crystal Space would be an idea engine for using on the client side of Second Life. We support dynamically creating content very easily and are very flexible with regards to rendering and support for 3D hardware (from low-end to high-end). I'm too busy to actively help making such a client myself but I would actively support any attempt at doing so. Greetings, -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=649 From vac at tid.es Wed Jul 25 06:23:16 2007 From: vac at tid.es (Vanessa Alvarez Colina) Date: Wed Jul 25 06:25:40 2007 Subject: [sldev] Avatar's movement on LibSecondLife Message-ID: <46A74EC4.5060900@tid.es> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: vac.vcf Type: text/x-vcard Size: 274 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070725/667c74e4/vac.vcf From labrat.hb at gmail.com Wed Jul 25 10:15:20 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Jul 25 10:15:24 2007 Subject: [sldev] Script to build "open source" client In-Reply-To: <46A72CDF.6080904@lindenlab.com> References: <1185282844.12861.27.camel@localhost> <46A72CDF.6080904@lindenlab.com> Message-ID: On 7/25/07, Tofu Linden wrote: > A.J.Delaney@brighton.ac.uk wrote: > > Dear all, > > We've been using a script internally to build SL viewer from > _only_ > > open source components (i686-linux and ia64-linux). This means no FMOD > > or JPEG 2000 library. We're actually using it to build a GStreamer > > backend for SL to support codecs other than QuickTime. > > FYI, GStreamer video support will be in the next trunk-based Linden > source-drop - which should be very soon. I expect there are plenty of > ways in which it could be improved though, if you are experienced with > GStreamer and want to help out! > > -Tofu Would this be for all platforms? As a quick look at the GStreamer site shows that it can be compiled for Windows as well OSX and Linux. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070725/8d51fa4a/attachment-0001.htm From soft at lindenlab.com Wed Jul 25 10:30:04 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jul 25 10:30:12 2007 Subject: [sldev] SLDev-Traffic #21 Message-ID: <9e6e5c9e0707251030p77bea9cdg333f471449c764ff@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_21 SLDev-Traffic number 21 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From Dana.Fagerstrom at Sun.COM Wed Jul 25 11:29:59 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Wed Jul 25 11:28:37 2007 Subject: [sldev] Script to build "open source" client In-Reply-To: References: <1185282844.12861.27.camel@localhost> <46A72CDF.6080904@lindenlab.com> Message-ID: <46A796A7.7090504@sun.com> GStreamer would be a win on Solaris too. I just wanted to make sure you got my vote as well :) D Harold Brown wrote: > On 7/25/07, *Tofu Linden* > wrote: > > A.J.Delaney@brighton.ac.uk wrote: > > Dear all, > > We've been using a script internally to build SL viewer > from _only_ > > open source components (i686-linux and ia64-linux). This means > no FMOD > > or JPEG 2000 library. We're actually using it to build a GStreamer > > backend for SL to support codecs other than QuickTime. > > FYI, GStreamer video support will be in the next trunk-based Linden > source-drop - which should be very soon. I expect there are plenty of > ways in which it could be improved though, if you are experienced with > GStreamer and want to help out! > > -Tofu > > > Would this be for all platforms? As a quick look at the GStreamer site > shows that it can be compiled for Windows as well OSX and Linux. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- ===================================================================== Dana Fagerstrom Phone: 877.851.6343 Sun Services Fax: 877.851.6343 400 Atrium Dr. Email: dana.fagerstrom@Sun.COM Somerset, NJ 08873 SneakerNet: USMT01 ===================================================================== Pressure - It can turn a lump of coal into a flawless diamond, and an average person into a perfect basketcase. -- www.despair.com ===================================================================== From gigstaggart at gmail.com Wed Jul 25 12:48:49 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jul 25 12:48:53 2007 Subject: [sldev] VWR-1217 Jerky animations Message-ID: <46A7A921.4090109@gmail.com> I've been told that VWR-1217 (jerky animation fade outs) is back in the newest first look, can anyone running that confirm? From soft at lindenlab.com Wed Jul 25 16:23:19 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jul 25 16:23:21 2007 Subject: [sldev] Thursday open source meeting agenda Message-ID: <9e6e5c9e0707251623l3cfdff66rc44fa8196dccbf28@mail.gmail.com> If there's something you'd like to discuss during tomorrow's open source office hours, please feel free to add it to the wiki page: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Rob and Liana are at OSCON, leaving me. I'll see if I can round up a couple programmers related to specific subsystems if there's interest in specific sim/viewer topics. From soft at lindenlab.com Wed Jul 25 16:26:25 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jul 25 16:26:27 2007 Subject: [sldev] VWR-1217 Jerky animations In-Reply-To: <46A7A921.4090109@gmail.com> References: <46A7A921.4090109@gmail.com> Message-ID: <9e6e5c9e0707251626g1a0f84b7y35f176f1c44a22b7@mail.gmail.com> A resident pinged me about this previously and I verified it with the bHear team. Their branch missed or reverted a few changes from the mainline. I believe it's already fixed for the next build. On 7/25/07, Jason Giglio wrote: > I've been told that VWR-1217 (jerky animation fade outs) is back in the > newest first look, can anyone running that confirm? From Paul.Hampson at Pobox.com Thu Jul 26 02:37:50 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Thu Jul 26 02:38:00 2007 Subject: [sldev] Debian 1.18.0.6 packages uploaded In-Reply-To: <20070722153725.GA1325@keitarou> References: <4695D527.6090808@gmail.com> <20070712123643.5t5h03w1s084kw04@datendelphin.net> <46963B7B.9040302@gmail.com> <20070714180001.GA20761@keitarou> <469BB19F.1000509@lindenlab.com> <20070717004704.GA20171@keitarou> <1184639588.31185.5.camel@localhost.localdomain> <20070717102705.GB23391@keitarou> <20070722153725.GA1325@keitarou> Message-ID: <20070726093750.GA26838@keitarou> On Mon, Jul 23, 2007 at 01:37:25AM +1000, Paul TBBle Hampson wrote: > This has reduced the build-time on my laptop to 1:50. I haven't tried a > fullly static build, but at some point over the last few releases I was > seeing consisten three hour build times. I've now done a fully-static build (by adding 'or True' to the if in build_cond_module) and it _also_ took 1:50. So I guess the shared-object change isn't at the root of this massive speed increase. So although I personally find the shared objects more aestheically pleasing, I don't have any good technical reason to prefer them. I'll wait to see what upstream has done in the next code-drop. > The above futzing also turned up a buglet, llui's files.list showed a > header file in the list, for some reason. Removing it had no apparently > ill effects, unless I'm overlooking something. This turns out to be already fixed, VWR-1704 > I also made more stuff pkgconfig'd [2], along the lines of the existing > pkgconfig stuff. (Thanks for that, by the way. It integrated a lot more > cleanly than my own changes did) Submitted to Jira, in case anyone's interested, VWR-1892 -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070726/c197b6e3/attachment.pgp From dzonatas at dzonux.net Thu Jul 26 07:14:49 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 26 07:14:19 2007 Subject: [sldev] Intel TBB is compatible with Second Life! Message-ID: <46A8AC59.6070204@dzonux.net> I just read over the announcement. I'd imagine this is also has been announced at OSCON. Here is a license explanation for Intel's Threading Building Blocks: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html It's Open Source...and available now: http://threadingbuildingblocks.org/ -- Power to Change the Void From soft at lindenlab.com Thu Jul 26 11:41:59 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Jul 26 11:42:01 2007 Subject: [sldev] Intel TBB is compatible with Second Life! In-Reply-To: <46A8AC59.6070204@dzonux.net> References: <46A8AC59.6070204@dzonux.net> Message-ID: <9e6e5c9e0707261141t5ad8ae23la39d5a1f58af441d@mail.gmail.com> On 7/26/07, Dzonatas wrote: > I just read over the announcement. I'd imagine this is also has been > announced at OSCON. > > Here is a license explanation for Intel's Threading Building Blocks: > > http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html > > It's Open Source...and available now: http://threadingbuildingblocks.org/ A little birdie strongly hinted that this was coming, and a couple of us have watched with interest. :) If anyone sees a strong case for using this in specific areas, this would be a great conversation to have on sldev. From dzonatas at dzonux.net Thu Jul 26 11:54:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jul 26 11:53:37 2007 Subject: [sldev] Intel TBB is compatible with Second Life! In-Reply-To: <9e6e5c9e0707261141t5ad8ae23la39d5a1f58af441d@mail.gmail.com> References: <46A8AC59.6070204@dzonux.net> <9e6e5c9e0707261141t5ad8ae23la39d5a1f58af441d@mail.gmail.com> Message-ID: <46A8EDD1.4040406@dzonux.net> Soft Linden wrote: > If anyone sees a strong case for using this in specific areas, this > would be a great conversation to have on sldev. > I'm thinking by using it we could eliminate a few patent issues. I'll make some time to check into it more. I see that it can hot-switch thread models, but I wonder if that is limited to certain platforms. -- Power to Change the Void From jhurliman at wsu.edu Thu Jul 26 14:29:07 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Jul 26 14:29:05 2007 Subject: [sldev] Avatar's movement on LibSecondLife In-Reply-To: <46A74EC4.5060900@tid.es> References: <46A74EC4.5060900@tid.es> Message-ID: <46A91223.3050106@wsu.edu> Vanessa Alvarez Colina wrote: > Hello everyone , > > I am working with the libsecondlife but I have a big problem and the > problem is that I can't move my avatar with the libsecondlife where I > want to .. I mean that I use the method *" moveto x, y, z"* but my > avatar isn't moved to this point ... Anyone can help me ??? > > > Thanks in advance > > Vanessa libsecondlife actually maintains a separate mailing list at http://opensecondlife.org/cgi-bin/mailman/listinfo/libsl-dev which would be the best place to ask libsl-related questions, as this mailing list is focused on development of the Linden Labs SL client. To answer your question though the MoveTo() function is just a wrapper around the simulator-side autopilot function which is very rough at best. The SecondLife.Self.Status class contains everything to handle sending AgentUpdate packets which is the proper way to move around in the metaverse, although movement can be a very complex task to automate through software. John Hurliman From po at danielnylander.se Thu Jul 26 14:53:48 2007 From: po at danielnylander.se (Daniel Nylander) Date: Thu Jul 26 14:54:04 2007 Subject: [sldev] Translations Message-ID: <46A917EC.6040303@danielnylander.se> Hi all, I would like to translate SL to Swedish. I have started by translating the XML files (which might not be correct). Problem is that I have serious problems finding information on how to do this. Can someone help me shed some light on this? -- Daniel Nylander (CISSP, GCUX, GCFA) Stockholm, Sweden http://www.DanielNylander.se info@danielnylander.se yeager@ubuntu.com dnylande@gnome.org From nicholaz at blueflash.cc Thu Jul 26 15:34:44 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jul 26 15:34:51 2007 Subject: [sldev] Translations In-Reply-To: <46A917EC.6040303@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> Message-ID: <46A92184.7070501@blueflash.cc> I think there is already a swedish translation sitting on the bug tracker (look at the query "issues with patches attached"). Maybe you can proof read it or check it to see how it is done (basically you need to go to c:\program files\secondlife\skin\xui ... this is where the folders for the languages are). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Daniel Nylander wrote: > Hi all, > > I would like to translate SL to Swedish. I have started by translating > the XML files (which might not be correct). Problem is that I have > serious problems finding information on how to do this. > Can someone help me shed some light on this? > From iridium at lindenlab.com Thu Jul 26 15:55:02 2007 From: iridium at lindenlab.com (Iridium Linden) Date: Thu Jul 26 15:55:15 2007 Subject: [sldev] Introducing Internationalization Triage Message-ID: <46A92646.70107@lindenlab.com> Hiya Devs, Tomorrow, we'll host the first Internationalization bug triage. The agenda is up, and I'm about to post what I've pasted below to the blog. You get the sneak peak. Iridium The JIRA Bug Triage Lowdown: A recap of the oldies and introducing Internationalization Little did Linden Lab know that Bug Triages would take off the way they did. What's a triage you ask? Well every week, Benjamin , Bridie , and Rob Linden hold in-world office hours with other Lindens, including Torley , and Residents to discuss Second Life bugs and Resident-created feature suggestions that you generate in public JIRA . During these office hours, bugs and feature suggestions, some with patches created by rock star, Resident, open source stormers and some without patches, are imported into the Linden Lab JIRA so that developers can begin work immediately on what's important to you. Residents craft agendas for these triages, and we all sit down weekly to discuss and import issues at office hours. In the month of June, Torley reported that your JIRA bug-reporting helped Linden Lab developers and open source contributors fix 163 bugs out of 480 reported. Those may not seem like impressive numbers to you, but keep in mind that the trend matters. You're reporting more bugs and together, we're fixing more bugs. (For tips on bug reporting, see Torley's post "How to report better bugs." ) The triage enables Lindens and Residents to combine forces in order to fix bugs and think about which features are important to you. Because triages have become so useful, we've launched in this month alone a User Interface weekly bug triage and Viewer Crashes weekly bug triage ! Now it's time to welcome Internationalization to the triage family. More... This Friday, we'll introduce the latest in our series of bug triages, Internationalization . Second Life has a burgeoning international population. In recent months, we've created an International Liaison Specialist team , released the viewer in Japanese and Korean , created multi-language Orientation Island HUDs to guide new Residents, published "Linguistic QA with the Second Life Viewer " on the wiki, and most recently, we added an Italian Forum to the International section of our official forums. However, with multi-language viewers come bugs. Alissa Sabre has done an amazing job of calling our attention to various issues that affect the Second Life International and Open Source communities . It's time that we began fixing those bugs in accordance with Resident feedback. So join us this Friday at 10am SLTime at Iridium's Haven for our very first Internationalization Bug Triage! *More Information on JIRA and Bug Triages* Internationalization Bug Triage * We've created a bug triage filter for Internationalization in JIRA. Check it out! * The agenda has yet to be set, but watch the triage wiki for more information. * The triage will be held this Friday, July 27^th at 10am SLTime. Show up at Iridium's Haven in Beaumont (108, 151, 200)! At the moment, this triage will be held monthly (the last Friday of each month) since the current number of bugs is fairly minimal (this doesn't negate their importance though). Viewer Crashes Bug Triage * Check out the Viewer Crashes bug triage filter in JIRA. * Look at the latest Viewer Crashes triage agenda on the wiki. * This triage is held every Wednesday at 3pm SLTime. Show up at Bridie's home in Linden Village to attend! User Interface Bug Triage * The User Interface triage filter can be located in JIRA. Keep in mind that you'll need to log in before you can access the filter. * Check out the latest User Interface triage agenda and look at past notes and agendas to see what's been imported to Linden Lab's JIRA! * Benjamin Linden's User Interface triage is held every Tuesday at 10am SLTime. Show up at Benjamin's office to attend! General Bug Triage * Locate the most current agenda , which is Resident created, on the wiki . * Attend this general triage with Rob Linden every Monday at 3pm SLTime. Be there or be square! We look forward to seeing you at your friendly, Second Life neighborhood triage! -------------- next part -------------- Skipped content of type multipart/related From po at danielnylander.se Thu Jul 26 23:10:26 2007 From: po at danielnylander.se (Daniel Nylander) Date: Thu Jul 26 23:10:40 2007 Subject: [sldev] Translations In-Reply-To: <46A92184.7070501@blueflash.cc> References: <46A917EC.6040303@danielnylander.se> <46A92184.7070501@blueflash.cc> Message-ID: <46A98C52.4010405@danielnylander.se> Nicholaz Beresford skrev: > > I think there is already a swedish translation sitting > on the bug tracker (look at the query "issues with > patches attached"). Maybe you can proof read it or > check it to see how it is done (basically you need > to go to c:\program files\secondlife\skin\xui ... this > is where the folders for the languages are). Yes, I submitted that bugreport. Since I don't know if I have done everything correct, I'm not sure how to proceed. I noticed that the XML structure has slightly changed between versions and the static translation must be updated accordingly. Is there any tools for this or do I just have to spend hours to find the changed strings? It would be great if someone could create a wiki page or similar describing the work flow for translators. Localization is important. There is a massive interest in SL here in Sweden and a proper translation would be much appreciated. Here are some screenshots with the translation http://www.danielnylander.se/2007/05/18/oversattning-av-second-life/ -- Daniel Nylander (CISSP, GCUX, GCFA) Stockholm, Sweden http://www.DanielNylander.se info@danielnylander.se yeager@ubuntu.com dnylande@gnome.org From nicholaz at blueflash.cc Fri Jul 27 02:34:09 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 27 02:34:15 2007 Subject: [sldev] Translations In-Reply-To: <46A98C52.4010405@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> <46A92184.7070501@blueflash.cc> <46A98C52.4010405@danielnylander.se> Message-ID: <46A9BC11.1020405@blueflash.cc> Daniel Nylander wrote: > Yes, I submitted that bugreport. Since I don't know if I have done > everything correct, I'm not sure how to proceed. Oh dang, didn't notice the name. That must have been a lot of work man ... kudos for that! In everty time I'm seeing your submission in that list, it makes me want to grab a Linden by the shoulders and shake them. It really infuriates me to see good work (and I assume it is good, although I don't know a single word of Swedish) lie there and get stale. (although a few days ago Torley said on the JIRA in a comment there, that their internationalizon team is looking at it). In fact if my brain had worked properly, I would have nominated you for the Open Source award for "best contribution" because yours is easiest of one of those with the most time and efforts spent. (Pinging Lindens ... is there any chance of bending the rules and accepting a late nomination?) > I noticed that the XML structure has slightly changed between versions > and the static translation must be updated accordingly. Is there any > tools for this or do I just have to spend hours to find the changed > strings? It would be great if someone could create a wiki page or > similar describing the work flow for translators. Localization is important. If you want to bring it up to date, I can give you a basic rundown on the diff tool and you could create that page if you want. With that it'll be easy to check for the XUI differences between two versions. What you basically need to do is to download the Cygwin-tools (http://www.cygwin.com/) and install them (best go to c:\cygwin). Then you need copies of the two xui folders (oder version, newer version) in a folder next to each other, e.g. c:\translate\xui_1_15 and c:\translate\xui_1_18). Then you open a windows command prompt (Dos window) and type: c: cd \translate c:\cygwin\bin\diff -u --strip-trailing-cr xui_1_15 xui_1_18 >diff.txt This will create a file named diff.txt which will show you all files and locations and lines which have changed. Let me know if you need more details about using this tool. And maybe email Soft Linden (soft@lindenlabs.com) and ask he she can find the current status of your submission. Nick Nick From nicholaz at blueflash.cc Fri Jul 27 02:44:32 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 27 02:44:39 2007 Subject: [sldev] Translations In-Reply-To: <46A98C52.4010405@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> <46A92184.7070501@blueflash.cc> <46A98C52.4010405@danielnylander.se> Message-ID: <46A9BE80.3010001@blueflash.cc> Daniel Nylander wrote: > Yes, I submitted that bugreport. Since I don't know if I have done > everything correct, I'm not sure how to proceed. Oh, I guess you've seen it, but if not, check this post on their blog. http://blog.secondlife.com/2007/07/26/the-jira-bug-triage-lowdown-a-recap-of-the-oldies-and-introducing-internationalization/#comments If you have the time, go to the meeting and pester Iridium Linden about the issue. Nick From po at danielnylander.se Fri Jul 27 03:26:29 2007 From: po at danielnylander.se (Daniel Nylander) Date: Fri Jul 27 03:26:30 2007 Subject: [sldev] Translations In-Reply-To: <46A9BC11.1020405@blueflash.cc> References: <46A917EC.6040303@danielnylander.se> <46A92184.7070501@blueflash.cc> <46A98C52.4010405@danielnylander.se> <46A9BC11.1020405@blueflash.cc> Message-ID: <1185531989.9513.20.camel@greger> fre 2007-07-27 klockan 11:34 +0200 skrev Nicholaz Beresford: > Oh dang, didn't notice the name. That must have been a lot of > work man ... kudos for that! Oh yes :-) (actually, I have translated 1500+ open source applications in my "career") > c:\cygwin\bin\diff -u --strip-trailing-cr xui_1_15 xui_1_18 >diff.txt Excellent. I actually run Linux so that would make things easier. The problem I see is that when the XML structure is changed, the translations would be incomplete, which means that the user might not be able to see new functions or would see strange error messages. I'm not a developer but I'm involved in a lot of internationalization / localization projects such as the GNOME Desktop Environment and Ubuntu Linux. There must be some sort of centralized updates of these XML files to avoid distributing incomplete files. I would propose that someone put together a web service or application that would present the translatable strings to the translator. The translator could then translate whatever strings that are untranslated and then the application would generate new XML files. That would create complete files based on the latest XML structure. I guess that GNU gettext would be suitable for this. Regards, Daniel Nylander Stockholm, Sweden From nicholaz at blueflash.cc Fri Jul 27 03:35:45 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 27 03:35:57 2007 Subject: [sldev] Translations In-Reply-To: <1185531989.9513.20.camel@greger> References: <46A917EC.6040303@danielnylander.se> <46A92184.7070501@blueflash.cc> <46A98C52.4010405@danielnylander.se> <46A9BC11.1020405@blueflash.cc> <1185531989.9513.20.camel@greger> Message-ID: <46A9CA81.1040802@blueflash.cc> Daniel Nylander wrote: > Oh yes :-) > (actually, I have translated 1500+ open source applications in my > "career") Holy sh*t!! 8-) I've done a few translations and always hated it, but I guess other people hate looking for bugs or memory leaks :-) >> c:\cygwin\bin\diff -u --strip-trailing-cr xui_1_15 xui_1_18 >diff.txt > > Excellent. I actually run Linux so that would make things easier. Of course Linux has it already. On Linux you can most likely omit the --strip-trailing-cr parameter (you just need that if for some reason the diff reports the whole file changed because of a mix of Windows and Linux text file formats). But btw, make that diff -un instead of diff -u so you'll also get new files (files which did not exist in the old folder). Nick From dale at daleglass.net Fri Jul 27 04:04:57 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Jul 27 04:05:02 2007 Subject: [sldev] Translations In-Reply-To: <46A917EC.6040303@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> Message-ID: <20070727110457.GA29901@bruno.sbruno> On Thu, Jul 26, 2007 at 11:53:48PM +0200, Daniel Nylander wrote: > > Hi all, > > I would like to translate SL to Swedish. I have started by translating > the XML files (which might not be correct). Problem is that I have > serious problems finding information on how to do this. > Can someone help me shed some light on this? This reminds me of something I've been thinking about recently. I'm adding new features to my viewer, and that means new floaters, alerts, etc, I've only written the text in english so far. What would be needed is some sort of SL translation oriented website. I'm thinking something that parses the XML files and lets users submit translations, with perhaps with some sort of voting system. Note that I'm thinking about something somewhat different here -- not translating all of SL as a big chunk, but allowing to translate things in pieces, as I will keep developing, so new things to translate will appear, and old things might change. This should work fine on the official SL files though. By parsing the XML files and storing data on changes and such it'd be possible to easily determine what changed in a new release. This can't be a very unique problem to solve, so I'm thinking that perhaps there's software for this somewhere already, which could be adapted to SL. Maybe some sort of forum software or such could be adapted for this to save development time. I've got tons of other things to work ATM, but if nothing comes up I might give this a try eventually. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070727/663629c9/attachment.pgp From dale at daleglass.net Fri Jul 27 04:55:44 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Jul 27 04:55:50 2007 Subject: [sldev] Translations In-Reply-To: <20070727110457.GA29901@bruno.sbruno> References: <46A917EC.6040303@danielnylander.se> <20070727110457.GA29901@bruno.sbruno> Message-ID: <20070727115544.GA22995@bruno.sbruno> On Fri, Jul 27, 2007 at 01:04:57PM +0200, Dale Glass wrote: > What would be needed is some sort of SL translation oriented website. > I'm thinking something that parses the XML files and lets users submit > translations, with perhaps with some sort of voting system. Actually, n/m that. I just remembered that I hate using web apps, and hate coding them even more. I'll just put that into the viewer instead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070727/83f311b1/attachment.pgp From po at danielnylander.se Fri Jul 27 05:03:20 2007 From: po at danielnylander.se (Daniel Nylander) Date: Fri Jul 27 05:03:20 2007 Subject: [sldev] Translations In-Reply-To: <20070727110457.GA29901@bruno.sbruno> References: <46A917EC.6040303@danielnylander.se> <20070727110457.GA29901@bruno.sbruno> Message-ID: <1185537800.9513.28.camel@greger> fre 2007-07-27 klockan 13:04 +0200 skrev Dale Glass: > I'm adding new features to my viewer, and that means new floaters, > alerts, etc, I've only written the text in english so far. How about implementing support for intltool? That way you could add support for compiling the XML files from translated GNU gettext PO files. This also means that there will be no issues when changes are made in the original English templates. http://www.freedesktop.org/wiki/Software/intltool Regards, Daniel From alissa_sabre at yahoo.co.jp Fri Jul 27 05:26:34 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jul 27 05:26:51 2007 Subject: [sldev] Translations In-Reply-To: <46A917EC.6040303@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> Message-ID: <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> > I would like to translate SL to Swedish. I have started by translating > the XML files (which might not be correct). Problem is that I have > serious problems finding information on how to do this. > Can someone help me shed some light on this? http://wiki.secondlife.com/wiki/Linguistic_QA_with_the_Second_Life_Viewer # I have never translated XUI files, so I'm not sure the explained process really works fine... -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From po at danielnylander.se Fri Jul 27 05:48:14 2007 From: po at danielnylander.se (Daniel Nylander) Date: Fri Jul 27 05:48:08 2007 Subject: [sldev] Translations In-Reply-To: <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> References: <46A917EC.6040303@danielnylander.se> <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> Message-ID: <1185540494.9513.38.camel@greger> fre 2007-07-27 klockan 21:26 +0900 skrev Alissa Sabre: > http://wiki.secondlife.com/wiki/Linguistic_QA_with_the_Second_Life_Viewer > > # I have never translated XUI files, so I'm not sure the explained > process really works fine... Doing the actual translation is the simplest step in the process. The problem I'm facing is that I started to translate version 1_15_0_2 and the latest released version is 1_18_0_6. There are huge diffs in the XML files between these two versions. 19 files have been changed and the combined diff file is 4,249 lines long. Since it's not possible to automatically update a translated XML file (is there?), I have to do this manually (bye bye, spare time). Regards, Daniel Nylander Stockholm, Sweden From soft at lindenlab.com Fri Jul 27 09:23:14 2007 From: soft at lindenlab.com (Soft Linden) Date: Fri Jul 27 09:23:16 2007 Subject: [sldev] Translations In-Reply-To: <46A9BE80.3010001@blueflash.cc> References: <46A917EC.6040303@danielnylander.se> <46A92184.7070501@blueflash.cc> <46A98C52.4010405@danielnylander.se> <46A9BE80.3010001@blueflash.cc> Message-ID: <9e6e5c9e0707270923p4cb0a7c4h2f830da169c9ca26@mail.gmail.com> On 7/27/07, Nicholaz Beresford wrote: > Daniel Nylander wrote: > > Yes, I submitted that bugreport. Since I don't know if I have done > > everything correct, I'm not sure how to proceed. > > Oh, I guess you've seen it, but if not, check this post on their blog. > http://blog.secondlife.com/2007/07/26/the-jira-bug-triage-lowdown-a-recap-of-the-oldies-and-introducing-internationalization/#comments > > If you have the time, go to the meeting and pester Iridium Linden > about the issue. Please please consider doing this! Current policy is that we only accept patches against languages that are already supported - some of the language files will carry an annotation to this effect in a coming release to avoid anyone embarking on work that may not get used. The problem is that maintaining translations involves a lot of ongoing QA time, and right now we simply don't have the resources to support that. Two things: - If any of you have ideas on how we can better handle translation, especially by migrating to existing open source tools or lending expertise from past translation efforts, the triage would be a great place to start a discussion. If we can lower overhead, I'd hope we could get more languages in sooner. - More experienced QA engineers would help too! If any of you love Second Life and want a job in QA, or have friends with testing experience who do... having a couple extra languages under the belt would be a huge bonus, possibly sweetening the pot enough to warrant avoiding relocation. There's information about our QA processes at the QA portal... having some of that knowledge and being able to speak to related experience would be helpful if applying: https://wiki.secondlife.com/wiki/QA_Portal As for actually applying, there's information on lindenlab.com. A recognizable name from sldev or office hours really helps here. Don't be afraid to drop the names of Lindens with whom you've established a good rapport through past contributions. That can help squeeze you through HR filters. :) From nicholaz at blueflash.cc Fri Jul 27 10:11:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 27 10:11:59 2007 Subject: [sldev] Server/Grid unavailable? Message-ID: <46AA2759.7060109@blueflash.cc> Anyone else having problems connecting there? Tracing route to secondlife.com [66.150.244.168] over a maximum of 30 hops: 1 2 ms 2 ms 2 ms 192.168.0.1 2 49 ms 49 ms 50 ms 217.0.116.202 3 50 ms 48 ms 51 ms 217.0.76.146 4 54 ms 54 ms 52 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165] 5 53 ms 54 ms 52 ms Te-4-4.car2.Frankfurt1.Level3.net [4.68.110.253] 6 54 ms 54 ms 67 ms ae-32-52.ebr2.Frankfurt1.Level3.net [4.68.118.62] 7 54 ms 54 ms 67 ms ae-1-100.ebr1.Frankfurt1.Level3.net [4.69.132.125] 8 71 ms 72 ms 73 ms ae-2.ebr2.Paris1.Level3.net [4.69.132.141] 9 152 ms 143 ms 144 ms ae-5.ebr2.Washington1.Level3.net [4.69.132.113] 10 146 ms 144 ms 144 ms ae-72-72.csw2.Washington1.Level3.net [4.69.134.150] 11 155 ms 144 ms 144 ms ae-74-74.ebr4.Washington1.Level3.net [4.69.134.181] 12 223 ms 230 ms 234 ms ae-4.ebr3.LosAngeles1.Level3.net [4.69.132.81] 13 223 ms 221 ms 230 ms ae-2.ebr3.SanJose1.Level3.net [4.69.132.9] 14 230 ms 234 ms 234 ms ae-73-73.csw2.SanJose1.Level3.net [4.69.134.230] 15 234 ms 234 ms 234 ms ae-72-72.ebr2.SanJose1.Level3.net [4.69.134.213] 16 222 ms 222 ms 223 ms ae-4-4.car2.SanFrancisco1.Level3.net [4.69.133.157] 17 * * * Request timed out. 18 * * * Request timed out. -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Fri Jul 27 10:14:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jul 27 10:14:19 2007 Subject: [sldev] Server/Grid unavailable? In-Reply-To: <46AA2759.7060109@blueflash.cc> References: <46AA2759.7060109@blueflash.cc> Message-ID: <46AA280B.2000101@dzonux.net> Nicholaz Beresford wrote: > > Anyone else having problems connecting there? > http://blog.secondlife.com/2007/07/27/rolling-restart-beginning-at-930-pst/ -- Power to Change the Void From able.whitman at gmail.com Fri Jul 27 10:33:53 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jul 27 10:33:55 2007 Subject: [sldev] Server/Grid unavailable? In-Reply-To: <46AA280B.2000101@dzonux.net> References: <46AA2759.7060109@blueflash.cc> <46AA280B.2000101@dzonux.net> Message-ID: <7b3a84fb0707271033j75fc870ye2ed0a063f9b8871@mail.gmail.com> But a rolling restart should only intermittently affect the availability of certain regions, no? Logging into the grid should still work, I'd think. On 7/27/07, Dzonatas wrote: > > Nicholaz Beresford wrote: > > > > Anyone else having problems connecting there? > > > > http://blog.secondlife.com/2007/07/27/rolling-restart-beginning-at-930-pst/ > -- > Power to Change the Void > _______________________________________________ > 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/20070727/5be3e0ee/attachment.htm From marcus at electricsheepcompany.com Fri Jul 27 11:30:52 2007 From: marcus at electricsheepcompany.com (Marcus Welz) Date: Fri Jul 27 11:31:17 2007 Subject: [sldev] Server/Grid unavailable? In-Reply-To: <46AA2759.7060109@blueflash.cc> References: <46AA2759.7060109@blueflash.cc> Message-ID: <46AA39DC.1070409@electricsheepcompany.com> I am having the same issue. Tracing route to secondlife.com [66.150.244.169] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 42 ms 42 ms 42 ms 217.0.116.166 3 42 ms 42 ms 42 ms 217.0.68.230 4 48 ms 49 ms 48 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165] 5 49 ms 48 ms 49 ms Te-4-4.car2.Frankfurt1.Level3.net [4.68.110.253] 6 51 ms 53 ms 53 ms ae-32-56.ebr2.Frankfurt1.Level3.net [4.68.118.190] 7 63 ms 53 ms 53 ms ae-1-100.ebr1.Frankfurt1.Level3.net [4.69.132.125] 8 59 ms 71 ms 58 ms ae-2.ebr2.Paris1.Level3.net [4.69.132.141] 9 139 ms 143 ms 143 ms ae-5.ebr2.Washington1.Level3.net [4.69.132.113] 10 146 ms 143 ms 143 ms ae-92-92.csw4.Washington1.Level3.net [4.69.134.158] 11 139 ms 140 ms 144 ms ae-94-94.ebr4.Washington1.Level3.net [4.69.134.189] 12 * 216 ms 216 ms ae-4.ebr3.LosAngeles1.Level3.net [4.69.132.81] 13 210 ms 215 ms 215 ms ae-2.ebr3.SanJose1.Level3.net [4.69.132.9] 14 220 ms 216 ms 216 ms ae-83-83.csw3.SanJose1.Level3.net [4.69.134.234] 15 220 ms 216 ms 216 ms ae-82-82.ebr2.SanJose1.Level3.net [4.69.134.217] 16 212 ms 211 ms 324 ms ae-4-4.car2.SanFrancisco1.Level3.net [4.69.133.157] 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Nicholaz Beresford wrote: > > Anyone else having problems connecting there? > > Tracing route to secondlife.com [66.150.244.168] > over a maximum of 30 hops: > > 1 2 ms 2 ms 2 ms 192.168.0.1 > 2 49 ms 49 ms 50 ms 217.0.116.202 > 3 50 ms 48 ms 51 ms 217.0.76.146 > 4 54 ms 54 ms 52 ms f-ea5.F.DE.net.DTAG.DE [62.154.16.165] > 5 53 ms 54 ms 52 ms Te-4-4.car2.Frankfurt1.Level3.net > [4.68.110.253] > 6 54 ms 54 ms 67 ms ae-32-52.ebr2.Frankfurt1.Level3.net > [4.68.118.62] > 7 54 ms 54 ms 67 ms ae-1-100.ebr1.Frankfurt1.Level3.net > [4.69.132.125] > 8 71 ms 72 ms 73 ms ae-2.ebr2.Paris1.Level3.net > [4.69.132.141] > 9 152 ms 143 ms 144 ms ae-5.ebr2.Washington1.Level3.net > [4.69.132.113] > 10 146 ms 144 ms 144 ms ae-72-72.csw2.Washington1.Level3.net > [4.69.134.150] > 11 155 ms 144 ms 144 ms ae-74-74.ebr4.Washington1.Level3.net > [4.69.134.181] > 12 223 ms 230 ms 234 ms ae-4.ebr3.LosAngeles1.Level3.net > [4.69.132.81] > 13 223 ms 221 ms 230 ms ae-2.ebr3.SanJose1.Level3.net > [4.69.132.9] > 14 230 ms 234 ms 234 ms ae-73-73.csw2.SanJose1.Level3.net > [4.69.134.230] > 15 234 ms 234 ms 234 ms ae-72-72.ebr2.SanJose1.Level3.net > [4.69.134.213] > 16 222 ms 222 ms 223 ms ae-4-4.car2.SanFrancisco1.Level3.net > [4.69.133.157] > 17 * * * Request timed out. > 18 * * * Request timed out. > From nicholaz at blueflash.cc Fri Jul 27 11:35:14 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 27 11:35:22 2007 Subject: [sldev] Server/Grid unavailable? In-Reply-To: <46AA39DC.1070409@electricsheepcompany.com> References: <46AA2759.7060109@blueflash.cc> <46AA39DC.1070409@electricsheepcompany.com> Message-ID: <46AA3AE2.5080805@blueflash.cc> Marcus Welz wrote: > I am having the same issue. Nothing on the blog except the occasional user in the comments saying the can't log on. Wonder if it's more of a carrier problem (going to San Francisco via Level3 networks). Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From marcus at electricsheepcompany.com Fri Jul 27 11:43:23 2007 From: marcus at electricsheepcompany.com (Marcus Welz) Date: Fri Jul 27 11:43:47 2007 Subject: [sldev] Server/Grid unavailable? In-Reply-To: <46AA3AE2.5080805@blueflash.cc> References: <46AA2759.7060109@blueflash.cc> <46AA39DC.1070409@electricsheepcompany.com> <46AA3AE2.5080805@blueflash.cc> Message-ID: <46AA3CCB.4010502@electricsheepcompany.com> Yeah, not sure. Judging by the traceroute, we're both on t-online. I can get to everything else fine. I can ssh into accounts on various other machines on different networks and get to secondlife.com from there, too. Makes me wonder whether that's some kind of secondlife ip ban for a certain tonline address range. Nicholaz Beresford wrote: > > Marcus Welz wrote: > > I am having the same issue. > > Nothing on the blog except the occasional user in the > comments saying the can't log on. Wonder if it's more > of a carrier problem (going to San Francisco via Level3 > networks). > > > > Nick > --- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > > > From po at danielnylander.se Fri Jul 27 11:44:24 2007 From: po at danielnylander.se (Daniel Nylander) Date: Fri Jul 27 11:44:36 2007 Subject: [sldev] Translations In-Reply-To: <1185540494.9513.38.camel@greger> References: <46A917EC.6040303@danielnylander.se> <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> <1185540494.9513.38.camel@greger> Message-ID: <46AA3D08.6080102@danielnylander.se> Guys (and gals), I think I'm on to something here. I'm using the xml2po from the gnome-doc-utils package to convert all translatable XML data to GNU gettext strings. GNU gettext is also required. cd indra/newview/skins/xui (I'm using the 1.18.0.6 release source code on Linux) 1. Create the POT file (POT = untranslated PO Template) xml2po -o secondlife.pot en-us/*.xml 2. Copy the template (secondlife.pot) to xx.po (where xx is your country code) with a PO editor (such as poedit, kbabel etc.). The file contains 1609 different text strings. I have generated a template which you can see over at http://home.danielnylander.se/translations/secondlife/secondlife.pot 3. Convert the translated PO file back to localized XML files xml2po -p xx.po en-us/alerts.xml > xx/alerts.xml This can also be automated for all 137 English XML files (Unix shell script) cd en-us; for a in *.xml; do xml2po -p ../xx.po $a > ../xx/$a; echo "$a done"; done 4. Voila! Now you should have a complete translation. If you need to update an existing translation, create the POT file but use the 'msgmerge' command to merge is new structure with the old PO file. This will add/change the strings in the existing PO file and the translator will directly see the changed/new strings. This process means: - Translators should not touch the XML files at all. One string can be used at hundreds of places but will only be translated once. - No faulty XML files(?). Translators will only touch translatable strings and nothing else. - Developers can update the translations and send the incomplete PO file to the translators for a quick update. Developers will then generate the XML files. - Proofreading will be so easy. Everything is in one file. Creating a diff between versions is even more simple. - There are web based translation tools which can be offered to translators and translator teams. One free tool is Pootle. http://www.wordforge.org/drupal/projects/wordforge/tools/pootle Please test this process and see if it works out for you! -- Daniel Nylander (CISSP, GCUX, GCFA) Stockholm, Sweden http://www.DanielNylander.se info@danielnylander.se yeager@ubuntu.com dnylande@gnome.org From nicholaz at blueflash.cc Fri Jul 27 11:58:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jul 27 11:58:35 2007 Subject: [sldev] Server/Grid unavailable? In-Reply-To: <46AA3CCB.4010502@electricsheepcompany.com> References: <46AA2759.7060109@blueflash.cc> <46AA39DC.1070409@electricsheepcompany.com> <46AA3AE2.5080805@blueflash.cc> <46AA3CCB.4010502@electricsheepcompany.com> Message-ID: <46AA4053.7010805@blueflash.cc> Either that or the cleaning lady unplugged the router/gateway to Level3 Networks in order put plug in her vacuum cleaner :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Marcus Welz wrote: > Yeah, not sure. Judging by the traceroute, we're both on t-online. I can > get to everything else fine. I can ssh into accounts on various other > machines on different networks and get to secondlife.com from there, > too. Makes me wonder whether that's some kind of secondlife ip ban for a > certain tonline address range. > > Nicholaz Beresford wrote: >> >> Marcus Welz wrote: >> > I am having the same issue. >> >> Nothing on the blog except the occasional user in the >> comments saying the can't log on. Wonder if it's more >> of a carrier problem (going to San Francisco via Level3 >> networks). >> >> >> >> Nick >> --- >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> >> >> > From zortiger at gmail.com Fri Jul 27 11:59:34 2007 From: zortiger at gmail.com (Erik Hill) Date: Fri Jul 27 11:59:38 2007 Subject: [sldev] Translations In-Reply-To: <46AA3D08.6080102@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> <1185540494.9513.38.camel@greger> <46AA3D08.6080102@danielnylander.se> Message-ID: <7c61ce730707271159i278cf122p66c30ece484deb65@mail.gmail.com> I think your over thinking the gettext. Gettext is vary handy, ill admit. But if it was it would be best to redo the hole translation structure if gettext was used. One of the best things about gettext in my opinion is that there are tools to phrase actual source code. So the hole thing could be done with english and the use of the function _gettext(translate), then the source could be ran though a program to process all the gettext generating a pot file. Then translations, would be done from that, saves a lot of time, and if a translations missing, the defaults used. On 7/27/07, Daniel Nylander wrote: > > > Guys (and gals), I think I'm on to something here. > > I'm using the xml2po from the gnome-doc-utils package to convert all > translatable XML data to GNU gettext strings. GNU gettext is also > required. > > > cd indra/newview/skins/xui > > (I'm using the 1.18.0.6 release source code on Linux) > > > 1. Create the POT file (POT = untranslated PO Template) > > xml2po -o secondlife.pot en-us/*.xml > > 2. Copy the template (secondlife.pot) to xx.po (where xx is your country > code) with a PO editor (such as poedit, kbabel etc.). The file contains > 1609 different text strings. > > I have generated a template which you can see over at > http://home.danielnylander.se/translations/secondlife/secondlife.pot > > 3. Convert the translated PO file back to localized XML files > > xml2po -p xx.po en-us/alerts.xml > xx/alerts.xml > > This can also be automated for all 137 English XML files (Unix shell > script) > > cd en-us; for a in *.xml; do xml2po -p ../xx.po $a > ../xx/$a; echo "$a > done"; done > > 4. Voila! Now you should have a complete translation. > > > If you need to update an existing translation, create the POT file but > use the 'msgmerge' command to merge is new structure with the old PO > file. This will add/change the strings in the existing PO file and the > translator will directly see the changed/new strings. > > > This process means: > > - Translators should not touch the XML files at all. One string can be > used at hundreds of places but will only be translated once. > > - No faulty XML files(?). Translators will only touch translatable > strings and nothing else. > > - Developers can update the translations and send the incomplete PO file > to the translators for a quick update. Developers will then generate the > XML files. > > - Proofreading will be so easy. Everything is in one file. Creating a > diff between versions is even more simple. > > - There are web based translation tools which can be offered to > translators and translator teams. One free tool is Pootle. > http://www.wordforge.org/drupal/projects/wordforge/tools/pootle > > > Please test this process and see if it works out for you! > > -- > Daniel Nylander (CISSP, GCUX, GCFA) > Stockholm, Sweden > http://www.DanielNylander.se > info@danielnylander.se yeager@ubuntu.com dnylande@gnome.org > > _______________________________________________ > 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/20070727/f6d13cd4/attachment-0001.htm From po at danielnylander.se Fri Jul 27 12:22:53 2007 From: po at danielnylander.se (Daniel Nylander) Date: Fri Jul 27 12:22:58 2007 Subject: [sldev] Translations In-Reply-To: <7c61ce730707271159i278cf122p66c30ece484deb65@mail.gmail.com> References: <46A917EC.6040303@danielnylander.se> <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> <1185540494.9513.38.camel@greger> <46AA3D08.6080102@danielnylander.se> <7c61ce730707271159i278cf122p66c30ece484deb65@mail.gmail.com> Message-ID: <46AA460D.1080609@danielnylander.se> Erik Hill skrev: > Gettext is vary handy, ill admit. But if it was it would be best to redo > the hole translation structure if gettext was used. > One of the best things about gettext in my opinion is that there are > tools to phrase actual source code. > So the hole thing could be done with english and the use of the function > _gettext(translate), then the source could be ran though a program to > process all the gettext generating a pot file. Changing the whole source code is a PITA. > Then translations, would be done from that, saves a lot of time, and if > a translations missing, the defaults used. My method will result in the same. If there is no translation for a string, the original string (English) will be used. My suggestion is to appoint a Translation Coordinator who will lead the localization work and be in close contact with the (future) translation teams. -- Daniel Nylander (CISSP, GCUX, GCFA) Stockholm, Sweden http://www.DanielNylander.se info@danielnylander.se yeager@ubuntu.com dnylande@gnome.org From po at danielnylander.se Fri Jul 27 13:40:56 2007 From: po at danielnylander.se (Daniel Nylander) Date: Fri Jul 27 13:41:11 2007 Subject: [sldev] Translations In-Reply-To: <46AA3D08.6080102@danielnylander.se> References: <46A917EC.6040303@danielnylander.se> <75s9Le14e1Ps00Ge4fu4e74c.alissa_sabre@yahoo.co.jp> <1185540494.9513.38.camel@greger> <46AA3D08.6080102@danielnylander.se> Message-ID: <46AA5858.5050801@danielnylander.se> Daniel Nylander skrev: > Guys (and gals), I think I'm on to something here. > > I'm using the xml2po from the gnome-doc-utils package to convert all > translatable XML data to GNU gettext strings. GNU gettext is also required. I did however notice that xml2po didn't see strings like these: